[U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim

Leif Lindholm leif.lindholm at linaro.org
Fri Apr 12 19:24:11 UTC 2019

On Thu, Apr 11, 2019 at 10:08:10PM +0200, Heinrich Schuchardt wrote:
> > > How about systab.tables assigned in efi_initialize_system_table()? Which
> > > of the addresses in systab.tables should be updated upon relocation.
> > > 
> > > The EFI Spec is really hazy: "A pointer to the table associated with
> > > VendorGuid. Whether this pointer is a physical address or a
> > > virtual address during runtime is determined by the VendorGuid."
> > > 
> > 
> > Indeed. So it is up to the publisher to update the reference, but I am
> > not aware of any firmware implementations that do this in practice. It
> > is typically assumed that a firmware component that is still active at
> > runtime holds its own reference to data exposed via a configuration
> > table, and updates the reference during SetVirtualAddressMap.
> > 
> > There is also a known bug in EDK2 where the ESRT table is passed in
> > boot services memory, but the capsule update code actually tries to
> > access it at runtime, so this isn't as clean as we'd like it to be.
> > 
> > > The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined
> > > in the UEFI spec. So we can marvel about expected behavior. Is there any
> > > other document specifying it?
> > > 
> > 
> > No, its de facto specification is in the EDK2 source tree.

Well, in reality, it appeared simultanously-ish in Linux and GRUB, and
I think is entry into the EDK2 codebase came later :)

> As all ARM systems use it I guess this GUID should move into the UEFI
> spec. Maybe Linaro could raise this issue.

While the UEFI specification does list the ACPI, ACPI_20, SMBIOS, and
some other common GUIDs, this is not where they are defined. If it
needs to go into some specification, that would probably be the
devicetree.org one.


More information about the U-Boot mailing list