agherzan
RaspberryPi CM4: Manually loading a device tree with u-boot does not work
This may not actually be a bug but a poorly documented expected behavior.
I am building core-image-base with RPI_USE_U_BOOT=1 from the current master (90b3ac6fb3037118bc711a14adcb31d2bcd7dfa4) and modified boot.cmd.in, adding a line like
fatload mmc 0:1 ${fdt_addr} bcm2711-rpi-cm4.dtb
In other words I'm overwriting the device tree loaded by the EEPROM bootloader. I'm running this on a RaspberryPi CM4 with eMMC. You can also just manually interrupt the normal U-Boot boot process and load the device tree manually of course. In this case, the kernel does not boot to the login prompt (expectation), but apparently hangs initializing the eMMC. See core-image-base-boot.txt.
You may wonder why I even want to overwrite the EEPROM-bootloader-loaded device tree. With core-image-base, this is certainly not necessary. However, I have a custom distribution that supports firmware upgrades via a two-partition scheme and uses U-Boot (or whatever is available) to choose the correct partition to boot. In my architecture, both kernels and device trees are upgradeable. The port of my distribution to the RaspberryPi CM4 is based on Yocto hardknott and contains a few backports. So I provoked the issue with a default image on the master branch which should be easier for you to understand and reproduce.
Theoretically, the device tree loaded by the EEPROM bootloader and manually using fatload should be identical (they are loaded from identical files). However, if I am comparing the trees as printed by fdt print, there do seem to be differences. (This diff is generated from my own distribution, so it might not be exactly the result you might get when building your own image as described above.)
Apparently, the EEPROM bootloader does some magic things to the device tree and these things must be vital for booting properly. Unfortunately the EEPROM bootloader is closed-source.
Looking into Balena's boot script, I also do not see any manual device tree loading, so it likely also just inherits the preloaded device tree. Apparently, Balena does not support upgrading device trees...
Is it somehow possible to boot with a manually U-boot-loaded device tree or do I always have to let the EEPROM bootloader do this (meaning it would be impossible to safely upgrade device trees on a RaspberryPi CM4)?
Some references here: https://forums.raspberrypi.com/viewtopic.php?t=315662
The base dtb is changed by the bootloader as you noticed. Perhaps the dump of the loaded device-tree in /proc can be used to boot. Moreover, if you make some changes (e.g. add an overlay or edit the dtb) the boot hangs if you do not remove uboot.env.
I'm trying to add support for "tryboot" in u-boot to allow kernel and dt upgrades with a/b rootfs schema.
I'm trying to add support for "tryboot" in u-boot to allow kernel and dt upgrades with a/b rootfs schema.
Thanks for digging up this post - I didn't find anything. tryboot/os_prefix might be an option. Or is it? In the end, I would have to touch the config.txt on the boot partition to make an upgraded partition as "active". But what if this file gets corrupted? Might brick the device. I don't like writing on that partition at all during upgrades. FAT partitions are prone to corruptions. Not to mention that I would have to adapt even more of my partitioning and boot logic for the Pi's idiosyncrasies. (Also, why is there os_prefix at all if you can just as well change the kernel name and device tree name... Well it seems you cannot change the device tree file name in config.txt.)
My current implementation uses a separate small FAT partition for communication between bootloader and Linux firmware and yet another pair of FAT partitions for holding bootloader and kernel for A & B. It can recover from all sorts of hypothetical corruptions. Furthermore I even support booting the last firmware by grounding a GPIO (all the magic is in a U-Boot Hush script). So it is as safe as it gets.
This patch in the u-boot mailiing list is a good starting point to import the firmware modifications applied to the fdt.
https://lists.denx.de/pipermail/u-boot/2021-August/458642.html