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. > I don't recall how well defined those are vs. just abstract concepts. > > Is it only for this interface or any firmware to firmware handoff. If > the former, then I'm looking for folks involved with EFI/Tianocore to > have some buy-in. If the latter, then this should be part of the > firmware handoff efforts and have buy-in there. > I still haven't seen any example of how platform init would make meaningful use of 'boot-code' and 'runtime-code' regions to inform a payload about executable regions in memory. Especially 'runtime code' is interesting here, as it presumably means that the OS must map such regions as executable in some way. This is why I mentioned phandles in a previous reply: there /must/ be some additional context provided elsewhere, or the distinction between boot code/data and runtime code/data is meaningless. So again, can we *please* have an example of how these regions will be used in practice? > > > I do have views on the 'EFI' opt-out with reserved-memory, if you are > > > interested, but that relates to the OS. If you are wanting to place > > > some constraints on /reserved-memory and /memory we could do that > > > e.g. that the DT and the map returned by EFI boot services must be > > > consistent. But as it is, the nodes are ignored by the OS when booting > > > with EFI, aren't they? > > > > Can this be applied, please? If there are further comments, please let me > > know. > > I really have limited knowledge and interest in this. I don't mind > hosting something like this in dtschema, but I'm not taking it without > buy-in from multiple parties which I haven't seen. > I will state again that I do not object to these bindings as long as they are restricted to use in the context of firmware. 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.
