[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on UEFI ACPI tables setup and probing on arm64
From: |
Ying Fang |
Subject: |
Re: Question on UEFI ACPI tables setup and probing on arm64 |
Date: |
Tue, 10 Nov 2020 09:42:15 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
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
.