[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [RFC] arm/virt: add one more uart for UEFI runtime debug
From: |
Peter Maydell |
Subject: |
Re: [Qemu-arm] [RFC] arm/virt: add one more uart for UEFI runtime debug |
Date: |
Sun, 7 Apr 2019 14:16:08 +0100 |
On Sun, 7 Apr 2019 at 09:19, Heyi Guo <address@hidden> wrote:
>
> This patch is based on the discussion in TianoCore edk2-devel mailing
> list:
> https://lists.01.org/pipermail/edk2-devel/2019-March/037986.html
>
> The conclusion is that we need an individual UART for UEFI runtime
> services to print debug message at runtime, to avoid conflicting with
> the system UART. We cannot use the secure UART either, for we may both
> have Trusted Firmware and UEFI runtime services running on the VM, and
> it is not easy to keep synchronization between the two components.
I don't think it makes much sense to keep adding UARTs for every
bit of the system software stack. We don't have an infinite
supply of UARTs on real hardware either -- how is this handled
there ?
Also adding new UARTs to this board is awkward because of
the weird choices various bits of software have made in
reading the dtb and picking a UART if there's more than one
listed.
> @@ -713,13 +715,23 @@ static void create_uart(const VirtMachineState *vms,
> qemu_irq *pic, int uart,
> if (uart == VIRT_UART) {
> qemu_fdt_setprop_string(vms->fdt, "/chosen", "stdout-path",
> nodename);
> } else {
> + const char *status_string;
> +
> + if (uart == VIRT_SECURE_UART) {
> + status_string = "secure-status";
> + } else {
> + status_string = "uefi-status";
Where does this status string come from? The "secure-status" one
is documented in the device tree spec and has a well defined
meaning.
thanks
-- PMM