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

[Yao Zi <me@ziyao.cc>]

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