On Wed, 2021-10-13 at 19:43 +0200, Heinrich Schuchardt wrote:
On 10/13/21 18:49, Aaron Durbin wrote:
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
On Wed, Oct 13, 2021 at 9:54 AM Sunil V L
On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
> On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
> > On 10/12/21 23:23, Aaron Durbin wrote:
> > > Hi,
> > >
> > > After reading through the platform spec I have some
> > > technical side of things (different from the scoping of
intention in my
> > > general feedback email).
> > >
> > > 1. Zam required, but as far as I can see there is no
> > > ratification in the current items on the docket for
> > > 2. Unified Discovery is still up in the air, and it's
> > > exactly the scope of the problem that it is trying to
> > > both debug and runtime use cases, but there are issues
> > > encoding based on fusing, runtime options, even when the
> > > valid, etc. In other words, not everything is fully
> > > mandate such a thing, imo.
> > > 3. On the server extension, it seems to be implied that
> > > mandated despite the OS only needing runtime services.
> > > for forcing a system integrator to use UEFI? And why
> > > firmware is used to the OS?
> > It is not only for the server extension but for all
> > that the platform specification requires the
> > of the UEFI API.
> > The specification does not require any specific firmware.
> > implementations exist with EDK II and U-Boot.
> OS-A doesn't indicate much w.r.t. UEFI aside from use UEFI
> the OS. Server extension mandates implementing large pieces
OS-A refers to EBBR which mandates reduced set of UEFI
> "The boot and system firmware for the server platforms must
support UEFI as
> defined in the section 2.6 of the UEFI Specification ..."
> That indicates implementing UEFI and subsequently dictates
> Therefore, implementing UEFI is inherently mandated.
Yes, UEFI is mandatory for server OS distros. What "other
which you think not necessary to support server OSs?
The EBBR is required currently to be implemented/presented. It
transitively requires a different UEFI version than what is in the
platform spec (2.8 Errata A in EBBR while 2.9 in platform spec),
See the changelog in
Implementing those interfaces should be the only requirement ifThe boot service LoadImage() is required via the
specified, but we're composing requirements from a multitude of
and it's not clear what spec overrides what requirement. i.e. how
the various specifications supposed to be composed?
As you noted, you are focusing on server OS distros. While not
out in the platform spec proper, the assumption for the platform
focusing on products that would primarily load OS binary distros?
Is the platform spec also assuming a particular kernel loader? Is
term 'OS' encompassing requirements for loader and kernel?
I guess I'm confused that the platform spec is calling out specific
protocols that are not required in EBBR (pcie can make sense if
required to boot, as EBBR dictates, but that's not necessarily true
depending on the topology of the system for booting). e.g. why
is EFI_LOAD_FILE2_PROTOCOL included?
EFI_LOAD_FILE_PROTOCOL says "The Load File protocol is used to
files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to
files from arbitrary devices that are not boot options."
The former is not required, but the latter is. How come?
and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This
implemented in U-Boot and EDK II.
Requiring implementing the EFI_LOAD_FILE2_PROTOCOL in the sense of
offering a file inside the firmware does not make any sense without
specifying which file shall be presented.
The EFI_LOAD_FILE2_PROTOCOL requirement needs some clarification in
Just to add to Heinrich's point,
LoadFile2 is the preferred method for loading initrd in RISC-V UEFI
implementation as well.
> > Conformance with the UEFI platform initialization
> > required.
> > The UEFI API provides standardized means
> > * to boot an operating system
> > * to update the firmware
> > * to reset and power-off
> Through the use of runtime services and boot services
> > For the operating system the standardized API allows:
> > * to create a single installation medium to boot on all
> > systems
> > * receive platform information in a system independent way
> > devicetree or ACPI tables)
> > * to implement operating system updates in a system
> I'm pretty sure those items don't require UEFI.
> > For the system owner the standardized API allows:
> > * to install alternative operating systems without hassle
> > * easily setup dual boot systems
> So the platform spec is not just for OS interfacing with.
> mandating end-user requirements. Who is the end-user? In my
> think what you wrote is valid depending on the user. In
> is not valid because those requirements do not exist, and
> not having UEFI implementations in the firmware.
> I think we need to clearly lay out the underlying intention
> how such a thing is followed. Or we acknowledge and clearly
define who the
> end-user is and the assumption in how they would use the