Updating to 2022 u-boot

I have a beaglebone green and I am looking to update u-boot to the latest (not for any reason in particular other than to learn). I can seem to find a guide that does this though. Below are the steps that I have taken to try to get it to work, but whenever I turn the device on it gets hung at SPL with the following message:
"U-Boot SPL 2022.01-00657-g2d7a463e82 (Feb 16 2022 - 17:42:54 -0500)
Trying to boot from MMC2

Steps I have taken:
git clone https://github.com/beagleboard/u-boot.git
cd u-boot
export MAKEFLAGS=-j$(nproc)
#make -j $(nproc)
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm
sudo cp MLO …/mnt
sudo cp u-boot.img …/mnt
sudo sync
sudo umount ./mnt
sudo dd if=./MLO of=/dev/mmcblk0 count=1 seek=1 bs=128k
sudo dd if=./u-boot.img of=/dev/mmcblk0 count=2 seek=1 bs=384k

In addition to this I have even attempted to drop the MLO and u-boot.img file into the u-boot folder as I saw where someone did that, but nothing worked for me.

Thanks in advance.

@Ted_Kent Retry with, things got ‘fatter’… (i forget when it happened, u-boot.img → u-boot-dtb.img switch has occurred)

sudo dd if=./MLO of=/dev/mmcblk0 count=2 seek=1 bs=128k
sudo dd if=./u-boot-dtb.img of=/dev/mmcblk0 count=4 seek=1 bs=384k


Appreciate the help, it is booting now, but I think there are some configs I need to get through before it will boot again.

@RobertCNelson Am I able to write this to an active device? I have tried a couple times and when I reboot, only the MLO loads. I am able to boot it again using an sd card. When I get to the user space on the sd card if I try to write the u-boot-dtb.img to the eMMC it works. There is no change in the command just from where I am working from. From there I can reboot and the device will load perfectly.

For context I am working on a wheezy image.

Hi @Ted_Kent i haven’t tested u-boot on the am335x beyond 2021.10 yet…

My branch is here:

with a build and install scripts built in…

It looks like v2022.04 has now dropped:

That’s my next personal target upgrade for am335x…


Hey @RobertCNelson I found that 2022 u-boot seems to boot the device well and I have had no issues when it has been written correctly on the device. My issue is that I am booting off of the eMMC and trying to also write there. It doesn’t seem like this should be an issue, but again only the MLO is loading when I do the initial flash.

If I boot the beaglebone from a different media device (sd card/NFS), I can flash the same u-boot-dtb.img file that I was attempting to flash previously and it will work. Is there something off with my commands?

108 -rw-r–r-- 1 root root 106.0K Apr 4 13:53 MLO
880 -rw-r–r-- 1 root root 873.9K Apr 4 13:53 u-boot-dtb.img

In u-boot, on the am335x, the writing instructions are the same for microSD vs eMMC… (aka nothing special for eMMC)…

On the AM335x, the bootrom scan’s eMMC first over microSD… So if it finds MLO on the eMMC it’ll load that first no matter what… (The boot button on the BBB changes this order, to help ignore the eMMC, but since it’s sysboot pins, it must be done before power on, as these pins are very special and only scanned by the bootrom early on startup…)


I am sorry, I think I am not getting my point across that well. Thank you for your patience.

My goal in this project is to perform an “OTA” upgrade for devices going from wheezy to bullseye. Stage one is to update the u-boot on the device, as the u-boot for 2015 doesn’t support pxebooting. Stage two is to boot the device using PXE, Stage Three is to flash the device with an updated image.

In stage one, I mount an NFS from the wheezy operating system to a folder that has the u-boot-dtb.img and MLO files.

From here I clear out the partition table using

sudo dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=10

I then flash MLO

dd if=/mnt/nfs/MLO of=/dev/mmcblk0 count=2 seek=1 bs=128k

then flash the u-boot-dtb.img

dd if=/mnt/nfs/u-boot-dtb.img of=/dev/mmcblk0 count=4 seek=1 bs=384k

When I reboot the device only MLO loads and it is not finding the u-boot file.

My workaround is to insert and sdcard, mount whatever image is on there, remount the NFS and flash the u-boot-dtb.img using the following command.

dd if=/mnt/nfs/u-boot-dtb.img of=/dev/mmcblk1 count=4 seek=1 bs=384k

Note: dev is being switched from /dev/mmcblk0 to /dev/mmcblk1 because of the different kernel versions.

Let me know if you have any suggestions.

That is odd, i’d fully expect after a reboot, that would load into u-boot…


1 Like

Thank you for confirming and I really appreciate your time. I’ll see if I can get this going and will bring back any findings.


Not sure if this is related, but this device does have boot partitions. From my understanding there is nothing present in these and that they are not used. (added the underscores to keep it as one block.)

Disk /dev/mmcblk0: 3909 MB, 3909091328 bytes
4 heads, 16 sectors/track, 119296 cylinders, total 7634944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x82034f61
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 2048 2099199 1048576 83 Linux
/dev/mmcblk0p2 2099200 4196351 1048576 83 Linux
/dev/mmcblk0p3 4196352 6293503 1048576 83 Linux
/dev/mmcblk0p4 6293504 7634943 670720 83 Linux
Disk /dev/mmcblk0boot1: 2 MB, 2097152 bytes
4 heads, 16 sectors/track, 64 cylinders, total 4096 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mmcblk0boot1 doesn’t contain a valid partition table
Disk /dev/mmcblk0boot0: 2 MB, 2097152 bytes
4 heads, 16 sectors/track, 64 cylinders, total 4096 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mmcblk0boot0 doesn’t contain a valid partition table

am335x does not use the /dev/mmcblk0boot0 or /dev/mmcblk0boot1 partitions feel free to use them as a extra small usb flash drives…

By default today, we use an offset of 4096… More room for u-boot…


My guess at this point is that the kernel is trying to fix the filesystem. If I power the device off, without using the reboot command and within 15 seconds of the device write I am able to get SPL to load u-boot with no issues. I have also found that if I completely crash the kernel this will work as well, upon a manual reboot it works as well.

To crash the kernel
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

flashing commands.
sudo dd if=./MLO of=/dev/mmcblk0 count=2 seek=1 bs=128k conv=fdatasync,notrunc
sudo dd if=./u-boot.img of=/dev/mmcblk0 count=4 seek=1 bs=384k conv=notrunc,fdatasync

Thanks again for your help during this project.