Please help me understand how U-Boot works on this board

theophile · August 23, 2022, 7:34pm

As noted here, I am trying to experiment with mainline U-Boot in the hopes of getting specific hardware behavior at power-on, before the kernel is loaded. I am using EMMC only. NO SDCARD.

I am using the image for the current release of Batocera (v34), which runs fine “stock.” The Batocera image includes the MBR and a u-boot binary–“U-Boot 2021.07-24128-g0cd076b58b” to be precise.

I have compiled U-Boot from mainline using the Radxa Zero defconfig and it compiles fine. I used the U-Boot build instructions from the Radxa wiki to generate the new u-boot.bin file from the compiled bl33.bin and the other components in the FIP repo. The version string for the new build is “U-Boot 2022.07-rc6-dirty.” However, no matter how I try to flash it, the board will either continue loading U-Boot 2021.07-24128-g0cd076b58b, or it will not boot at all and only output G12A:BL:0253b8:61aa2d;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;CHK:1F;READ:0;CHK:1F;READ:0;CHK:1F;SD?:20000;USB:8;

I have tried:

$ sudo /home/theophile/.nexustools/fastboot erase mmc0
$ sudo /home/theophile/.nexustools/fastboot erase mmc0boot0
$ sudo /home/theophile/.nexustools/fastboot erase mmc0boot1
$ sudo /home/theophile/.nexustools/fastboot flash mmc0 ~/Downloads/batocera-s905gen2-34-20220611.img
$ sudo /home/theophile/.nexustools/fastboot flash mmc0boot0 ~/temp/rz-uboot/fip/radxa-zero/u-boot.bin
$ sudo /home/theophile/.nexustools/fastboot flash mmc0boot1 ~/temp/rz-uboot/fip/radxa-zero/u-boot.bin

All commands complete successfully, but when I boot, U-Boot 2021.07-24128-g0cd076b58b is what loads.

I have tried putting the device into mass storage mode and then doing:

sudo dd if=~/temp/rz-uboot/fip/radxa-zero/u-boot.bin of=/dev/sdg bs=1 count=444; sync
sudo dd if=~/temp/rz-uboot/fip/radxa-zero/u-boot.bin of=/dev/sdg bs=512 skip=1 seek=1; sync

Again, I just keep getting U-Boot 2021.07-24128-g0cd076b58b.

According to this, the SOC looks for bootloaders in the order of mmcblk0, mmcblk0boot0, and mmcblk0boot1, and boots the first one it finds. I assume that the fastboot flash targets mmc0boot0 and mmc0boot1 correspond to mmcblk0boot0 and mmcblk0boot1. If I’m understanding correctly, that means that the SOC must be finding U-Boot 2021.07-24128-g0cd076b58b in mmcblk0 and boots it without proceeding to check in mmc0boot0 or mmc0boot1.

I would have thought that the sudo dd if=~/temp/rz-uboot/fip/radxa-zero/u-boot.bin of=/dev/sdg bs=512 skip=1 seek=1; sync command would write to mmcblk0, but apparently that’s not the case because even after doing that, I still get U-Boot 2021.07-24128-g0cd076b58b.

I even tried to replace U-Boot directly in the Batocera image before flashing it:

dd conv=notrunc if=rz-uboot/fip/radxa-zero/u-boot.bin of=batocera-s905gen2-34-20220611.img bs=512 skip=1 seek=1

But after flashing this modified image, I only get

G12A:BL:0253b8:61aa2d;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;CHK:1F;READ:0;CHK:1F;READ:0;CHK:1F;SD?:20000;USB:8;

I tried erasing mmc0, mmc0boot0, and mmc0boot1 in fastboot and then flashing the new U-Boot image to mmc0boot0 and mmc0boot1 without flashing any image to mmc0. I figured that this would result in the new U-Boot loading, although it obviously would not be able to boot beyond this because it would not be able to find a system image. But that does not work either, only giving me:

G12A:BL:0253b8:61aa2d;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;CHK:1F;READ:0;CHK:1F;READ:0;CHK:1F;SD?:20000;USB:8;

I do not understand the behavior I am seeing. What do I have to do to flash my new U-Boot image to the emmc so that it actually loads?

theophile · September 6, 2022, 1:42pm

Any input on this?

thc013 · September 6, 2022, 5:15pm

he is playing with uboot also

and pgwipeout did also some work with mainline uboot

thought the major holdup is the release of the atf-sources from rockchip

theophile · September 6, 2022, 5:35pm

Thanks, but I’m working with the Radxa Zero board, which is an Amlogic SoC, not Rockchip. Mainline U-Boot builds fine, I just can’t get the bootloader to even attempt to load the binary. No matter what I do, it will either load the U-Boot binary from the flashed distro image, or nothing at all.

igorp · September 7, 2022, 7:04am

Look into goldmine https://github.com/armbian/build/tree/master/config/sources/families/include

jack · September 7, 2022, 11:09am

Make sure eMMC boot0 and boot1 are wipped
You should use u-boot.sd.bin for both eMMC and SD card.
dd notrunc to a existing image will break the MBR header for the image, please check:

https://wiki.radxa.com/Zero/dev/u-boot

bin=/path/to/fip/radxa-zero/u-boot.bin.sd.bin
sudo dd if=$bin of=/dev/sdx conv=fsync,notrunc bs=1 count=444 
sudo dd if=$bin of=/dev/sdx conv=fsync,notrunc bs=512 skip=1 seek=1

theophile · September 22, 2022, 1:31am

Even after following the instructions at https://wiki.radxa.com/Zero/dev/u-boot exactly, and flashing with:

bin=/path/to/fip/radxa-zero/u-boot.bin.sd.bin
sudo dd if=$bin of=/dev/sdx conv=fsync,notrunc bs=1 count=444
sudo dd if=$bin of=/dev/sdx conv=fsync,notrunc bs=512 skip=1 seek=1

I was not able to get the new u-boot image to load, only the “old” one that is packaged with the OS image.

I eventually found a method that appears to work reliably for me. With a working OS image installed, and without wiping any partitions, I appear to be able to flash a new U-Boot binary with this command:

~~> sudo /home/theophile/.nexustools/fastboot flash mmc0 u-boot.bin.sd.bin~~

~~This appears to work for me even though the dd-based commands in mass storage mode do not work for me.~~

EDIT: Nevermind. While this command does flash U-Boot such that it actually loads, I did not try booting past U-Boot and failed to notice that this also clobbers the partition table and prevents U-Boot from actually being able to boot the system. So I am back to the drawing board…

theophile · September 22, 2022, 4:44pm

The OS image I’m using is Batocera, specifically the v35 beta (9/10/22 build) found here: https://mirrors.o2switch.fr/batocera/s905gen2/beta/last/

The image was created with genimage using this config file. From the config, you can see that the image consists of a U-Boot partition at offset 512 that is not in the partition table, plus a 3GB ext4 partition and a 512MB vfat partition that are in the partition table.

I used sfdisk to get the start block and sector counts for each partition in the image then used dd to extract the ext4 and vfat partitions. The I used genimage with a simplified version of the original .cfg file to repack the OS image using my rebuild U-Boot binary plus the original vfat and ext4 partitions.

This worked perfectly. After wiping the emmc and flashing the repackaged image, I now get my recompiled version of U-Boot and it is able to boot into the system as expected. That being the case, I do not understand why the typical ‘dd’ commands to flash U-Boot to the emmc in mass storage mode do not work. Best I can figure, U-Boot is not at the location that the dd commands are writing to.

The vfat partition starts at sector 4096 and the sector size is 512 bytes, which means that U-Boot is located somewhere in the first 2MB of the disk. The U-Boot binary is about 1.4MB. I assumed it would start with sector 1, but maybe it doesn’t? Either way, it does not make sense to me that the old U-Boot would still load after running these commands:

sudo dd if=~/temp/rz-uboot/fip/radxa-zero/u-boot.bin of=/dev/sdg bs=1 count=444; sync
sudo dd if=~/temp/rz-uboot/fip/radxa-zero/u-boot.bin of=/dev/sdg bs=512 skip=1 seek=1; sync

Even if I’m writing the new U-Boot to not precisely the right location, I would expect it to clobber enough of the old U-Boot binary to corrupt it and prevent it from loading.

theophile · September 26, 2022, 11:57pm

I came up with a workaround that’s serving my purposes at the moment. I disassembled the OS image as described in the previous post and then reassembled it without the u-boot partition at all. Then using fastboot I flashed the repacked OS image to mmc0, and then separately flashed u-boot.bin.sd.bin to mmc0boot0. This way as I tinker with u-boot, I can flash new u-boot images to mmc0boot0 without having to guess where on mmc0 the u-boot binary might be located.

Incidentally, the Radxa wiki says that u-boot can be flashed to emmc with the command:

sudo fastboot flash 0x200 /path/to/fip/radxa-zero/u-boot.bin

But this does not work, as fastboot throws a “no such device” error. This is because the “0x200” device only exists in the 2021.01 branch of the Radxa u-boot fork, per this commit. But that patch does not apply to the 2021.07 branch because of intervening commits that refactor a lot of the fastboot handling. So for any distro that uses the 2021.07 u-boot or newer, the “fastboot flash 0x200” command won’t work.

This is especially notable because the Radxa wiki describes the process of building and flashing the 2021.07 branch. So even if a user is on a distro that has the 2021.01 u-boot version with the 0x200 pseudo-partition, flashing the new u-boot binary with fastboot will only work the first time. Once the 2021.07 version is installed, flashing u-boot with fastboot this way won’t work anymore.