Buildroot on Beaglebone?

I’m trying to get a Buildroot-based image working for the Beaglebone Green and Beaglebone Green Wireless.

I’m a bit confused about what’s required to get cape support working.

As far as I can tell the device-tree overlay stuff is handled by u-boot and then handed off to the Kernel as a Flattened Device Tree. Are the CapeMgr patches still required for both the kernel and u-boot?

Is there any up-to-date documentation about how the various parts are supposed to work together?

I’m using the 2020.05.x LTS branch of Buildroot with the 5.6 kernel and 2020.04 u-boot.

We only support u-boot overlays, with a single patch to the linux kernel “-@” for exporting the device tree label’s…

then you just need the 2 u-boot patches:


Thanks for the quick response. I managed to get the patches applied and it looks like uboot is successfully querying the EEPROM. However, it doesn’t seem to actually load the firmware.

U-Boot SPL 2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600)
Trying to boot from MMC2
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **

U-Boot 2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600), Build: jenkins-github_Bootloader-Builder-137

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Global external warm reset has occurred.
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
Model: SeeedStudio BeagleBone Green:
debug: process_cape_part_number:[0060-0701]
debug: process_cape_part_number:[303036302d30373031]
BeagleBone: cape eeprom: i2c_probe: 0x54: /lib/firmware/0060-0701-00A0.dtbo [0x6b10b6f]
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 0 seconds
board_name=[BBG1] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
83026 bytes read in 8 ms (9.9 MiB/s)
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
434 bytes read in 2 ms (211.9 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from /uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
5905032 bytes read in 372 ms (15.1 MiB/s)
loading /am335x-bonegreen.dtb ...
83026 bytes read in 9 ms (8.8 MiB/s)
bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 8ffe8000, end 8ffff451 ... OK

Starting kernel ...

The 0060-0701-00A0.dtbo is built from BB-UART2-00A1.dts in the the repo and with the part number and version changed before compiling it.

I can see the dtbo file in the right spot when I’m logged in:

$ ls -l /lib/firmware
total 1
-rw-r--r--    1 root     root          1024 Sep 15  2020 0060-0701-00A0.dtbo

If it matters, I’m using a merged /usr layout:

$ ls -l /lib
lrwxrwxrwx    1 root     root             7 Sep 15  2020 /lib -> usr/lib

Do I need to do something else to get uboot to actually load the firmware?

“Running uenvcmd …” this means in your /uEnv.txt file you have the uenvcmd variable defined. This takes u-boot down a path to be compatible with anything ancient. Not use new things like overlays…

To make things work, please remove /uEnv.txt from your fat parition…

On your ext4 partition, create /boot/uEnv.txt

In it set these 3 variables:


The uname_r is really important, as that starts the search in the new path, u-boot is expecting: (So please take a look how you named zImage/vmlinuz-xyz)

rootfs: / (ext2/ext3/ext4) (btrfs supported in u-boot v2018.03+ (with both compression options))
/boot/uEnv.txt (priority 4)
/boot/vmlinuz-$(uname -r)
/boot/initrd.img-$(uname -r) (optional, but needed for uuid cases)
/boot/dtbs/$(uname -r)/*.dtb (or one of the 7 locations below)

device tree’s can be here:

(1) Mainline: /boot/dtbs/$(uname -r)/*.dtb
(2) Debian: /usr/lib/linux-image-$(uname -r)/*.dtb
(3) Ubuntu: /lib/firmware/$(uname -r)/device-tree/*.dtb
(4) Fedora: /boot/dtb-$(uname -r)/*.dtb
(5) archlinux: /boot/dtbs/*.dtb
(6) openSUSE: /boot/dtb/*.dtb
(7) OpenEmbedded: /boot/*.dtb

and sorry, this line needs to be changed:

“ro” -> “rw” in debian we always mount ro, with buildroot this needs to be changed…

There’s currently a developer starting to make this generic and merge in upstream u-boot…