Re: Platform Spec Technical Feedback


On Wed, 2021-10-13 at 11:50 -0600, Aaron Durbin wrote:

On Wed, Oct 13, 2021 at 11:43 AM Heinrich Schuchardt <
heinrich.schuchardt@...> wrote:
On 10/13/21 18:49, Aaron Durbin wrote:

On Wed, Oct 13, 2021 at 9:54 AM Sunil V L <
<mailto:sunilvl@...>> wrote:

     Hi Aaron,

     On Wed, Oct 13, 2021 at 09:00:49AM -0600, Aaron Durbin wrote:
      > On Tue, Oct 12, 2021 at 9:28 PM Heinrich Schuchardt <
      > heinrich.schuchardt@...
     <mailto:heinrich.schuchardt@...>> wrote:
      > >
      > >
      > > On 10/12/21 23:23, Aaron Durbin wrote:
      > > > Hi,
      > > >
      > > > After reading through the platform spec I have some
     on the
      > > > 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
plan for
      > > > ratification in the current items on the docket for
      > > > 2. Unified Discovery is still up in the air, and it's
not clear
      > > > 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
     mconfigptr is
      > > > valid, etc. In other words, not everything is fully
     out to
      > > > mandate such a thing, imo.
      > > > 3. On the server extension, it seems to be implied that
     firmware is
      > > > mandated despite the OS only needing runtime services.
     the reason
      > > > for forcing a system integrator to use UEFI? And why
does it
     matter what
      > > > firmware is used to the OS?
      > >
      > > It is not only for the server extension but for all
     OS-A systems
      > > that the platform specification requires the
implementation of
     as subset
      > > 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
     interface from
      > the OS. Server extension mandates implementing large pieces
     UEFI spec:

     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),

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:

In this case, it was just not updated in the webpage. I have raised a
github issue[1] 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.


Implementing those interfaces should be the only requirement if
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
spec is
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

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?
The boot service LoadImage() is required via the
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

Best regards



      > >
      > > Conformance with the UEFI platform initialization
     is not
      > > 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
     supported RISC-V
      > > systems
      > > * receive platform information in a system independent
      > > 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.
It's also
      > mandating end-user requirements. Who is the end-user? In my
     experience, I
      > think what you wrote is valid depending on the user. In
     situations it
      > is not valid because those requirements do not exist, and
     insist on
      > not having UEFI implementations in the firmware.
      > I think we need to clearly lay out the underlying intention
     not dictate
      > 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
      > -Aaron

Join to automatically receive all group messages.