[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.

/
    Leif


More information about the U-Boot mailing list