[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH 3/3] hw/arm/virt-acpi-build: Add seco

From: Peter Maydell
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 3/3] hw/arm/virt-acpi-build: Add second UART to ACPI tables
Date: Tue, 12 Dec 2017 12:47:06 +0000

On 12 December 2017 at 12:41, Laszlo Ersek <address@hidden> wrote:
> I agree. There's one user-visible complication: while with one UART,
> it's not possible to mix things up, with two UARTs, users will
> inevitably want to assign inverse roles to them, relative to what QEMU /
> the firmware assigns originally.
> E.g. if one PL011 is redirected to a regular file (debug messages) and
> the other one to stdio (console), there will be complaints that "I
> wanted it the other way around". The redirection happens on the backend
> (chardev) level, but the firmware won't see the difference on the
> frontend (PL011) level.
> Is it possible to add a new property to the UART nodes in the DTB, like
> "purpose"?

This is what the "chosen" stdout-path node in the DTB is for,
but you said you didn't want to look at that :-) (it means
"device to be used for boot console output".)

> Or can we make a virt-arm policy that "first -serial is always ...,
> second -serial is always ..."?

Well, the first -serial will always be the 0x09000000 one
that we have today, and the second -serial will be the other
one (unless you have -machine secure=yes, in which case
second -serial is the secure-only UART and third -serial is
the second NS UART).

Is this any different to the x86 case, where there are two
UARTs at different IO port/IRQ locations?

I think the only thing users really expect is that if you're
using just the one serial port for anything then it's the
first one.

-- PMM

reply via email to

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