On Wed, 2021-10-13 at 19:43 +0200, 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
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. Just to add to Heinrich's point, LoadFile2 is the preferred method for loading initrd in RISC-V UEFI implementation as well.
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
|
