fwmanager: Add per-device slot layout to the device-table schema - #394
Open
chrysh wants to merge 3 commits into
Open
fwmanager: Add per-device slot layout to the device-table schema#394chrysh wants to merge 3 commits into
chrysh wants to merge 3 commits into
Conversation
Slot topology becomes data on DeviceConfig: a table of SlotDesc entries (writable/bootable/optional Recovery role) plus a RecoveryPolicy. No layout shape is named anywhere — plain A/B, A/B+golden, or single+golden fall out of what the board table declares, and "golden" is the recovery role plus writable:false rather than a name. An empty layout is legal for devices that own their boot selection (the PLDM archetype) but forces EscalateOnly, since it has no ladder rungs. There is no cap on the number of slots a device may declare. validate() gains the layout rules: unique slot ids, at most one recovery-role slot (which must be bootable), a non-empty layout needs a bootable slot, and a Ladder policy needs a second bootable rung. The mock board exercises both shapes: the bmc declares plain A/B with Ladder, the nic an empty layout with EscalateOnly. Signed-off-by: Christina Quast <christina.quast@9elements.com>
A passive downstream device (a symbiont whose flash the eRoT fronts, e.g. a CPLD on SPI) produces no boot evidence: no liveness signal exists, so neither existing commit gate is declarable honestly, and it has no boot checkpoints to wait on. CommitPolicy gains None — the device is released blind and a staged image is committed once readback verification passes. validate() ties the ends together: an empty checkpoint list is legal only under CommitPolicy::None. The converse stays legal — a device may signal boot progress for recovery purposes while committing unconditionally. The mock board gains the archetype: a cpld with no checkpoints and CommitPolicy::None whose flash still carries a full layout — A/B plus a golden slot, with Ladder recovery walked on verification failures only, since no boot signal exists. Signed-off-by: Christina Quast <christina.quast@9elements.com>
4 tasks
Review on the slot-layout PR asked whether slot ids are indices or arbitrary tokens. They are tokens: unique within one device's table, with no contiguity or ordering requirement — ladder order comes from table declaration order. The doc comment said "position", which suggested index semantics; say token explicitly instead. Refs: #1 Signed-off-by: Christina Quast <christina.quast@9elements.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Slot topology becomes data on
DeviceConfig: each device declares a table ofSlotDescentries (writable/bootable/optionalRecoveryrole) plus aRecoveryPolicy. No layout shape is named anywhere — plain A/B, A/B+golden, or single+golden fall out of what the board table declares; "golden" is the recovery role pluswritable: false, not a name. There is no cap on the number of slots. An empty layout is legal for devices that own their boot selection (the PLDM archetype) but forcesEscalateOnly, since it has no ladder rungs.validate()gains the layout rules: unique slot ids, at most one recovery-role slot (which must be bootable), a non-empty layout needs a bootable slot, and aLadderpolicy needs a second bootable rung.The second commit admits passive devices: a symbiont whose flash the eRoT fronts (e.g. a CPLD on SPI) produces no boot evidence, so
CommitPolicygainsNone— released blind, a staged image is committed once readback verification passes. An empty checkpoint list is legal only under this policy. The mock board now exercises all three archetypes:bmc(direct-flash, A/B,Ladder),nic(self-updating, no slots,EscalateOnly), andcpld(passive, A/B+golden,Ladderwalked on verification failures only).Part of 9elements#1 (partitioning schemes; verification keys remain open there).