Fix the dtb handling during A/B update

[lueschem]

Problem Description

The README of the edi-pi project describes the issue:

⚠️ Raspberry Pi 4 boot loader: On the Raspberry Pi 4 the
stock boot loader
does load the device tree binary and modifies it. For this reason it is difficult to
do a robust update of the kernel together with the device tree binary. For now, edi-pi
does not touch the device tree binary that gets loaded by the stock boot loader during
a robust update and the boot process will just take over the device tree that got loaded
by the stock boot loader instead of taking the one that gets bundled with the kernel.
This might be a setup that is not sustainable for industrial applications that require
long term support. For such scenarios you might want to consider other platforms such as
edi-var and
edi-cl. If I find a solid solution for the described
boot loader issue I will update the configuration accordingly.

Possible Solutions

Dave Jones pointed out some possible solutions: Groovy Boot Modes
Many thanks!

Additional Information

The kernel commit for the new tryboot.txt feature: firmware: raspberrypi: Add support for tryonce reboot flag
The upstream_kernel flag: Firmware handling of upstream kernel and Device Tree files
Handling of *_prefix and upstream_kernel: Boot options in config.txt
A related thread on the Raspberry Pi forum: Dual boot with automatic revert to old partition for system upgrades via image?
Partition switching implemented by Rauc: Update Boot Partition in MBR
A Mender related post: Updating Raspberry Pi boot firmware files using Yocto Project and Mender

Possible Way Forward

The new tryboot.txt feature could eventually remove the need of U-Boot. A Mender state script would then copy the relevant files (dtb/kernel/initrd) to a location on the boot partition. Further modifications would be needed to make Mender interact with the tryboot.txt feature instead of U-Boot.
As an alternative U-Boot could remain in place and do a transparent handling of the tryboot.txt feature for Mender.

[lueschem]

On the Raspberry Pi 4 the MAX_RESTARTS option might be useful. This option helps e.g. if an invalid start_file option is selected.

[lueschem]

The following tryboot.txttriggered using sudo reboot '0 tryboot' resulted in a successful boot on a Raspberry Pi 4:

# needs to be 8.3 format and in top level folder
start_file=p3start4.elf
fixup_file=p3fixup4.dat

# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_64bit=1

enable_uart=1

kernel=vmlinuz-5.10.17-v8+
os_prefix=p3/

The kernel command line under p3/cmdline.txt was setup as follows:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p3 rw rootfstype=ext4 elevator=deadline fsck.repair=yes panic=10 rootdelay=2

panic=10 rootdelay=2 makes sure that the system automatically reboots in case there is an issue with the rootfs.

[lueschem]

Mender u-boot interactions:

rollback:

"mender_boot_part":     nextPartition,
"mender_boot_part_hex": nextPartitionHex,
"upgrade_available":    "0",

install update:

"upgrade_available":    "1",
"mender_boot_part":     inactivePartition,
"mender_boot_part_hex": inactivePartitionHex,
"bootcount":            "0",

commit:

"upgrade_available": "0"

[lueschem]

Manual interaction example:

pi@raspberry:~$ cat install 
upgrade_available 1
mender_boot_part 4 
mender_boot_part_hex 4
bootcount 0
pi@raspberry:~$ cat install | sudo bash -x fw_setenv -s -
...

[lueschem]

The implementation details can be found here:
https://www.get-edi.io/Debian-Bullseye-Upgrade-for-the-Raspberry-Pi/#new-bootloader-integration-for-the-pi-4

[timg236]

I just spotted this, in-case it helps anyone there are some extensions in the latest firmware/bootloader that should make A/B booting a bit easier.
https://www.raspberrypi.com/documentation/computers/config_txt.html#autoboot-txt

[lueschem]

I just spotted this, in-case it helps anyone there are some extensions in the latest firmware/bootloader that should make A/B booting a bit easier. https://www.raspberrypi.com/documentation/computers/config_txt.html#autoboot-txt

Many thanks for letting us know!

This new feature can indeed make the A/B booting slightly easier and a bit more robust. Considering the implementation within edi-pi I would have to figure out how I could do this transition without breaking existing installations.

As a general remark: tryboot really works great. I have done plenty of A/B updates over the past 12 months and I never had an issue!