U-Boot boot protocol should be a standalone process
Similar to how we should break out the Raspberry Pi and GRUB boot protocol out to a separate process, we should move all U-Boot handling to a dedicated process, with separate life-cycle, bus name and permissions. This has the following consequences:
- u-boot boot protocol can be used together with other boot protocols (separate bus names)
- u-boot boot protocol process can be forbidden to talk to the network but allowed to write to the boot partition
- u-boot boot protocol can grow custom APIs, not shared with pi-boot or GRUB, that express unique properties, allowing reporting tools to accurately describe the state and relationship of this part of the boot stack.
- u-boot boot protocol can express ability to update boot assets and inform if the update is atomic, possible to roll-back or protected with A/B mechanism.
This is a background task, it should be picked up when convenient without sacrificing the rest of the roadmap.