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: > 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 Laszlo