Add patina_sre crate (System Recovery Environment boot orchestrator)#97
Open
kat-perez wants to merge 3 commits into
Open
Add patina_sre crate (System Recovery Environment boot orchestrator)#97kat-perez wants to merge 3 commits into
kat-perez wants to merge 3 commits into
Conversation
Adds patina_sre at uefi/crates/patina_sre/ — implements
patina_boot::BootOrchestrator for platforms shipping a System Recovery
Environment alongside the main OS. The skeleton implements the normal
boot path:
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. boot-partition write-lock (currently a log::warn! stub pending
odp-platform-common#61's patina_boot::partition helper)
6. discover_boot_options + iterate each Boot#### entry through
signal_ready_to_boot + boot_from_device_path; logs the device path
and underlying error on each failure
7. fall back to the constructor-provided main_os_path if discovery
yields no entries OR fails
8. return EfiError::NotFound once every attempt is exhausted
The crate re-exports DevicePathBuf + EndEntire from 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 and will layer onto this skeleton.
Verified end-to-end on Maa Intel Surface hardware (Kioxia KBG8 NVMe,
NVMe 2.0, CAP.BPS=1) via the paired 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 OpenDevicePartnership#91.
kat-perez
requested review from
Copilot,
dymk,
maxperga-msft,
philgweber and
rogurr
4 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a new patina_sre crate that implements patina_boot::BootOrchestrator to drive the normal boot path on platforms that ship a System Recovery Environment. The crate covers controller-connect/dispatch interleaving, EndOfDxe + ReadyToBoot signalling, console discovery, Boot#### enumeration with a main_os_path fallback, and a stub for the boot-partition write-lock pending issue #61. Re-exports DevicePathBuf/EndEntire ensure callers share trait coherence with the patina source used internally.
Changes:
- Introduce
SreBootManagerorchestrator with interleaved connect+dispatch, BDS signalling,Boot####iteration, andmain_os_pathfallback. - Re-export
DevicePathBuf/EndEntirefrompatina_sreso downstream consumers stay on the samepatinasource. - Add crate scaffolding (Cargo.toml, README, rust-toolchain.toml, rustfmt.toml, .gitignore) and host-side unit tests for the interleave loop and trait bounds.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| uefi/crates/patina_sre/src/sre_boot_manager.rs | Core orchestrator implementation + unit tests for interleave loop and trait conformance. |
| uefi/crates/patina_sre/src/lib.rs | Crate root with no_std/feature flags and re-exports. |
| uefi/crates/patina_sre/README.md | Crate description and usage snippet. |
| uefi/crates/patina_sre/Cargo.toml | Package manifest with git deps for patina/patina_boot. |
| uefi/crates/patina_sre/rust-toolchain.toml | Pinned nightly-2025-12-12 with UEFI targets. |
| uefi/crates/patina_sre/rustfmt.toml | max_width = 120. |
| uefi/crates/patina_sre/.gitignore | Ignore target/ and Cargo.lock. |
rogurr
previously approved these changes
Jun 5, 2026
… -> RAM disk -> chainload)
Layers the SRE entry path onto the existing normal-boot skeleton. When the
Vol-Up + Power chord is registered at power-on (read via Surface
MS_BUTTON_SERVICES_PROTOCOL), SreBootManager::execute branches into the
BP recovery flow:
1. ConnectAll (priority-boot dispatch may run before BdsConnectAll)
2. Locate EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL
3. Probe Identify Controller MDTS to size LID 0x15 chunks; clamp to
[64 KiB, 512 KiB]; fall back to 64 KiB on probe failure
4. Read 1 GiB of BP1 via chunked Get Log Page LID=0x15 into a fresh
DRAM allocation (LPOL = 16 + bp_offset to skip the controller's
header preamble)
5. Register the allocation as a RAM disk via EFI_RAM_DISK_PROTOCOL
(VIRTUAL_DISK_GUID)
6. Connect the RAM disk handle so PartitionDxe/FAT bind
7. Build a full device path = RAM disk DP + FilePath(\EFI\Boot\bootx64.efi)
+ END, LoadImage + StartImage
On any failure the flow returns and execute falls through to the
existing normal boot path. BP write protection (lock/unlock) is
intentionally not touched; that's owned by the FMP capsule update flow.
The three protocol FFI shims (NvmExpressPassThru, RamDisk,
MsButtonServices) are inlined in bp_recovery.rs rather than pulled
from patina_boot helpers that aren't yet published (issues OpenDevicePartnership#63
HotkeySource trait, OpenDevicePartnership#65 RAM-disk binding, OpenDevicePartnership#66 partition file-read,
OpenDevicePartnership#67 install_ram_disk). The intent is to extract these into
patina_boot once the API shape is proven on hardware.
Tests: existing 6 unit tests still pass; both x86_64-unknown-uefi
and host builds compile clean.
Mirrors the hardware-validated C-side SRE flow shipped via Devices
PR 392564 (commit 48a7a6159c on platform/maa_900/sre).
… testability - 2 pure-function tests for build_file_path_node (byte layout) and device_path_size (END_ENTIRE walk). - 3 tests for detect_sre_hotkey covering protocol-absent (outer) and pressed / not-pressed / check-errors (inner via synthetic button protocol). - 4 tests for probe_max_transfer covering MDTS=7 -> 512 KiB cap, MDTS=0 -> READ_CHUNK_MAX, MDTS too low -> READ_CHUNK_MIN clamp, Identify failure -> READ_CHUNK_DEFAULT. - 2 tests for read_bp_via_log_page: single-chunk LPOL=header-offset + LSP/LID layout, and pass-thru failure propagation. - 3 tests for register_ram_disk: outer locate failure, inner success (base/size captured + sentinel DP returned), inner register failure. To make the protocol-touching functions testable, split detect_sre_hotkey and register_ram_disk into outer (BootServices-based locate) + inner (takes raw protocol pointer) functions. Mirrors the pattern already used in patina_boot::partition for the lock_partition_write helpers. All 23 tests pass; both x86_64-unknown-uefi and host targets compile.
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####entry throughsignal_ready_to_boot+boot_from_device_path; logs the device path and underlying error on each failuremain_os_pathif discovery yields no entries OR failsEfiError::NotFoundonce every attempt is exhaustedThe 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 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 fallback)Closes #91.