Re: Question on UEFI ACPI tables setup and probing on arm64

[Ying Fang]

On 11/7/2020 1:09 AM, Laszlo Ersek wrote:
> On 11/05/20 05:30, Ying Fang wrote:
>
> > I see it in Qemu the *loader_start* is fixed at 1 GiB on the
> > physical address space which points to the DRAM base. In ArmVirtQemu.dsc
> > PcdDeviceTreeInitialBaseAddress is set 0x40000000 with correspondence.
> >
> > Here I also see the discussion about DRAM base for ArmVirtQemu.
> > https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03127.html
> >
> > I am still not sure how UEFI knows that it is running on a ArmVirtQemu
> > machine type.
>
> It doesn't know. It remains a convention.
>
> This part is not auto-detected; the constants in QEMU and edk2 are
> independently open-coded, their values were synchronized by human effort
> initially.
>
> The user or the management layer have to make sure they boot a UEFI
> firmware binary on the machine type that is compatible with the machine
> type.
>
> There is some meta-data to help with that:

Thanks so much for the reply,
I now have the basic understanding how QEMU and EDK2 works together
after reading the docs and code there.

> > Does UEFI derive it from the fdt *compatible* property ?
>
> Please see the schema "docs/interop/firmware.json" in the QEMU tree; in
> particular the @FirmwareTarget element.
>
> For an actual example: QEMU bundles some edk2 firmware binaries (purely
> as a convenience, not for production), and those are accompanied by
> matching descriptor files. See
> "pc-bios/descriptors/60-edk2-aarch64.json". (It is a template that's
> fixed up during QEMU installation, but that's tangential here.)
>
>      "targets": [
>          {
>              "architecture": "aarch64",
>              "machines": [
>                  "virt-*"
>              ]
>          }
>      ],

Thanks, I'll look closer into it.

> Thanks
> Laszlo
>
> .