patina_boot: Add partition file-read helper#1495
Closed
kat-perez wants to merge 9 commits into
Closed
Conversation
…DevicePartnership#1225) Adds BootOrchestration component, simple console discovery, simple BootOption Config - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [x] Includes documentation? QEMU Platform Integration: - Q35 - SBSA N/A
… boot options (OpenDevicePartnership#1272) ## Description Add hotkey detection support to the boot orchestrator, allowing platforms to configure alternate boot options that are used when a hotkey (e.g., F12) is pressed during boot. Changes: - Add `detect_hotkey()` helper function to check for hotkey press via SimpleTextInput protocol - Add `hotkey_devices` field and `with_hotkey_device()` builder to `BootOptions` - Update `BootOrchestrator` to use alternate boot options when hotkey is detected --- - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Unit tests for `detect_hotkey()` (no input handles case) - Unit tests for `hotkey_devices` config (single device, multiple devices, combined with hotkey) - `cargo test -p patina_boot` passes ## Integration Instructions Platforms can configure hotkey boot options: ```rust BootOptions::new() .with_device(primary_device) .with_hotkey(0x16) // F12 scancode .with_hotkey_device(alternate_device) ``` Closes OpenDevicePartnership#1228
…e_system_table (OpenDevicePartnership#1284) Release SYSTEM_TABLE lock (TPL_NOTIFY) before accessing ComponentDispatcher (TPL_APPLICATION) to avoid TPL violation. PR OpenDevicePartnership#1225 lowered ComponentDispatcher from TPL_NOTIFY to TPL_APPLICATION to allow components to use boot services, but this created a conflict when initialize_system_table held SYSTEM_TABLE while setting boot/runtime services on ComponentDispatcher. Fix: Extract boot/runtime services pointers while holding SYSTEM_TABLE lock, then release it before accessing ComponentDispatcher. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? - Unit tests pass - QEMU Q35 boots without TPL violation panic N/A
…ion (OpenDevicePartnership#1290) Add support for expanding partial (short-form) device paths to full device paths by matching against the device topology. - Add `is_partial_device_path()` to detect partial paths (start with Media/Messaging nodes instead of Hardware/ACPI) - Add `expand_device_path()` to find matching full paths by enumerating device handles - Wire expansion into `boot_from_device_path()` for transparent handling - Currently supports HardDrive nodes with GPT partition signature matching This enables booting from Boot#### variables containing partial device paths like `HD(1,GPT,<GUID>)\EFI\BOOT\BOOTX64.EFI`. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? - Unit tests for `is_partial_device_path()`, `expand_device_path()`, and signature matching - `cargo test -p patina_boot` passes (32 tests) - QEMU Q35 platform test passes N/A Closes OpenDevicePartnership#1280
…stration design (OpenDevicePartnership#1333) ## Description Refactors `patina_boot` from a monolithic `BootOrchestrator` component + `Config<BootOptions>` pattern to a trait-based design: - **`BootOrchestrator` trait** — defines the boot flow interface with `execute() -> Result<!, EfiError>`, enforcing at the type level that successful boot never returns - **`BootDispatcher`** — the Patina component that installs the BDS architectural protocol and delegates to a `BootOrchestrator` implementation - **`SimpleBootManager`** — a default `BootOrchestrator` implementation for platforms with straightforward boot topologies - **`BootConfig`** — unified boot configuration (replaces previous `BootOptions` + `SimpleBootConfig` split), requires at least one device at construction (compile-time enforcement) Also updates `helpers.rs` imports from removed `uefi_protocol::device_path` to `device_path::paths`/`device_path::node_defs`. `patina_dxe_core` changes (image handle plumbing) split out to OpenDevicePartnership#1374. - [x] Impacts functionality? - [ ] Impacts security? - [x] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested 1. Unit tests: 35 pass (`cargo test -p patina_boot`) 2. Integration tested on QEMU Q35 — all components dispatched, BDS phase ran, boot options attempted, failure handler fired correctly 3. CI: fmt, clippy, all platforms pass ## Integration Instructions Update boot orchestration usage from: ```rust use patina_boot::{component::BootOrchestrator, config::BootOptions}; // In configs(): add.config(BootOptions::new()...); // In components(): add.component(BootOrchestrator); ``` To: ```rust use patina_boot::{BootDispatcher, SimpleBootManager, config::BootConfig}; add.component(BootDispatcher::new(SimpleBootManager::new( BootConfig::new(primary_device_path()) .with_device(fallback_device_path()) .with_hotkey(0x16) .with_hotkey_device(usb_device_path()) .with_failure_handler(|| { /* ... */ }), ))); ```
…penDevicePartnership#1375) ## Description Rewrite `discover_console_devices()` from a stub into a full implementation that enumerates console protocol handles, builds multi-instance device paths, and writes `ConIn`, `ConOut`, and `ErrOut` UEFI global variables via `SetVariable`. - Adds `EFI_GLOBAL_VARIABLE` GUID to `patina::guids` - Adds `build_multi_instance_device_path()` helper for constructing multi-instance device paths from protocol handles - Updates `is_partial_device_path()` to recognize FV/FvFile paths as non-partial - Includes get_variable readback verification with device path display logging Depends on OpenDevicePartnership#1333. Closes OpenDevicePartnership#1230 - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested Verified on QEMU Q35 with VGA enabled. Console variables written and read back successfully: - ConIn: 24 bytes (SimpleTextInput) - ConOut: 60 bytes (SimpleTextOutput + GOP) - ErrOut: 30 bytes (SimpleTextOutput) ## Integration Instructions N/A
…with DxeServices (OpenDevicePartnership#1422) ## Description Interleave controller connection with DXE driver dispatch during device enumeration. Connecting controllers can discover new firmware volumes (e.g., PCI option ROMs) that contain drivers for devices behind that controller. Those drivers must be dispatched before the next round of enumeration, otherwise the devices they serve will not be found. `SimpleBootManager` uses `interleave_connect_and_dispatch()` to alternate between connecting controllers and dispatching newly-discovered drivers until both stabilize. The `DxeDispatch` service trait (from OpenDevicePartnership#1421) is consumed via dependency injection. Note: `interleave_connect_and_dispatch()` currently uses `connect_all()` which connects every controller on every round. This is functional but inefficient for platforms with large device topologies — a future optimization could connect only newly-discovered controllers. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Built SBSA DXE core binary with `BootDispatcher` + `SimpleBootManager` replacing TianoCore BdsDxe - Booted Windows ARM64 under QEMU SBSA-ref emulation with Patina BDS handling the full boot flow - Verified interleaving: controller connection discovered AHCI device, partial device path expanded to full path, Windows bootloader loaded, ExitBootServices completed ## Integration Instructions Depends on OpenDevicePartnership#1421 (`DxeDispatch` service trait) for platform binary integration. Remove TianoCore `BdsDxe.inf` from platform DSC/FDF since the `BootDispatcher` provides the BDS architectural protocol.
…penDevicePartnership#1447) ## Description Add `discover_boot_options()` helper to `patina_boot::helpers` that reads UEFI `BootOrder` and `Boot####` variables to build a `BootConfig` from standard UEFI boot options. This enables any `BootOrchestrator` implementation that consumes `BootConfig` to use UEFI-compliant boot variables instead of requiring platforms to hardcode device paths. The function: - Reads `BootOrder` to determine boot attempt order - Parses each `Boot####` `EFI_LOAD_OPTION` structure to extract device paths - Filters out inactive boot options (`LOAD_OPTION_ACTIVE`) - Gracefully skips unreadable or malformed entries - Returns a populated `BootConfig` with discovered devices in priority order --- - [ ] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Unit tests covering: single/multiple boot options, inactive option filtering, unreadable variable handling, truncated load option data, empty BootOrder, and hex variable name generation - Integration tested with patina-dxe-core-qemu `feature/patina-boot` on QEMU Q35 — full boot to UEFI Shell 2.0 ## Integration Instructions Platforms can call `discover_boot_options()` with runtime services to automatically populate a `BootConfig` from UEFI boot variables instead of constructing device paths manually. This works with any `BootOrchestrator` implementation that accepts a `BootConfig`: ```rust let config = discover_boot_options(&runtime_services)?; add.component(BootDispatcher::new(SimpleBootManager::new(config))); ```
Adds read_partition_file(boot_services, device_path, file_path) to patina_boot::helpers. Resolves the partition handle via locate_device_path against EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, opens the volume, opens the file at the given partition-relative path for reading, slurps the contents into a Vec<u8>, and closes the handles before returning. The path is interpreted as a partition-relative UEFI file path (e.g. "\\EFI\\BOOT\\BOOTX64.EFI"). It's converted to UCS-2 with a trailing null and passed to the protocol's open call. Inner FFI dispatch is split into an unsafe helper following the existing detect_hotkey_from_handles / lock_partition_write_inner pattern. Cleanup is consolidated into a close_both closure used on every error path. Closes OpenDevicePartnership/odp-platform-common#66.
Contributor
⏳ QEMU Validation In ProgressA new QEMU validation run has started. Results from any previous run(s) are now outdated.
Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/25328578606 This comment was automatically generated by the Patina QEMU PR Validation workflow. |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
1 similar comment
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
kat-perez
force-pushed
the
feature/patina-boot
branch
from
d9c454f to
adc19cd
Compare
Contributor
Author
|
Closing in favor of OpenDevicePartnership/patina-components#12, which moves this helper into the new |
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.
Description
Adds
read_partition_file(boot_services, device_path, file_path)topatina_boot::helpers. Resolves the partition handle vialocate_device_pathagainstEFI_SIMPLE_FILE_SYSTEM_PROTOCOL, opens the volume, opens the file at the given partition-relative path for reading, slurps the contents into aVec<u8>, and closes the handles before returning.The path is interpreted as a partition-relative UEFI file path (e.g.
\EFI\BOOT\BOOTX64.EFI). It's converted to UCS-2 with a trailing null internally.Closes OpenDevicePartnership/odp-platform-common#66.
How This Was Tested
cargo make allIntegration Instructions