HI Peter,
First of all I would like to THANK you for your time to share the feedback. I'm
grateful to get your feedback at first place.
Please consider my apology if this email sounds different and create some
communication/understanding error.
This email was not for sure meant to insult coreboot projects. And being an
active member of coreboot community since several year now, spending so much
time with coreboot project, it was never an intent to do such.
Rather we are exploring to see how we could avoid the redundant development
effort across all IA SoC supported bootloaders (i.e. UEFI based Min Platform,
SBL and coreboot) that would benefit IA-coreboot projects as well.
Example: customers can switch easily between one payload to another payload
based on their platform need, for their firmware solution and underlying
firmware should publish unified information across all payload.
Happy to see your early feedback and this would be helpful for our early design
process.
Thanks,
Subrata
-Original Message-
From: Peter Stuge
Sent: Thursday, November 5, 2020 4:54 AM
To: coreboot
Cc: Banik, Subrata ; Zimmer, Vincent
; Ma, Maurice ; Sripathi,
Srinivas ; Manigandan, Balaji
Subject: Re: [coreboot] Universal Payload - RFC and Invitation from Universal
Payload community
Hello Intel,
TL;DR: I consider this spec and project an insult to the coreboot project.
It is ridiculous and a waste of everyone's time. You seem to completely miss
the point of, or ignore, numerous design decisions made in coreboot for very
good reasons. I'm not sure which is worse.
It seems that you are only able to think in terms of UEFI and ecosystem partner
requirements, in which case you should please take that nonsense somewhere else.
Long response:
Banik, Subrata wrote:
> 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
..
> 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.
In the draft spec you appropriate the payload concept and terminology
established by coreboot, and make it sound like payloads somehow originate from
your project.
While it is flattering that you recognize payloads as introduced by coreboot
(actually LinuxBIOS) long before EFI to be a good idea, you still need to be
honest in your communication if you want any chance at gaining a good
reputation for your project.
The draft spec consistently pushes EDK2 over all alternatives and it also
pushes as many UEFI-related and legacy concepts (HOBs, ACPI, etc.) as possible.
Such behavior is directly contrary to acceptable practice in open projects like
coreboot, in fact this tactic that you have chosen looks more like a propaganda
campaign in a political fight, it is utterly ridiculous to me.
The spec makes very broad statements such as this:
"Payloads are considered part of system firmware"
But that is not at all true for coreboot, where it is a conscious design
decision to have very strong separation between hardware init and payload.
Payloads are explicitly *not* part of the system "firmware" - but are an entity
of their own, running after coreboot.
You confuse Linux as a payload with LinuxBoot in the draft spec. Those flows
are two distinct and very different methods to boot into Linux.
In the section "coreboot Payload Interface" you pose this question:
"How to fill the gap with current coreboot and payload requirement?"
The question refers to a "gap" and a "requirement" while the spec does not say
what those are.
Even though this question is completely unspecific, and thus does not
communicate anything useful, the draft spec does not fail to provide an answer,
which has the side effect of making the purpose of your project absolutely
clear:
"Use a library in coreboot to convert the new interface."
You want to add "new interface" (as in UEFI-based) stuff to coreboot (and
surely any other relevant firmware project) because you are obviously trying to
force a new payload interface onto coreboot, instead of adapting to what
coreboot already supports.
Further, the draft spec in the "Payload principle" section introduces a
campaign aimed at retarding firmware back to the BIOS era.
"Open: Should Payload return back to bootloader if payload fail?
Answer: No for first generation. No callbacks into payload launcher."
This explains that you intend to create a callback interface from the payload
to the hardware initialization in a *later* version of the spec, doubling down
on your serious mistake in EFI to couple all stages together in complicated
ways, and ignoring that a callback interface is something that the coreboot
project explicitly and purposely rejects, and does not want to see as part of
its payload
