Beaglebone Black Test Build Fails
Build Environment
Ubuntu 22.04
Yocto 5.0.2
The toolchain is up to date and the compiler, make and linker are all in spec with the Yocto 5 requirements.
Target Machine
Beaglebone Black
Behavior
Building the mender scarthgap-v2024.07 ./tests/build-conf/beagleboneblack/local.conf with yocto-5.0.2-56-gca27724b44 fails with sram overflows.
| arm-poky-linux-gnueabi-ld.bfd: u-boot-spl section `__u_boot_list' will not fit in region `.sram'
| arm-poky-linux-gnueabi-ld.bfd: region `.sram' overflowed by 740 bytes
| make[2]: *** [/home/<user>/Documents/repos/build-targets/beaglebone/tmp/work/beaglebone_yocto-poky-linux-gnueabi/u-boot/2024.01/git/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
| ERROR: oe_runmake failed
Hi @SuicidalLabRat,
thanks for the report! However I would guess that this is a false positive caused by the test harness somewhere, as my weekly builds for the BBB have been extremely stable. See the latest at build boards · mendersoftware/meta-mender-community@e0581d2 · GitHub.
I’ll have a peek into the test build configuration, my gut feeling is that there is something possibly outdated which causes that.
Are you seeing problems on the BBB? If so, which?
Greetz,
Josef
Hey YTJ, thanks for the prompt response!
At the moment, our build farm is running the latest releases of all the toolchain components supported by Ubuntu 22.04.
It may be that I need to roll back to an earlier linker?
We cant get a build to complete, so no builds have deployed to our test shards, i.e. no testing has been done on the target hardware.
Sorry, Im not sure I answered your question 
NOTE, If you describe your build environment, I can replicate it for testing.
Hi @SuicidalLabRat,
I definitely expect Ubuntu 22.04 to build this. Have you tried the beaglebone.yml kas configuration on the same host?
The build environment I use is a very boring Debian 10, using this configuration: meta-mender-community/kas/beaglebone.yml at scarthgap · TheYoctoJester/meta-mender-community · GitHub
Greets,
Josef
FYI, I should have made clear that the failing build differs from the official test configuration in that it deploys u-boot in place of grub.
Hi @SuicidalLabRat,
okay, so to properly summarise: you are seeing a build failure of u-boot. As this is not the default integration path for the BBB, it is not being hit in our tests. Is that correct?
If so, there’s not so much more that I can try to help, just some random ideas you might possibly find helpful:
- is this actually being triggered by the Mender patches to
u-boot, or not? As beaglebone-yocto is a default target in poky, I’d expect that to be quite well tested.
- If you can confirm that the problem is the Mender patches, the mention of the
SPL indicates that it might be adding things there which are not required. The Mender boot logic should be good enough in u-boot proper, so it might be good to figure out why the SPL is even affected.
I’ll happily be a debugging conversation partner and rubberduck in this context.
Greets,
Josef
Hey Jester,
Thanks for spawning this new thread!
One further observation I can provide is that commenting out all Mender references in the local.conf and bblayers results in a successful build, including u-boot.
Any chance there have been changes in how you are linking the spl build?
THNX!
Hi @SuicidalLabRat,
unfortunately, no. The changes that Mender introduces are really minimal:
- it enables the
BOOTCOUNT feature in the environment
- it makes sure that a redundant environment is enabled
- adds a few lines to the default environment.
You can relatively simply verify that by looking at the changes.
So given that, my assumption is that something, somewhere in the u-boot codebase has grown to the point where enabling those upstream features breaks the build. Really sorry I don’t have anything better, but you probably need to go digging here.
Greets,
Josef
Yuck 
Thanks for engaging on this YoctoJester, much appreciated!
Sadly, this is pretty confounding; the sram regions are fixed on the BBB, so I would expect the yocto tests for the beaglebone-yocto machine target would not pass if the spl was oversized by ~800 bytes. But here we are. Maybe I can try ‘preferring’ an earlier u-boot and see if something that simple will suffice…
At any rate, please keep this thread open, and I’ll update as I go.
THNX!
Yeah I expect the Yocto internal tests are all fine and keeping the SRAM restrictions. The question is, what adds the additional storage requirements. Some thoughts:
- enable the features one by one and compare
- check the default environment, maybe there are things that you can remove
- maybe there are things enabled in the config that add to the SPL, but which you don’t actually need
Good luck!
I have the same issue using UBoot and the mender-uboot-auto-configure stuff. I do see a lot of FITIMAGE stuff in the UBoot config which I am trying to remove as I don’t believe it is needed when using mender-uboot. Unfortunately just adding a .cfg fragment doesn’t seem to work.
Drew
1 Like
I think it may be time for this particular project I am helping to switch to GRUB.
In a related note, I tried to build the stock image using GRUB for the beaglebone and it fails to boot. It tries to load GRUB and reports:
3216 bytes read in 28 ms (13.4 MiB/s)
Booting /efi\boot\bootarm.efi
Welcome to GRUB!
error: unknown filesystem.
Dropping to grub prompt for unknown reason. Should never get here.
I built this setup using the following:
git clone -b scarthgap git@github.com:mendersoftware/meta-mender-community
kas build meta-mender-community/kas/beaglebone.yml
Any ideas?
I get the same result, though not using kas.
SLR-
Hi @drewmoseley
Does this chore: Document problem with old GRUB and new yocto · mendersoftware/mender-docs@c6121d9 · GitHub fix the boot? If so, we might need to extend it to all of the mender-grub feature maybe.
Greetz,
Josef
Yes, that does seem to work. It does have a fairly long delay after the following output:
Welcome to GRUB!
EFI stub: Booting Linux Kernel...
EFI stub: Entering in SVC mode with MMU enabled
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
before booting.
Drew
I also managed to get UBoot to build. I added a cfg file into my layer with the following;
# CONFIG_SPL_USB_GADGET is not set
# CONFIG_SPL_USB_ETHER is not set
# CONFIG_SPL_USB_ETH_RNDIS is not set
# CONFIG_SPL_MUSB_NEW is not set
This disabled enough in SPL to allow it to fit. I don’t think any of that is needed in a Mender configuration so should be a reasonable change. @TheYoctoJester should I submit that as a patch in meta-mender-beaglebone or keep it local?
Drew
1 Like
@drewmoseley a PR that I can use to create an alternate build config (as opposed to GRUB) would be perfect!
@ drewmoseley
Interesting. I built with an almost identical fragment, and while it did result in a successful build, once written to actual hardware, the boot failed at Starting kernel ...
I’ll try again, but using your SPL configuration changes instead of mine, and see what happens…
SLR-