U-Boot UEFI implementation vs EDK II UEFI Payload

U-Boot UEFI implementation vs EDK II UEFI Payload

[Umut Tezduyar Lindskog]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi,

I have been looking into U-Boot’s UEFI implementation and trying to
understand some of the architectural decisions behind it.

I noticed that EDK II has a UefiPayloadPkg component, which is intended to
provide UEFI services on top of an existing bootloader. This made me
curious why U-Boot maintains its own UEFI implementation rather than using
EDK II’s.

I am not suggesting that one approach is better than the other. I am just
trying to understand the history and the trade-offs.

I have a few questions:

1. Was integrating EDK II’s UefiPayloadPkg ever considered for U-Boot? If
so, what were the main reasons for choosing a native implementation?
2. What are the main advantages of U-Boot’s native UEFI implementation
compared to using EDK II? Is it primarily about binary size, complexity,
dependencies, or having better control over the implementation?
3. Are there any significant disadvantages to maintaining a separate UEFI
implementation? For example, keeping up with UEFI specifications,
compatibility with EFI applications, or implementing features such as
Secure Boot.
4. Would there be any technical advantages to using EDK II’s UefiPayloadPkg
on top of U-Boot today (instead of it's own UEFI implementation)?

I realize some of these questions might have obvious answers for people
familiar with U-Boot’s history. I am mainly interested in understanding the
design decisions and the reasoning behind having two independent
implementations.

Thanks!
Umut

[-- Attachment #2: Type: text/html, Size: 1572 bytes --]

Re: U-Boot UEFI implementation vs EDK II UEFI Payload

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Tue, Oct 20, 2026 at 02:15:44PM +0200, Umut Tezduyar Lindskog wrote:
> Hi,
> 
> I have been looking into U-Boot’s UEFI implementation and trying to
> understand some of the architectural decisions behind it.
> 
> I noticed that EDK II has a UefiPayloadPkg component, which is intended to
> provide UEFI services on top of an existing bootloader. This made me
> curious why U-Boot maintains its own UEFI implementation rather than using
> EDK II’s.
> 
> I am not suggesting that one approach is better than the other. I am just
> trying to understand the history and the trade-offs.
> 
> I have a few questions:
> 
> 1. Was integrating EDK II’s UefiPayloadPkg ever considered for U-Boot? If
> so, what were the main reasons for choosing a native implementation?

UefiPayloadPkg didn't exist until about 3 years after U-Boot started
implementing our efi_loader code.

> 2. What are the main advantages of U-Boot’s native UEFI implementation
> compared to using EDK II? Is it primarily about binary size, complexity,
> dependencies, or having better control over the implementation?
> 3. Are there any significant disadvantages to maintaining a separate UEFI
> implementation? For example, keeping up with UEFI specifications,
> compatibility with EFI applications, or implementing features such as
> Secure Boot.

I think having this separate implementation has *helped* because it has
at times brought to light inconsistencies within the spec and fostered
cooperation. In general having multiple implementations of something
rather than a single implementation of something is beneficial in many
ways.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot UEFI implementation vs EDK II UEFI Payload

[Yao Zi]

On Tue, Oct 20, 2026 at 02:15:44PM +0200, Umut Tezduyar Lindskog wrote:
> Hi,
> 
> I have been looking into U-Boot’s UEFI implementation and trying to
> understand some of the architectural decisions behind it.
> 
> I noticed that EDK II has a UefiPayloadPkg component, which is intended to
> provide UEFI services on top of an existing bootloader. This made me
> curious why U-Boot maintains its own UEFI implementation rather than using
> EDK II’s.
> 
> I am not suggesting that one approach is better than the other. I am just
> trying to understand the history and the trade-offs.
> 
> I have a few questions:
> 
> 1. Was integrating EDK II’s UefiPayloadPkg ever considered for U-Boot? If
> so, what were the main reasons for choosing a native implementation?
> 2. What are the main advantages of U-Boot’s native UEFI implementation
> compared to using EDK II? Is it primarily about binary size, complexity,
> dependencies, or having better control over the implementation?

A point which I could come up with, is that one doesn't need to
re-implement drivers already available in U-Boot on EDK2 with U-Boot
EFI. And porting drivers from Linux to U-Boot would be easier than
targetting EDK2, I think.

And personally speaking, to me it's easier to work with U-Boot :)

> 3. Are there any significant disadvantages to maintaining a separate UEFI
> implementation? For example, keeping up with UEFI specifications,
> compatibility with EFI applications, or implementing features such as
> Secure Boot.
> 4. Would there be any technical advantages to using EDK II’s UefiPayloadPkg
> on top of U-Boot today (instead of it's own UEFI implementation)?
> 
> I realize some of these questions might have obvious answers for people
> familiar with U-Boot’s history. I am mainly interested in understanding the
> design decisions and the reasoning behind having two independent
> implementations.
> 
> Thanks!
> Umut

Regards,
Yao Zi