[Top][All Lists]

[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: Heyi Guo
Subject: Re: [Qemu-arm] [RFC] arm/virt: add one more uart for UEFI runtime debug
Date: Mon, 8 Apr 2019 09:45:32 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 2019/4/7 21:16, Peter Maydell wrote:
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

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 ?
As you were in the edk2 mail thread, I supposed you also agreed to add one more UART. 
What did you mean by "I do still have a todo list item to add a 2nd UART"? How 
shall we do that?

On our real hardware platforms, we don't have a separate serial port for UEFI 
runtime services; that's the reason for why I had wanted to have an adaptable 
approach for platform without one more serial port...

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

@@ -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
Sorry this came from my imagination, so I sent it as a "RFC" :)


-- PMM


reply via email to

[Prev in Thread] Current Thread [Next in Thread]