(Adding a few more, will respond soon) - Simon On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Wed, 23 Aug 2023 at 22:04, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Wed, 23 Aug 2023 at 10:59, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > > > > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote: > > > > > The Devicetree specification skips over handling of a logical view of > > > > > the memory map, pointing users to the UEFI specification. > > > > > > > > > > It is common to split firmware into 'Platform Init', which does the > > > > > initial hardware setup and a "Payload" which selects the OS to be booted. > > > > > Thus an handover interface is required between these two pieces. > > > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is > > > > > present on either side of this interface, information about memory usage > > > > > and attributes must be presented to the "Payload" in some form. > > > > > > Not quite. > > > > > > This seems to be intended for consumption by Linux booting in ACPI > > > mode, but not via UEFI, right? > > > > Actually, this is for consumption by firmware. The goal is to allow > > edk2 to boot into U-Boot and vice versa, i.e. provide some > > interoperability between firmware projects. I will use the "Platform > > Init" and "Payload" terminology here too. > > > > OK. It was the cc to linux-acpi@ and the authors of the > ACPI/SMBIOS-without-UEFI patches that threw me off here. > > If we are talking about an internal interface for firmware components, > I'd be inclined to treat this as an implementation detail, as long as > the OS is not expected to consume these DT nodes. > > However, I struggle to see the point of framing this information as a > 'UEFI memory map'. Neither EDK2 nor u-boot consume this information > natively, and there is already prior art in both projects to consume > nodes following the existing bindings for device_type=memory and the > /reserved-memory node. UEFI runtime memory is generally useless > without UEFI runtime services, and UEFI boot services memory is just > free memory. > > There is also an overlap with the handover between secure and > non-secure firmware on arm64, which is also DT based, and communicates > available memory as well as RAM regions that are reserved for firmware > use. > > 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. > > ... > > > > There is no intent to implement the UEFI spec, here. It is simply that > > some payloads (EDK2) are used to having this information. > > > > Imagine splitting EDK2 into two parts, one of which does platform init > > and the other which (the payload) boots the OS. The payload wants > > information from Platform Init and it needs to be in a devicetree, > > since that is what we have chosen for this interface. So to some > > extent this is unrelated to whether you have EFI boot services. We > > just need to be able to pass the information across the interface. > > Note that the user can (without recompilation, etc.) replace the > > second part with U-Boot (for example) and it must still work. > > > > OK, so device tree makes sense for this. This is how I implemented the > EDK2 port that targets QEMU/mach-virt - it consumes the DT to discover > the UART, RTC,, memory, PCI host bridge, etc. > > But I don't see a use case for a UEFI memory map here. > > > > > > > > > > > > > Today Linux does that by passing: > > > > > > > > /chosen/linux,uefi-mmap-start > > > > /chosen/linux,uefi-mmap-size > > > > /chosen/linux,uefi-mmap-desc-size > > > > /chosen/linux,uefi-mmap-desc-ver > > > > > > > > ... or /chosen/xen,* variants of those. > > > > > > > > Can't we document / genericise that? > > > > That seems to me to be the fields from the EFI memory-map call, but > > where is the actual content? I looked in the kernel but it seems to be > > an internal interface (between the stub and the kernel)? > > > > > > > > > > > > Given the ACPI angle, promoting this to external ABI would introduce a > > > DT dependency to ACPI boot. So we'll at least have to be very clear > > > about which takes precedence, or maybe disregard everything except the > > > /chosen node when doing ACPI boot? > > > > > > This also argues for not creating an ordinary binding for this (i.e., > > > describing it as part of the platform topology), but putting it under > > > /chosen as a Linux-only boot tweak. > > > > > > > Pointing to that rather than re-encoding it in DT means that it stays in-sync > > > > with the EFI spec and we won't back ourselves into a corner where we cannot > > > > encode something due to a structural difference. I don't think it's a good idea > > > > to try to re-encode it, or we're just setting ourselves up for futher pain. > > > > > > > > > > What I would prefer is to formalize pseudo-EFI boot and define the > > > bare required minimum (system table + memory map + config tables) in > > > an arch-agnostic manner. That way, the only thing that needs to be > > > passed via DT/boot_params/etc is the (pseudo-)EFI system table > > > address, and everything else (SMBIOS, ACPI as well as the EFI memory > > > map and even the initrd) can be passed via config tables as usual, all > > > of which is already supported in (mostly) generic kernel code. > > > > > <snip some lines> > > > > > Here I believe you are talking about booting the kernel in EFI mode, > > but that is not the intent of this patch. This is all about things > > happening in firmware. Now, if the payload (second) part of the > > firmware decides it wants to offer EFI boot services and boot the > > kernel via the EFI stub, then it may very well pack this information > > (with a few changes) into a system table and make it available to the > > kernel stub. But by then this FDT binding is irrelevant, since it has > > served its purpose (which, to reiterate, is to facilitate information > > passage from platform init to 'payload'). > > > > Indeed. As long as this binding is never consumed by the OS, I don't > have any objections to it - I just fail to see the point.
