Add boot monitor, move HalBootController into hal-adapters directory#20
Open
chrysh wants to merge 4 commits into
Open
Add boot monitor, move HalBootController into hal-adapters directory#20chrysh wants to merge 4 commits into
chrysh wants to merge 4 commits into
Conversation
embediver
reviewed
Jul 20, 2026
| /// into device implementations. | ||
| pub trait BootMonitor { | ||
| /// The error type reported by this device's boot monitor. | ||
| type Error: core::fmt::Debug; |
chrysh
force-pushed
the
add-boot-reset-control_v2
branch
from
July 21, 2026 12:04
e10f4c6 to
daa9aa7
Compare
chrysh
added a commit
that referenced
this pull request
Jul 22, 2026
Split the HAL-backed adapter out of fwmanager-api so the api crate is a dependency-free leaf holding only the BootControl capability contract, matching the layout of #20. HalBootControl and the BootError wrapper move to the new fwmanager-hal-adapters crate, which depends on //hal/blocking and the api crate. Drop the system_control::Error bound from BootControl::Error, keeping core::error::Error only: requiring the HAL error trait in the api crate would keep the HAL dependency the split is meant to remove. BootError still exposes kind(), and the generic-consumer test now recovers the error category by downcasting the dyn core::error::Error instead of relying on the removed bound. Add impl From<E> for BootError<E> so implementations forwarding HAL calls can use ? instead of .map_err(BootError), and switch HalBootControl over to it. Add api-side tests proving the contract stays implementable with no HAL in sight, and cover the release error path in the adapter. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
chrysh
added a commit
that referenced
this pull request
Jul 22, 2026
Split the HAL-backed adapter out of fwmanager-api so the api crate is a dependency-free leaf holding only the BootControl capability contract, matching the layout of #20. HalBootControl and the BootError wrapper move to the new fwmanager-hal-adapters crate, which depends on //hal/blocking and the api crate. Drop the system_control::Error bound from BootControl::Error, keeping core::error::Error only: requiring the HAL error trait in the api crate would keep the HAL dependency the split is meant to remove. BootError still exposes kind(), and the generic-consumer test now recovers the error category by downcasting the dyn core::error::Error instead of relying on the removed bound. Add impl From<E> for BootError<E> so implementations forwarding HAL calls can use ? instead of .map_err(BootError), and switch HalBootControl over to it. Add api-side tests proving the contract stays implementable with no HAL in sight, and cover the release error path in the adapter. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
leongross
pushed a commit
to OpenPRoT/openprot
that referenced
this pull request
Jul 23, 2026
Split the HAL-backed adapter out of fwmanager-api so the api crate is a dependency-free leaf holding only the BootControl capability contract, matching the layout of 9elements#20. HalBootControl and the BootError wrapper move to the new fwmanager-hal-adapters crate, which depends on //hal/blocking and the api crate. Drop the system_control::Error bound from BootControl::Error, keeping core::error::Error only: requiring the HAL error trait in the api crate would keep the HAL dependency the split is meant to remove. BootError still exposes kind(), and the generic-consumer test now recovers the error category by downcasting the dyn core::error::Error instead of relying on the removed bound. Add impl From<E> for BootError<E> so implementations forwarding HAL calls can use ? instead of .map_err(BootError), and switch HalBootControl over to it. Add api-side tests proving the contract stays implementable with no HAL in sight, and cover the release error path in the adapter. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
Member
|
@chrysh, this needs a rebase |
Add the Boot Orchestrator's observation capability: the BootMonitor trait (boot_status) reporting boot liveness as BootStatus lands in the api leaf crate, and GpioBootMonitor, binding one HAL GpioPort input line to a managed device's boot-complete signal, lands in the hal-adapters crate as gpio_boot_monitor.rs. Liveness only: it reports that a device came up, never what booted (attestation is a separate step), and a stuck boot is caught by the orchestrator's timeout, not by this enum. Includes host unit tests covering active-high and active-low polarity, that an unrelated line is ignored, that a deasserted line reads as Booting rather than a failure, and that a port read error surfaces through BootMonitor unchanged. Closes: #6 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Christina Quast <christina.quast@9elements.com>
Align BootMonitor::Error with the BootControl contract: require core::error::Error instead of Debug. GpioBootMonitor satisfies it through the new MonitorError adapter, which keeps kind() reachable and converts via From so ? keeps working. Add api-side BootMonitor tests proving the contract stays implementable with no HAL in sight, that a device that never reports Booted is the orchestrator's timeout rather than an error, and that errors surface with Display through the generic seam. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com> Claude-Session: https://claude.ai/code/session_012zYYeyGyq4xYg1TGSjNyAJ
Two contract gaps in the BootMonitor seam: An empty ready_pin mask is vacuously contained in every input sample, so a misbound GpioBootMonitor would report every device Booted from the moment reset is released. Fail at construction instead: new() now panics on an empty mask. Boot-complete is one line by definition; multi-line masks are documented as unsupported (PinMask offers no way to reject them at construction). Nothing said who clears a hardware boot latch across reset cycles, so evidence from a previous boot could read as Booted after the device re-enters reset. Make it a stated BootMonitor contract: status describes the current boot cycle, latches are cleared by the reset path (not the observer, which would let a read race a reset), and the GPIO adapter documents the platform wiring this implies. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com> Claude-Session: https://claude.ai/code/session_012zYYeyGyq4xYg1TGSjNyAJ
chrysh
marked this pull request as draft
July 23, 2026 14:51
MonitorError's Display renders only the generic GpioErrorKind, and it had no source(), so once a GPIO read error crossed the BootMonitor seam the concrete HAL error — and whatever pin/hardware context the implementation put in it — was unreachable. Debugging a production boot monitor failure would start and end at 'HardwareFailure'. GpioError only guarantees Debug, so the HAL error cannot be the source itself. Wrap it in GpioCause, a thin adapter whose Display renders the full concrete error, and hand that out from source(). The orchestrator now gets a real chain — kind at the top, implementation detail at the tail — and a consumer that knows the adapter can downcast the source to GpioCause<E> (or call inner()) to recover the typed error. Requires P::Error: 'static, which plain-data error types always satisfy. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com> Claude-Session: https://claude.ai/code/session_012zYYeyGyq4xYg1TGSjNyAJ
chrysh
marked this pull request as ready for review
July 23, 2026 15:22
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
3 participants
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.
This patch can only be applied after the boot reset control patch is done.