Re: Platform Spec Technical Feedback


atishp@...
 

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 <
sunilvl@...
<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
feedback
     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
ratification.
      > > > 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
solve.
     There's
      > > > both debug and runtime use cases, but there are issues
about
     dynamic
      > > > encoding based on fusing, runtime options, even when
the
     mconfigptr is
      > > > valid, etc. In other words, not everything is fully
fleshed
     out to
      > > > mandate such a thing, imo.
      > > > 3. On the server extension, it seems to be implied that
UEFI
     firmware is
      > > > mandated despite the OS only needing runtime services.
What's
     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
profile
     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.
Open
     source
      > > 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
of
     UEFI spec:

     OS-A refers to EBBR which mandates reduced set of UEFI
interfaces.

      >
      > "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
other
     protocols.
      > Therefore, implementing UEFI is inherently mandated.

     Yes, UEFI is mandatory for server OS distros. What "other
protocols"
     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),
fwiw.

With version 2.0.1 the EBBR switches to UEFI spec 2.9.

See the changelog in
https://github.com/ARM-software/ebbr/blob/main/source/index.rst

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[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
revision.
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


[1] https://github.com/ARM-software/ebbr/issues/88



Implementing those interfaces should be the only requirement if
EBBR is
specified, but we're composing requirements from a multitude of
sources,
and it's not clear what spec overrides what requirement. i.e. how
are
the various specifications supposed to be composed?

As you noted, you are focusing on server OS distros. While not
called
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
the
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
it's
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
obtain
files, that are primarily boot options, from arbitrary devices."
EFI_LOAD_FILE2_PROTOCOL says "The Load File 2 protocol is used to
obtain
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
EFI_LOAD_FILE_PROTOCOL
and EFI_LOAD_FILE2_PROTOCOL according to the UEFI specification. This
is
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
the
specification.

Best regards

Heinrich



     Regards
     Sunil

      >
      >
      > >
      > > Conformance with the UEFI platform initialization
specification
     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
interfaces,
     correct?
      >
      >
      > >
      > > 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
way
(via
      > > devicetree or ACPI tables)
      > > * to implement operating system updates in a system
independent
     manner
      > >
      >
      > 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
other
     situations it
      > is not valid because those requirements do not exist, and
they
     insist on
      > not having UEFI implementations in the firmware.
      >
      > I think we need to clearly lay out the underlying intention
and
     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
product
     itself.
      >
      > -Aaron
      >
      >
      >
      >
      >
 
--
Regards,
Atish

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.