Then place it in the boot partition and extlinux.conf consists of its reference:
fdtoverlays /beaglenode.dtbo
During boot time, u-boot reports an error about this specific dtbo I cannot understand:
U-Boot SPL 2023.01 (Jan 09 2023 - 16:07:33 +0000)
Trying to boot from MMC1
U-Boot 2023.01 (Jan 09 2023 - 16:07:33 +0000)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
Core: 160 devices, 18 uclasses, devicetree: separate
WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
<ethaddr> not set. Validating first E-fuse MAC
Net: eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1: Yocto
Retrieving file: /extlinux/../zImage
append: root=PARTUUID=83f57597-02 rootwait console=ttyS0,115200
Retrieving file: /extlinux/../am335x-bonegreen.dtb
Retrieving file: /extlinux/../beaglenode.dtbo
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
Failed to apply overlay ../beaglenode.dtbo, skipping
Kernel image @ 0x82000000 [ 0x000000 - 0x77b738 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
EXTLINUX FAILED: continuing...
63965 bytes read in 6 ms (10.2 MiB/s)
Working FDT set to 88000000
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Exact error part:
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
What am I missing exactly…?
I would appreciate all help!
But was the base DTC file also compiled with that option? What does yocto do?
Devicetree files can be a real pain to debug as the error message are often no help
You need to build both files with -@… we can see you built beaglenode.dtbo with -@ but you need to build am335x-bonegreen.dtb with that too.
Right… Now I get it.
Not sure what version, but you can just patch the makefile:
I am using the meta-yocto-bsp , not meta-ti (Kirkstone). I manually bumped the uboot version from 2022.01 to 2023.01 (edited SRCREV in the poky repo for now) to even be able to use the dtbo, otherwise I faced this issue:
For a very long time already, I am trying to find a working yocto configuration for the BBB that would have all needed features working (can load dtbo, can boot without kernel panic)- still cannot get it (with meta-ti or not).
I do not understand the patching functionality yet in Yocto. @RobertCNelson would you mind explaining how to incorporate your proposed solution exactly? I have my custom example layer added to the build and I can do changes there. I think your example refers to meta-ti, but I am not using it (kernel panic at boot time as mentioned in the linked topic).
I think that class is only for building external overlays… Other then the Makefile file in the kernel source, i don’t see a way to globally enable this.
What kernel source are you currently building in meta-ti? i might have already pushed an update to give you this…
What kernel source are you currently building in meta-ti? i might have already pushed an update to give you this…
I am not using meta-ti, I am using meta-yocto-bsp. In the meta-ti-bsp the dtbo can be loaded, but the image is unusable on Kirkstone because of the kworker failure during boot as described here:
But when I was building the meta-ti-bsp, it was on the kirkstone branch.
I think that class is only for building external overlays… Other then the Makefile file in the kernel source, i don’t see a way to globally enable this.
I see… I just tried to assign my own dts path (with the beaglenode.dts) to the DT_FILES_PATH variable, but that did not change anything…
Also, I have changed the u-boot version in meta-yocto-bsp from 2022.01 to 2023.01 exactly because I have seen that the dtbo was loaded when using meta-ti-bsp (it was using u0boot version 2023.01). I have no idea why this does not work…
So what I did to confirm your theory 100% is that I removed the am335x-bonegreen.dtb compiled by poky-yocto-bsp and replaced it with one compiled by meta-ti-bsp. Although the kernel does not start now:
U-Boot SPL 2023.07.02 (Jul 11 2023 - 15:20:44 +0000)
Trying to boot from MMC1
U-Boot 2023.07.02 (Jul 11 2023 - 15:20:44 +0000)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
Core: 160 devices, 18 uclasses, devicetree: separate
WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
<ethaddr> not set. Validating first E-fuse MAC
Net: eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1: Yocto
Retrieving file: /zImage
append: root=PARTUUID=89a21fdb-02 rootwait console=ttyS0,115200
Retrieving file: /am335x-bonegreen.dtb
Retrieving file: /beaglenode.dtbo
Kernel image @ 0x82000000 [ 0x000000 - 0x77b738 ]
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Device Tree to 8ffe4000, end 8fffffff ... OK
Working FDT set to 8ffe4000
Starting kernel ... (end of the output)
The error seems to be mitigated… What I tried earlier is to include only the meta-ti-bsp recipe for u-boot building and remove the one from meta-yocto-bsp- that did not really work and required a lot of manual edits…
but that is d08880e7ec70e70249f80b8305da8e90bd47c606 we need… 423e1996694b61fbfc8ec3bf062fc6461d64fde1 → linux-yocto - Yocto Linux Embedded kernel (v6.1.20) that also matches…
git clone --reference ../linux-src/ https://git.yoctoproject.org/linux-yocto
cd ./linux-yocto/
git checkout 423e1996694b61fbfc8ec3bf062fc6461d64fde1
Thank you for the answer- this is still a bit too fast for me, I do not understand what actions exactly need to be taken and how to match this example to my case…
looks like 6.1.x
But why this one? It seems that I am using 5.15 following your notation:
But I do not have the openembedded-core checked out locally- for this purpose I only have poky repo and my custom exemplary layer. Can this “patching” be done somehow within the poky repo and the meta-yocto-bsp dir?
In the end, the poky (or any other yocto related) repo(s) are just submodules in my project repo: GitHub - Beaglenode/BeagleNodeOs at setup_config . The only additional changes (like patching I guess) should by design be done in the meta-beaglenode directory in the above repo, as thats the custom layer. Otherwise If I need to add changes in the yocto related repos, I would need to fork them and detatch from the main repo…
otherwise, it’s yocto, not my cup of tea… you just need to figure out how to add that ^ patch to the yocto *.bb files…
I think still more tha mine
Either way, I think I understand the high level concept. Will try to complete this somehow within the poky repo. Thank you for the help!
A bit off topic, but have you had a look at Buildroot ? It has a much lower learning curve. If you have ever built a Linux kernel from source you will feel right at home straight away. If you want to build a system that isn’t going to change, where you don’t need to build packages to install I think it is a much better option.
Think of Yocto as building a distribution with all that entails as to Buildroot building an embedded system where you have a fixed install.
Basically download the buildroot source, extract it, cd into the source directory, run make defconfig for your board (or a board with the same CPU), make menuconfig to config what you want it to build and the make to build it.
No messing around with editing or creating recipes or layers. As part of the make menuconfig, you can setup the git repos for kernel and u-boot, tell it what defconfigs to use, what dtbs you need to include in the final image.
Use menuconfig to select what libraries and packages you need. By default the last time I used it, it just builds a tiny image using busybox. Great if you are aiming for a minimal system. There are lots of build options, but you can see what they are just by going through the menus. No need to hunt through documentation most of the time. Somethings may be hidden depending on your choices.
Have not used it to build a BBB image for over 10 years now. Last time I used it was for an imx6ul based sbc.
Hi @benedict.hewson ,
The funny thing is I come from Buildroot world (sort of). I also do not have too wide experience with it, but I initially started to work on my custom image for the given project exactly with Buildroot. I decided to switch to Yocto, because:
I have seen that the BBB is a reference platform for it, so assumed it would work better out of the box,
I have figured that with yocto it was easier to do some development, without needing to fork the build system repo and work outside of it (like poky is right now a submodule in my git project and I am trying to incorporate all changes outside of it),
I wanted to learn more about Yocto because I have noticed that it is used more often in the general engineering market place.
All and all I didn’t expect so many issues and such a step learning curve (maybe just for me). My aim in theory was simple:
Get a working (booting) image for the BBB/ BBG,
Add a device tree overlay to configure the required pins,
Utilize PRU for part of the software.
I did not even get to point 3, because surprisingly (for me) I am stuck on point 1 and 2 for a long period of time. I fully get how this is an open source project, but I just assumed (probably incorrectly) that things would work more out of the box for this specific hardware…
Yocto has an extremely high learning curve compared to Buildroot.
Do you really need a custom image ? Just go with the default Debian install. You will have access to pretty much everything you need, or it can be installed.
I think it is a shame that there is so much more publicity for Yocto than Buildroot.
But that doesn’t mean it is better. Each system has pros and cons. The dependency build on Yocto is much better than Buildroot for example. But I have not really found that to be much of an advantage if you are building a project specific image as once setup it never changes. Unless you need to remove packages, then with Buildroot you need to clean and rebuild everything, but again this just doesn’t happen that often.
Even though hardware manufacturers rarely mention Buildroot, really all you need for any hardware is the kernel source and u-boot source and know what CPU settings you need to configure.
I like the fact that in Buildroot it is very easy to locate the downloaded source files used to build the image. Try to find the same in a Yocto build !
Whether you are using Yocto or Buildroot, if you want to customize a package you need to patch it. Both let you do that by apply diffs to the downloaded source.
Both Yocto and Buildroot will compile a cross compiler that you can use for your own software development.
Fortunately I am in a position where I don’t need to learn Yocto. I have tried a few times, but I find the documentation to be a bit poor and often doesn’t explain things or use cases very well. Not to mention you could spend weeks reading it all. For me Buildroot will always be my goto solution for an embedded Linux system unless something better comes along.
