RFC: Boot Orchestration Component#1013
RFC: Boot Orchestration Component#1013kat-perez wants to merge 1 commit intoOpenDevicePartnership:mainfrom
Conversation
d8f1790 to
6c56b0a
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
6c56b0a to
609504f
Compare
os-d
left a comment
There was a problem hiding this comment.
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.
ec79517 to
db8fc97
Compare
|
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 |
260e43c to
30ec240
Compare
30ec240 to
43371f5
Compare
43371f5 to
7a68005
Compare
7a68005 to
b90bc0c
Compare
b90bc0c to
411136c
Compare
519829e to
33ec729
Compare
67aed20 to
cc6b1ec
Compare
✅ QEMU Validation PassedAll QEMU validation jobs completed successfully.
Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/23929052276 Boot Time to EFI Shell
Dependencies
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` |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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 | |
There was a problem hiding this comment.
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.
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.
How This Was Tested
N/A
Integration Instructions
N/A