[lib][uefi] implement missing protocols required by GBL#512
Conversation
There was a problem hiding this comment.
Pull request overview
This PR extends the LK UEFI shim to satisfy additional protocol expectations from GBL by adding protocol implementations/stubs, expanding boot buffer allocation options, and improving boot service trace readability via protocol GUID names.
Changes:
- Added platform “open_*” hooks for GBL AVB, GBL Boot Control, and EFI RNG protocols, and wired them into
open_protocol/handle-location paths. - Extended
GblEfiBootMemoryProtocol::get_boot_bufferto support kernel/ramdisk/FDT buffer allocation. - Added protocol GUID → readable name mapping and improved boot service tracing/log formatting.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| lib/uefi/uefi_platform.h | Declares new protocol “open” helpers needed by the boot service provider. |
| lib/uefi/uefi_platform.cpp | Adds stub implementations for AVB/BootControl/RNG protocols and changes default DT selection behavior. |
| lib/uefi/memory_protocols.cpp | Adds additional boot buffer types and allocations for UEFI boot flows. |
| lib/uefi/boot_service_provider.h | Exposes protocol_name() and adds the AVB protocol GUID constant. |
| lib/uefi/boot_service_provider.cpp | Improves trace output with protocol names and implements singleton protocol handle discovery/allocation. |
| lib/uefi/blockio_protocols.h | Updates block device listing API to use caller-provided buffers. |
| lib/uefi/blockio_protocols.cpp | Implements the updated block device listing behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
zhangxp1998
force-pushed
the
master
branch
3 times, most recently
from
3ba8b2f to
fb01a5d
Compare
zhangxp1998
force-pushed
the
master
branch
2 times, most recently
from
1dda88c to
595f932
Compare
| if (selected_overlay != num_device_trees) { | ||
| device_trees[selected_overlay].selected = true; | ||
| } |
There was a problem hiding this comment.
why do we default to select the first overlay?
I think DT overlays should be selected by some criteria, like platform version / SOC name etc. Since we are not checking those, does it make more sense to select none overlays by default? or select ALL by default?
There was a problem hiding this comment.
The intent here is that this weak uefi_platform.cpp implementation is a QEMU-like reference implementation rather than a platform policy recommendation. QEMU normally does not provide overlay DTBs, so the exact overlay choice does not matter for the QEMU case.
For real OEM platforms, this hook is the place to filter and locate overlay DTBs from the input list using platform-specific criteria such as board/SOC/version. Selecting the first overlay here is just a simple reference behavior that shows where overlay selection happens; platform code should override it when the input can contain multiple meaningful overlays.
There was a problem hiding this comment.
Done in 2eee933a: simplified the selection logic with select_first_dtb(type), then use it to select the first base DTB and the first overlay separately after clearing existing selections.
Summary
Test
source .env && make qemu-virt-arm64-testgit diff --check origin/master..HEAD