Clarify why RPI firmware loaded device tree is 'Very Bad'

[kodonnell]

Hi there, thanks for this repo - I really wanted to use swupdate, but went with RAUC purely because your repo exists = )

I'm working through the device tree + raspberry pi stuff in buildroot and a genuine question (from a novice in this area): why have you described using the RPI firmware loaded device tree as 'Very Bad'? The reason given is

This creates a dependency between your rootfs image containing the kernel and the FAT partition with the device tree file and overlays

But isn't this always the case i.e. even with a DTB it in the rootfs partition, there's still a dependency between the rootfs and FAT because u-boot is on the FAT partition, correct? This might be different if you've got flash but that only applies to the CM4?

Not trying to be difficult here, but if my understanding is correct, then using the RPI firmware approach (at least for non-CM4) has a similar risk profile, but is much easier (for me) and more tested than me trying to roll my own etc.

Thoughts?

[cdsteinkuehler]

Well....it's complicated on the RPi.

Generally, the Linux kernel, kernel modules, and device tree are all related and having them on the rootfs instead of the boot partition means they will all stay consistent if/when the RAUC U-Boot scripts decide a fresh update is bad and rolling back to the last-known-good rootfs is required. The RPi complicates this because the (closed source) firmware makes some changes to the device-tree which are required to boot properly (eg: the DMA range for the eMMC controller which changes based on the silicon revision). See this RPi forum post for details on what the EEPROM firmware is doing to figure out which bits you might need to replicate: https://forums.raspberrypi.com/viewtopic.php?p=1974203#p1974233

Also, it is generally safer to update the rootfs image as there are multiple copies and it can be rolled back vs. updating the boot-loader FAT partition. I do have atomic updates enabled for the boot loader, but there is no rolling back if you wind up with something that doesn't boot properly.

So I put everything I can on the rootfs partition in order to avoid updating the boot FAT partition any more than absolutely necessary. You may have different concerns and wish to do things differently.

[kodonnell]

Thanks, that makes more sense - the issue is less the dependency between the boot and root partitions (in the sense that a good system always requires a good boot partition), and more keeping them in sync. (I think!)

Re the boot partition updates - have you considered tryboot? Idea being, after the boot partition is updated, reboot '<new boot partition> tryboot' and it'll try to boot from it. If that fails, it'll stay booting from the old boot partition. Otherwise if it succeeds, all good, proceed with atomic shuffling of the MBR as currently (I think that's how it works?). I don't know if this will work with RAUC, but it feels simple - and, at worst, you could drop the MBR switching and use autoboot.txt - instead of shuffling the MBR, just update the boot_partition in autoboot.txt. Thoughts?

[cdsteinkuehler]

The tryboot functionality was added shortly after I got the U-Boot scripts for RAUC working and I have not dug into it much. When I last looked at this, it didn't seem like tryboot would be particularly easy to integrate with RAUC vs. the more conventional use of U-Boot scripts and environment variables, but perhaps that has changed in the last year or so since I looked at tryboot.

[kodonnell]

Thanks. To clarify, I'm suggesting keeping U-boot + environment variables, but only using tryboot/autoboot when you update the boot partition (which currently uses MBR switching?). Maybe this is better asked in an issue on the RAUC repo ... anyway, I think I'll close this one.