[FEAT] Support `tryboot` helpers without ramdisk

Open
#1,940 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
raspberry-pi
Domain
embedded-iot, operating-systems

Research direction

Start by reading the linked tryboot A/B booting documentation and the issue's references to autoboot.txt, config.txt, and cmdline*.txt. Compare the two proposed firmware approaches for systems without a ramdisk, then define which behavior is required and how it can be verified for both A/B partitions.

Written by the indexing model from the issue text.

Description

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:

  1. 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.
  2. 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.
Dominant language
No language data
Stars
5.6k
Forks
1.7k
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raspberrypi/firmware

All issues in raspberrypi/firmware

Similar issues

More Embedded & IoT issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.