Add patina_sre crate (System Recovery Environment boot orchestrator)#95
Closed
kat-perez wants to merge 1 commit into
Closed
Add patina_sre crate (System Recovery Environment boot orchestrator)#95kat-perez wants to merge 1 commit into
kat-perez wants to merge 1 commit into
Conversation
Adds patina_sre at uefi/crates/patina_sre/ implementing
patina_boot::BootOrchestrator for platforms shipping a System Recovery
Environment alongside the main OS. The skeleton implements the normal
boot path only:
1. interleave connect+dispatch (10-round cap)
2. extra connect_all before EndOfDxe so PartitionDxe can bind GPT
child handles during the open driver-binding window
3. signal EndOfDxe
4. discover console devices
5. write-lock boot partition (currently a log::warn! stub pending
odp-platform-common#61's patina_boot::partition helper)
6. discover_boot_options + iterate each entry through
signal_ready_to_boot + boot_from_device_path
7. fall back to the constructor-provided main_os_path if discovery
yields nothing
8. signal_ready_to_boot + boot the fallback path
The crate re-exports DevicePathBuf + EndEntire from its patina source
so callers (e.g. surface_patina_intel/patina_bin) can construct the
constructor's device-path arguments without picking up a different
patina source (which would break trait coherence).
Hotkey-to-SRE entry, WIM-to-RAM-disk boot, and capsule pre-boot hook
are tracked separately and will layer onto this skeleton.
Verified end-to-end on Maa hardware (Kioxia KBG8 NVMe, NVMe 2.0,
CAP.BPS=1) via surface_patina_intel feature branch — BootDispatcher
dispatches, SreBootManager.execute() runs the full BDS phase,
discover_boot_options finds the Windows Boot Manager Boot####,
expand_device_path resolves the short-form HD(GPT,GUID) path against
the live device topology, and bootmgfw.efi loads + starts cleanly.
Closes #91.
5 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a new UEFI Rust crate patina_sre that provides SreBootManager, a reference patina_boot::BootOrchestrator implementation intended to orchestrate the “normal boot” path for platforms that ship an SRE alongside the main OS.
Changes:
- Introduces
SreBootManagerwith a connect/dispatch interleave loop, BDS-phase signaling, console discovery, Boot#### option enumeration, and a fallback main OS device-path boot. - Adds unit tests validating the interleave loop behavior and trait-object constructibility.
- Adds crate scaffolding (manifest, README, pinned toolchain/rustfmt config, exports for device-path types).
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| uefi/crates/patina_sre/src/sre_boot_manager.rs | Implements the boot orchestration logic and unit tests for interleave/connect/dispatch and boot option iteration. |
| uefi/crates/patina_sre/src/lib.rs | Crate entrypoint; exports SreBootManager and re-exports device-path types for downstream type-identity. |
| uefi/crates/patina_sre/Cargo.toml | Declares crate metadata and dependencies (incl. git deps on patina_boot and patina). |
| uefi/crates/patina_sre/README.md | Documents intended boot sequence and basic integration snippet. |
| uefi/crates/patina_sre/rust-toolchain.toml | Pins nightly toolchain and UEFI targets for this crate. |
| uefi/crates/patina_sre/rustfmt.toml | Sets rustfmt configuration for the crate. |
| uefi/crates/patina_sre/.gitignore | Ignores build artifacts and lockfile for this crate directory. |
| //! 4. Write-lock the NVMe boot partition (volatile, until power cycle) | ||
| //! — currently a stub pending `patina_boot::partition` (odp-platform-common#61) | ||
| //! 5. Signal `ReadyToBoot` | ||
| //! 6. Boot the main OS device |
| ); | ||
|
|
||
| // Try boot options discovered from the firmware's Boot#### EFI variables. | ||
| // The constructor's `main_os_path` is used only if discovery yields nothing. |
Comment on lines
+118
to
+121
| match helpers::boot_from_device_path(boot_services, image_handle, device_path) { | ||
| Ok(()) => log::warn!("Boot option returned control, trying next..."), | ||
| Err(_) => log::warn!("Boot option failed, trying next..."), | ||
| } |
| } | ||
| match helpers::boot_from_device_path(boot_services, image_handle, &self.main_os_path) { | ||
| Ok(()) => log::warn!("Main OS boot returned control"), | ||
| Err(_) => log::warn!("Main OS boot failed"), |
| 4. Write-lock the NVMe boot partition *(pending — TODO referencing | ||
| [odp-platform-common#61](https://github.com/OpenDevicePartnership/odp-platform-common/issues/61))* | ||
| 5. Signal `ReadyToBoot` | ||
| 6. Boot the main OS device |
This was referenced May 27, 2026
Contributor
Author
|
Superseded by #97 — same logical change rebased onto a personal fork (kat-perez/odp-platform-common) so subsequent review-fix commits can land without hitting the upstream feature-branch ruleset. The new PR already folds in the Copilot review feedback from this one. |
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
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.
Summary
Adds
patina_sreatuefi/crates/patina_sre/— implementspatina_boot::BootOrchestratorfor platforms shipping a System Recovery Environment alongside the main OS.The skeleton implements the normal boot path:
connect_allbefore EndOfDxe so PartitionDxe can bind GPT child handles during the open driver-binding windowlog::warn!stub pending Add partition write-lock helper to patina-boot #61'spatina_boot::partitionhelper)discover_boot_options+ iterate eachBoot####throughsignal_ready_to_boot+boot_from_device_pathmain_os_pathif discovery yields nothingThe crate re-exports
DevicePathBuf+EndEntirefrom its own patina source so callers (e.g.surface_patina_intel/patina_bin) can construct the constructor's device-path arguments without picking up a different patina (which would break trait coherence).Hotkey-to-SRE entry, WIM-to-RAM-disk boot, and capsule pre-boot hook are tracked separately (#50–53, #63–73) and will layer onto this skeleton.
Verification
End-to-end on Maa Intel Surface hardware (Kioxia KBG8 NVMe, NVMe 2.0, CAP.BPS=1, BPSZ=8192×128KiB) via paired
surface_patina_intelfeature branch:SreBootManager::execute()runs the full BDS phasediscover_boot_optionsfinds the Windows Boot Manager Boot####expand_device_pathresolves the short-form HD(GPT,GUID) path against the live device topologybootmgfw.efiloads + starts cleanly → Windows bootscargo test6/6 passing.Test plan
cargo test)x86_64-unknown-uefiFollow-ups
patina_boot::partition::lock_partition_writeso the write-lock stub becomes a real callmain_os_pathdoesn't have to rely on discovery fallbackNotes for reviewers
This is the first end-to-end exercise of
patina_boot::BootDispatcheron real hardware. patina-qemu Q35 doesn't currently register BootDispatcher, so any bugs uncovered are from this real-hardware integration path (e.g., partition discovery timing/order).The 5 stale
feature/patina-sre-crate-*branches in the repo are the WIP iteration log from working out the boot path on hardware. They can't be deleted via API due to the branch ruleset — admins, please batch-delete them via the web UI when convenient.Closes #91.