[PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Wed, 8 Nov 2023 at 14:57, Rob Herring <robh at kernel.org> wrote:
>
> On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > On Tue, 7 Nov 2023 at 19:07, Rob Herring <robh at kernel.org> wrote:
> > >
> > >
> > > All of this:
> > >
> >
> > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > It is not specific to EDK2. Imagine this boot sequence:
> > > > >
> > > > > - Platform Init (U-Boot) starts up
> > > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > > > various things in memory
> > > > > - U-Boot sets up some runtime code and data for the OS
> > > > > - U-Boot jumps to the Tianocore payload **
> > > > > - Payload (Tianocore) wants to know where the ACPI tables are, for example
> > > > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > > > the memory map, etc.
> > > > >
> > > > > ** At this point we want to use DT to pass the required information.
> > > > >
> > > > > Of course, Platform Init could be coreboot or Tianocore or some
> > > > > strange private binary. Payload could be U-Boot or something else.
> > > > > That is the point of this effort, to build interoperability.
> > >
> > > [...]
> > >
> > > > > Perhaps the problem here is that Linux has tied itself up in knots
> > > > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > > > It is a simple handoff between two pieces of firmware, Platform Init
> > > > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > > > typically combined, but with this usage they are split, and we can
> > > > > swap out one project for another on either side of the DT interface.
> > >
> > > Is perhaps the clearest description of the problem you want to solve.
> > > It's clearly related to EFI though not the interface to the OS. IIRC,
> > > "platform init" and "payload" are terms in the UEFI spec, right?
> >
> > No they are not. This is from the universal payload specification that
> > is being drafted here
> >
> > https://universalpayload.github.io/spec/index.html
> >
> > but the UEFI specification does not use this terminology.
>
> Then I'm confused as to what this is:
>
> https://uefi.org/specs/PI/1.8/index.html
>

The PI and UEFI specifications are both maintained by the UEFI forum.

The UEFI specification covers external APIs for firmware
implementations, i.e., the OS visible interface and the public API for
UEFI device drivers that are not tightly integrated with system
firmware (for example, the GPU boot time driver in the ROM of an
add-in card)

The UEFI forum's PI spec describes system firmware internals, and
defines the SEC, PEI DXE and BDS boot phases, among other things.

It is possible to implement UEFI without PI (which is what uboot does,
for instance), but Tianocore/EDK2 is the reference implementation for
both PI and UEFI, and sadly, there is no discernible distinction
between the two (e.g., both PI and UEFI use identifiers with EFI_ type
and enum identifier prefixes)

'platform init' in the context of this discussion is something
completely separate, and has zero bearing on the PI<->UEFI handover in
Tianocore (which is not really a handover to begin with).

There is code in Tianocore which allows it to run as a 'payload',
which means [presumably] that only the DXE and subsequent phases are
launched from a 'platform init' component that describes the platform
using some of the DT bindings that are under discussion here. In this
case, I can see how some of the ACPI descriptions provided by the
'platform init' might be inherited by the 'payload'. However, I don't
see how such a Tianocore payload would make meaningful use of
boot/runtime code/data described in general terms using this proposed
binding, which is why I keep asking for an example scenario.