Hi Rob, Sure, I will ask if the edk2 developers who work together for UPL spec could help to respond here.
Hi Ard, Regarding this part: *However, there is no scoping in DT schema as far as I am aware, which means that the OS may be forced/expected to interpret these regions beyond simply disregarding them and treating them as reserved memory, and *that* is something I strongly object to.* I think that is one of good perspective to look into this, however please also consider this situation: that everyone is just starting to develop their own DT schemas (e.g. RISC-V), and there is no way to stop OS to also pick up those DT nodes. in that case, if we do not maintain a more unified DT schema, then OS might end up with more conflicting and possibly contracting DT nodes/ properties (e.g. RISC-V with own DT schemas using U-Boot (another DT schema) + edk2 payload (another DT schema, like UPL) to boot to OS. So personally I still prefer a unified DT schema, even if the OS never uses them, but that would be very beneficial and in control in the long term if more people are using DT. For now, the DT does serve as the purpose of communication vehicle in between platform init and payload, which is still within Firmware stack. However from edk2 stand point, there is more people want to roll out DT for more internal usage within edk2 itself, for example: https://uefi.org/sites/default/files/resources/Embracing%20Modularity%20and%20Boot-Time%20Configuration%20Faster%20TTM%20with%20Tiano-based%20Solutions_Warkentin.pdf For sure, it is much easier for us (and time saving as well) to just maintain DT schema/ format within our own UPL spec, but as mentioned, for better long term maintenance and community collaborations, we decided to upstream our implementation back to the main DT schema :) Thanks! Best Regards, *Lean Sheng Tan* 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: sheng....@9elements.com Phone: *+49 234 68 94 188 <+492346894188>* Mobile: *+49 176 76 113842 <+4917676113842>* Registered office: Bochum Commercial register: Amtsgericht Bochum, HRB 17519 Management: Sebastian German, Eray Bazaar Data protection information according to Art. 13 GDPR <https://9elements.com/privacy> On Wed, 8 Nov 2023 at 15:20, Ard Biesheuvel <a...@kernel.org> wrote: > On Wed, 8 Nov 2023 at 14:57, Rob Herring <r...@kernel.org> wrote: > > > > On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel <a...@kernel.org> wrote: > > > > > > On Tue, 7 Nov 2023 at 19:07, Rob Herring <r...@kernel.org> wrote: > > > > > > > > > > > > All of this: > > > > > > > > > > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass <s...@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. >
