Skip to content

RFC: Boot Orchestration Component#1013

Open
kat-perez wants to merge 1 commit intoOpenDevicePartnership:mainfrom
kat-perez:rfc-boot-manager
Open

RFC: Boot Orchestration Component#1013
kat-perez wants to merge 1 commit intoOpenDevicePartnership:mainfrom
kat-perez:rfc-boot-manager

Conversation

@kat-perez
Copy link
Copy Markdown
Contributor

@kat-perez kat-perez commented Nov 4, 2025

Description

This RFC proposes modular components for UEFI spec compliant boot functionality in Patina firmware. Platforms can
use reference implementations for console initialization, boot option discovery, and boot orchestration,
or implement custom boot flows using the provided library functions.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?
  • Creates a new crate?

How This Was Tested

N/A

Integration Instructions

N/A

@github-actions github-actions bot added impact:non-functional Does not have a functional impact type:documentation Improvements or additions to documentation labels Nov 4, 2025
@codecov
Copy link
Copy Markdown

codecov bot commented Nov 4, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Copy link
Copy Markdown
Contributor

@os-d os-d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The biggest part of BDS that I did not see enumerated in this RFC is the connect management, driving binding protocols, etc. That requires careful thought as it is another form of driver dispatch that is unique to the BDS phase.

I think that before we move this forward, we need to include what that story is.

@makubacki makubacki added the rfc A request-for-change proposal label Nov 4, 2025
@kat-perez kat-perez force-pushed the rfc-boot-manager branch 5 times, most recently from ec79517 to db8fc97 Compare November 6, 2025 14:50
@kat-perez
Copy link
Copy Markdown
Contributor Author

i've changed the design quite a bit, added more goals and requirements to further constrain the design to be limited to the most fundamental Patina components that can achieve a successful boot

@kat-perez kat-perez changed the title RFC: Boot Manager RFC: Boot Manager Components Nov 6, 2025
@kat-perez kat-perez requested review from kuqin12 and os-d November 6, 2025 15:15
@patina-automation
Copy link
Copy Markdown
Contributor

patina-automation bot commented Mar 25, 2026

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Q35 is only built on Windows hosts (QEMU boot is disabled due to a QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/23929052276

Boot Time to EFI Shell

Platform Elapsed
Q35 (Linux Host) 28.2s
SBSA (Linux Host) 1m 6s

Dependencies

Repository Ref
patina e076e51
patina-dxe-core-qemu 8a232bb
patina-fw-patcher b08d6ff
patina-qemu firmware v3.0.0
patina-qemu build script b42c7c2

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.


## Motivation

Most Patina platforms require UEFI-compliant boot functionality: discovering boot options from `Boot####`/`BootOrder`
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how detailed you want to be here. There is a BootNext in addition to the Boot#### and BootOrder. It's a UINT16 to force a specific path on the next reset.

**Console Variables**:

- Discover console devices via GOP (graphics) and SimpleTextInput protocols
- Populate `ConIn`, `ConOut`, and `ErrOut` variables with console device paths
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are discussing the ConIn/ConOut/ErrOut variables, you might want to also include the ConInDev/ConOutDev/ErrOutDev variables that list all found options each boot.

https://github.com/tianocore/edk2/blob/87e486f622c5eaa0bee04f090b5c543466d6178b/MdePkg/Include/Guid/GlobalVariable.h#L75

The non 'dev' vars are usually the default selection and are saved in NVRAM. The 'dev' vars are usually volatile and created each boot upon discovery.

- **`Key####` hotkey variables**: Full UEFI-compliant hotkey management via `Key####`
variables, extending the current scancode-based `detect_hotkey()` to read hotkey
configuration from UEFI variables.
- **Platform recovery options**: `PlatformRecovery####` variable support for
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be expanded to maybe be a hierarchy mechanism with a fallover? Try option 1, if fails, try option 2, if fails, try option 3, etc.? We talked about the recovery option which would be where we just have 2 options, but current platforms have several options; Windows boot path, Linux boot path, UEFI shell, PXE boot, USB boot, front page, etc.


Both `expand_device_path()` and `boot_from_device_path()` are provided to support different use cases:

| Function | Use Case |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, if you want to make tables a little more readable in edit mode, you don't need to make each line the same length.

This text:

| Title 1 Left Justified | Title 2 Centered | Title 3 Right Justified |
|---|:---:|---:|
| a | b | c |
| d | e | f |

Produces this:

Title 1 Left Justified Title 2 Centered Title 3 Right Justified
a b c
d e f

The separator only needs 3 dashes and you can put a colon ':' on both sides to center the column or on the right to right align.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

impact:non-functional Does not have a functional impact rfc A request-for-change proposal type:documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants