You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm digesting the implications of the tryboot_a_b update flow, and it's becoming clear that it is more designed for boot systems that depend on a ramdisk. Since the ramdisk would be named the same on the A/B boot partitions, it doesn't need any differences in cmdline.txt, and init logic within it can then use the device tree's chosen/bootloader properties to drive its dynamic logic.
But for systems that would prefer not to have a separate ramdisk, they are currently required to modify their kernel cmdline appropriately for the A/B partition that is being booted, and set up for that during their update process along with modifying the autoboot.txt.
I can think of two possible ways that the rpi firmware could support this use-case:
Support the cmdline setting in the autoboot.txt in addition to the config.txt. This way, the A/B boot partitions could be identical and contain both cmdline_A.txt and cmdline_B.txt files with the appropriate root= values.
Support a [boot_partition=n] filter in config.txt that would be filled by the active configuration from the autoboot.txt logic. This way, the config.txt could conditionally point to an appropriate cmdline*.txt next to it.
The text was updated successfully, but these errors were encountered:
I'm digesting the implications of the
tryboot_a_b
update flow, and it's becoming clear that it is more designed for boot systems that depend on a ramdisk. Since the ramdisk would be named the same on the A/B boot partitions, it doesn't need any differences incmdline.txt
, and init logic within it can then use the device tree'schosen/bootloader
properties to drive its dynamic logic.But for systems that would prefer not to have a separate ramdisk, they are currently required to modify their kernel cmdline appropriately for the A/B partition that is being booted, and set up for that during their update process along with modifying the
autoboot.txt
.I can think of two possible ways that the rpi firmware could support this use-case:
cmdline
setting in theautoboot.txt
in addition to theconfig.txt
. This way, the A/B boot partitions could be identical and contain bothcmdline_A.txt
andcmdline_B.txt
files with the appropriateroot=
values.[boot_partition=n]
filter inconfig.txt
that would be filled by the active configuration from theautoboot.txt
logic. This way, theconfig.txt
could conditionally point to an appropriatecmdline*.txt
next to it.The text was updated successfully, but these errors were encountered: