On Wed, 2021-10-13 at 11:50 -0600, Aaron Durbin wrote:
On Wed, Oct 13, 2021 at 11:43 AM Heinrich Schuchardt <
On 10/13/21 18:49, Aaron Durbin wrote:
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
on theplan for
> > > 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 forratification.
> > > 2. Unified Discovery is still up in the air, and it'snot clear
> > > exactly the scope of the problem that it is trying tosolve.
> > > both debug and runtime use cases, but there are issues
> > > encoding based on fusing, runtime options, even when
> > > 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.
the reasondoes it
> > > 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
OS-A systemsimplementation of
> > 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?fwiw.
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),
With version 2.0.1 the EBBR switches to UEFI spec 2.9.
See the changelog in
Thanks for the pointer. The platform spec, while calling out 2.0.1, has
a link to 2.0.0: https://arm-software.github.io/ebbr/
In this case, it was just not updated in the webpage. I have raised a
github issue for that.
If we're going to call out specific versions we should be able to
directly link to the spec that only has that version specified. In this
case, we're pointing to 2.0.0, but it also seems it's not a particular
RISC-V specific changes were merged in v2.0.1. That's why, it is
referred in the platform spec.https://github.com/ARM-software/ebbr/releases/tag/v2.0.1
Implementing those interfaces should be the only requirement ifEBBR is
specified, but we're composing requirements from a multitude ofsources,
and it's not clear what spec overrides what requirement. i.e. howare
the various specifications supposed to be composed?called
As you noted, you are focusing on server OS distros. While not
out in the platform spec proper, the assumption for the platformspec is
focusing on products that would primarily load OS binary distros?the
Is the platform spec also assuming a particular kernel loader? Is
term 'OS' encompassing requirements for loader and kernel?it's
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 trueobtain
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."obtain
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to
files from arbitrary devices that are not boot options."The boot service LoadImage() is required via the
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
> > 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
> > devicetree or ACPI tables)independent
> > * 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 myother
> 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