qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).