On Thu, 31 Aug 2023 at 21:03, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > Hi Ard, > > On Thu, 31 Aug 2023 at 06:28, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Wed, 30 Aug 2023 at 23:11, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > Hi Ard, > > > > > > On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > On Tue, 29 Aug 2023 at 21:18, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > > > > > Hi Ard, > > > > > > > > > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > ... > > > > > > In summary, I don't see why a non-UEFI payload would care about UEFI > > > > > > semantics for pre-existing memory reservations, or vice versa. Note > > > > > > that EDK2 will manage its own memory map, and expose it via UEFI boot > > > > > > services and not via DT. > > > > > > > > > > Bear in mind that one or both sides of this interface may be UEFI. > > > > > There is no boot-services link between the two parts that I have > > > > > outlined. > > > > > > > > > > > > > I don't understand what this means. > > > > > > > > UEFI specifies how one component invokes another, and it is not based > > > > on a DT binding. If the second component calls UEFI boot or runtime > > > > services, it should be invoked in this manner. If it doesn't, then it > > > > doesn't care about these memory reservations (and the OS will not be > > > > booted via UEFI either) > > > > > > > > So I feel I am missing something here. Perhaps a practical example > > > > would be helpful? > > > > > > Let's say we want to support these combinations: > > > > > > Platform Init -> Payload > > > -------------------------------- > > > U-Boot -> Tianocore > > > coreboot -> U-Boot > > > Tianocore -> U-Boot > > > Tianocore -> Tianocore > > > U-Boot -> U-Boot > > > > > > Some of the above things have UEFI interfaces, some don't. But in the > > > case of Tianocore -> Tianocore we want things to work as if it were > > > Tianocore -> (its own handoff mechanism) Tiancore. > > > > > > > If Tianocore is the payload, it is either implemented as a EFI app, in > > which case it has access to EFI services, or it is not, in which case > > it doesn't care about UEFI semantics of the existing reserved regions, > > and it only needs to know which regions exist and which of those are > > reserved. > > > > And I think the same applies to all other rows in your table: either > > the existence of UEFI needs to be carried forward, which needs to be > > done via EFI services, or it doesn't, in which case the UEFI specific > > reservations can be dropped, and only reserved and available memory is > > relevant. > > > > > Some Platform Init may create runtime code which needs to accessible later. > > > > > > > But not UEFI runtime code, right? If the payload is not UEFI based, > > the OS would never be able to call that runtime code unless it is > > described in a different, non-UEFI way. This is fine, but it is not > > UEFI so we shouldn't call it UEFI runtime memory. > > > > > The way I think of it is that we need to generalise the memory map a > > > bit. Saying that you must use UEFI boot services to discover it is too > > > UEFI-specific. > > > > > > > What I am questioning is why a memory map with UEFI semantics is even > > relevant when those boot services do not exist. > > > > Could you be more specific about why a payload would have to be aware > > of the existence of UEFI boot/runtime service regions if it does not > > consume the UEFI interfaces of the platform init? And if the payload > > exposes UEFI services to the OS, why would it consume a memory map > > with UEFI semantics rather than a simple list of memblocks and memory > > reservations? > > It seems like you are thinking of the Payload as grub, or something > like that? This is not about grub. If there are EFI boot services to > be provided, they are provided by the Payload, not Platform Init. I am > not that familiar with Tianocore, but if you are, perhaps think of it > as splitting Tianocore into two pieces, one of which inits the silicon > and the other which provides the EFI boot services. > > Again, if you are familiar with Tianocore, it can be built either as a > monolithic whole, or as a coreboot Payload. The Payload part of the > code is (roughly) the same in each case. But the Platform Init is > different[1] > I co-maintain OVMF [including the ARM port that I created from scratch] as well as the ARM architecture support in Tianocore, along with a couple of platform ports for ARM boards, some of which could by now be characterized as 'historical' (AMD Seattle, Socionext SynQuacer and Raspberry Pi 3/4). So I think I have a pretty good handle on how Tianocore based firmware is put together. Tianocore as a payload will expose boot services to the OS, and will provide the OS with a memory map using the UEFI APIs. But you still haven't explained why the memory description this Tianocore inherits from the Platform Init would include any UEFI boot or runtime service regions, or any of the other memory regions with UEFI semantics. TIanocore just needs to know a) where memory lives b) which parts of it are already in use (as far as the memory map is concerned), and the existing bindings suffice for this purpose. In short, the memory regions with UEFI semantics are created by the boot phase that actually exposes UEFI to the OS, in which case the boot services can be used to obtain the memory map. If the consumer is not UEFI based, there is no reason to bother it with descriptions of memory regions that have no significance to it. > > > > Again, I am inclined to treat this as a firmware implementation > > detail, and the OS must never consume this binding. But I am still > > puzzled about what exact purpose it is expected to serve. > > It really is purely so we can mix and match Platform Init (perhaps > silicon init is a more familiar term?) and the Payload. > That part is clear to me. > [1] Of course, coreboot uses blobs which are chunks of UEFI, but that > is a separate issue I suppose you are referring to the proprietary FSP components? Those are mostly made up of PEIMs (in Tianocore/EDK2 speak) for DDR training and chipset initialization, and don't really take part in the implementation of the UEFI APIs. Strictly, they are not 'chunks of UEFI' but 'chunks of PI' (but even Tianocore itself, being the reference implementation of both UEFI and PI, does a terrible job at distinguishing between the two)
