From: Laszlo Ersek <lersek@redhat.com>
To: Ying Fang <fangying1@huawei.com>, Igor Mammedov <imammedo@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Drew Jones <drjones@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
"wangzhigang17@huawei.com" <wangzhigang17@huawei.com>,
"Ard Biesheuvel \(ARM address\)" <ard.biesheuvel@arm.com>,
philmd@redhat.com
Subject: Re: Question on UEFI ACPI tables setup and probing on arm64
Date: Fri, 6 Nov 2020 18:09:53 +0100 [thread overview]
Message-ID: <813efc59-2ce4-e2be-894f-e48ca66ce603@redhat.com> (raw)
In-Reply-To: <5310d14d-8dbe-ba97-fdf1-4f3f10f91f3a@huawei.com>
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
next prev parent reply other threads:[~2020-11-06 17:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 2:50 Question on UEFI ACPI tables setup and probing on arm64 Ying Fang
2020-11-03 12:39 ` Igor Mammedov
2020-11-04 21:46 ` Laszlo Ersek
2020-11-04 21:57 ` Ard Biesheuvel
2020-11-05 4:30 ` Ying Fang
2020-11-06 17:09 ` Laszlo Ersek [this message]
2020-11-10 1:42 ` Ying Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=813efc59-2ce4-e2be-894f-e48ca66ce603@redhat.com \
--to=lersek@redhat.com \
--cc=ard.biesheuvel@arm.com \
--cc=drjones@redhat.com \
--cc=fangying1@huawei.com \
--cc=imammedo@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wangzhigang17@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).