[XL] Change in coreboot[main]: payloads: Add uefistub payload

[Maximilian Brune (Code Review)]

Attention is currently required from: Benjamin Doron, Martin L Roth, Patrick Rudolph, Simon Glass.

Maximilian Brune has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/78913?usp=email )

Change subject: payloads: Add uefistub payload
......................................................................

Patch Set 4:

(2 comments)

Commit Message:

https://review.coreboot.org/c/coreboot/+/78913/comment/d7b6c175_e5f427c9 :
PS4, Line 7: payloads: Add uefistub payload
Add u-boot reference, since it is mostly their effort.

Patchset:

PS4:
> Why do we need to pull pieces out of U-Boot to achieve this? It doesn't seem a very friendly approach to me...particularly as the files do not seem to reference U-Bot as the source. But even if they do, this seems like a fork to me.

I can't believe I forgot to include the reference (u-boot) into the commit-msg. Sorry about that. I will fix that.
> I believe it would make more sense for coreboot to embrace U-Boot as a first-class coreboot payload, rather than always trying to use something else.

It may help to know how the original motivation of creating the uefistub:
I needed to get ACPI (and SMBIOS) to Linuxboot. Thats it.
The obvious solution was to get the Linux Kernel to accept something else than UEFI to transfer the ACPI tables on arm64. This proved difficult. I am hoping that universal payload will take care of that problem in the future.

Solution number two was to use u-boot for that. I worked on that for a few weeks (implemented 64 bit SMBIOS in u-boot, added an arm64 coreboot platform to u-boot and a few other things). I found myself debugging u-boot problems for weeks and considering that I only wanted u-boot because of ACPI it proved to be overkill for my actual problem. U-boot just didn't fit my use case. Don' get me wrong I like u-boots UEFI implementation, but it just didn't fit my use case. Ideally I would have liked the UEFI implementation of u-boot to be something seperate to u-boot itself (like this payload is and like efistub of Linux more or less is).

Solution number three was to write a minimal uefistub that does what is necessary so it is compliant to LBBR. Being compliant to the UEFI spec is not the goal of this payload (it is completely overkill). I wanted to keep it small, simple and maintainable. I also wanted to seperate the UEFI implementation from coreboot (which is why it is a payload). It was actually a cool experiment to see how much Linux actually relies on UEFI. uefistub is not a fork of u-boot. It is just splitting u-boot and its UEFI implementation and keep that to a minimum.

In the end everyone can decide for themselves to use either u-boot or this uefistub. I am not forcing anyone to use this payload. Using u-boot as coreboot payload is still desired for most use cases (just not for mine).

An alternative approach was I think proposed by Ilias Apalodimas at OSFC:
Create a library that takes care of all the UEFI specific stuff. That could then be leveraged by multiple projects like u-boot or this coreboot payload. I am actually in big favour of this, because I would really like to see coreboot, u-boot and other open source firmware projects to share more code. That would also create some more flexibility for different use cases. I just didn't have yet the time to work on that.
That reminds me: OpenSBI is actually a nice example on how to share code, because you can either use it as library or standalone binary and it basically only accomplishes a very specific task (the SBI interface). I would like to see something similar to that for UEFI interfaces.