Re: [Qemu-devel] [RFC] arm/virt: add one more uart for UEFI runtime debug

[Heyi Guo]

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

Thanks,
Heyi

> thanks
> -- PMM
>
> .