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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
