Thanks for the note.

I think you're going at this somewhat backwards. While this may seem
to you to be a universal payload, to many it appears to be "make
everybody support UEFI model."

As you have seen, this will not be well received.

As Peter points out, the coreboot payload model is simple,
deliberately, and in that simplicity there has been a lot of thought.
As we know, it's far harder to write less code than to write more
code. The coreboot model is to pare down functionality to the minimum
possible. In the coreboot model, complexity belongs in the payload.

In fact, the coreboot payload went through four distinct evolutions
before settling on the current model. That was so long ago it is
little remembered; one indicator of our success is that the payload
model has been unchanged for almost the last 15 years.

But a common payload model might be desired. (could we call it common
and not universal? universal has a feel of hubris)

Were I to do this, I'd start with a survey. What do the different
firmware systems do? What is a payload in these systems? What do
payloads require of the firmware, and what do they provide? How is
data communicated to payloads? Is there value in having multiple
payloads, and can payloads return? How are payloads selected? And so
on.

From there, we could figure out what the limitations of these models are.

From there, we could start to talk about common models.

A good example for me is the UEFI handoff block. I think the design is
fatally flawed, as it is not self-describing data: you have to know
what struct was compiled, what pieces were not #ifdef'd out, by what
version of what compiler, with what padding and alignment rules, or
you can't use the struct. That's not great.

So, rather than accepting a HOB as a given, in a standard that may
well last 20 years, why not state the goal of having a way to
communicate information to a payload, and then work out a good way to
do that, and THEN define what a HOB could be.

Might you consider restarting this as a true community effort?
Unfortunately there is an appearance that Intel is dictating the
standard to the rest of us, take it or leave it, and that is going to
generate bad feeling.

Thanks

ron

On Mon, Nov 2, 2020 at 2:58 AM Banik, Subrata <subrata.banik@intel.com> wrote:
>
> HI All,
>
>
>
> coreboot is a modular design with hardware initialization stage followed by a payload to boot OS https://doc.coreboot.org/payloads.html
>
>
>
> There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction
>
>
>
> The goal for this initiative is interoperability between bootloaders and payloads so that different bootloaders can work with different payloads.
>
>
>
> An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html.
>
>
>
> The Universal Payload community welcomes feedback and contributions.
>
>
>
> We are developing various POC codes to demonstrate the concept. One POC uses coreboot as the bootloader and EDKII UEFI as the payload https://github.com/universalpayload/coreboot/tree/universal_payload
>
>
>
> Thanks,
>
> Subrata
>
>
>
> _______________________________________________
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-leave@coreboot.org