qemu-arm
[Top][All Lists]
Advanced

[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: Ard Biesheuvel
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 13:56:44 +0000

On 12 December 2017 at 13:28, Laszlo Ersek <address@hidden> wrote:
> On 12/12/17 13:47, Peter Maydell wrote:
>> 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".)
>
> :(
>
> Ard is right that we really shouldn't do that kind of parsing magic in
> very early UEFI stuff.
>
>
>>> 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?
>
> OVMF (x86) uses two distinct devices for the two purposes discussed.
>
> * It uses the "debug console device" for debug message output, at
> hard-coded IO port 0x402; so if you'd like to capture those messages,
> then you have to add:
>
>   -chardev file,id=debugfile,path=debug.log \
>   -device isa-debugcon,iobase=0x402,chardev=debugfile \
>
> (or the more traditional
>
>   -debugcon file:debug.log \
>   -global isa-debugcon.iobase=0x402 \
> )
>
> * For console I/O, it uses the first serial port. (I think I have once
> investigated what it takes to use other serial ports for console I/O --
> I'm no longer sure if "it happens to be impossible in OVMF", or just
> "nobody ever does that".)
>
>
> The important distinction (on the UEFI level anyway) is that the debug
> messages need to go to a super dumb device, while console I/O can use a
> much higher-level serial IO abstraction ("protocol").
>
>
>> 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.
>
> You are right -- we've never had two (non-secure) UARTs on virt-arm, so
> we can invent whatever assignment, as long as:
>
> - the single UART case doesn't break (keeps receiving both debug output
> and console IO),
>
> - whatever we invent for the two UARTs case now, it remains consistent
> over time. I think this implies we can rely on the FDT node ordering in
> the firmware (if we want to use the 2nd UART at all, that is), and then
> QEMU shouldn't change the serial_hds[] <-> FDT node mapping in the
> future, in machvirt_init() and the callees thereof.
>

Given that the DEBUG output is only produced on DEBUG builds, couldn't
we simply stipulate that DEBUG output appears on the PL011 with the
lowest physical address? That keeps the current status quo, and is
probably sufficient for 99% of the use cases of people using the DEBUG
builds.

Then, we can introduce some code to decode stdout-path in FdtClientDxe
(a higher level DT parsing driver) so that the actual serial console
gets installed onto whichever UART is described as the system console.
Also, given that ArmVirtQemu is tightly coupled to QEMU/mach-virt, we
could decide to only use node names in stdout-path (as we do
currently) to simplify the parsing logic.



reply via email to

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