Re: [Qemu-devel] [PATCH 3/3] hw/arm/virt-acpi-build: Add second UART to ACPI tables

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 13 December 2017 at 16:01, Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/13/17 14:56, Peter Maydell wrote:
>> On 12 December 2017 at 11:06, Laszlo Ersek <lersek@redhat.com> wrote:
>>> BTW, has anyone tested this with the ArmVirtQemu firmware? As far as I
>>> can see from the firmware code, the firmware will use the PL011 whose
>>> description comes first in the DTB (and ignore the other PL011), in an
>>> fdt_next_node() traversal. Is that OK for the intended use case?
>>
>> I have now tested this,
>
> Thank you!
>
>> and annoyingly UEFI and the kernel seem
>> to disagree about enumeration order. That is, if QEMU creates
>> them in the code in the order 0x09050000 (uart 2), 0x09000000 (uart 1),
>> then they appear in the dtb with uart 1 first, and the kernel enumerates
>> them as ttyAMA0 being uart 1 and ttyAMA1 being uart 2, but UEFI
>> outputs to uart 2...
>
> Ouch. This reminds me (remotely) of QEMU commit 587078f0ed63
> ("hw/arm/virt: explain device-to-transport mapping in
> create_virtio_devices()", 2015-02-05).
>
> I'd still like to avoid the "sophisticated" /chosen lookup (the lookup
> itself is not too complex, but evaluating whatever we find there against
> each of the scanned UART nodes appears difficult, if I'm to understand
> Ard's earlier point correctly).

This may be a lot simpler than I originally thought. stdout-path
contains a string of the from

<nodename-or-alias>[:<baudrate[<parity>[<data-bits>[<flow-control>]]]]

where nodename-or-alias can be resolved into a path via fdt_get_alias
(), or used directly as a path otherwise.

> I hope that we can match the kernel's
> logic with simple modifications to our scanning loops, e.g. we could
> simply pick the last UART rather than the first, or else do a maximum
> (or minimum) search for the UART base, and stick with the maximum (or
> minimum) found.
>
> However, for that, we first have to understand what the kernel does. Can
> someone explain that? (I tried taking a look, but it's turtles all the
> way down.)
>

The kernel uses the contents of the SPCR table or /chosen/stdout-path
as the console unless overridden on the kernel command line. This is
independent of enumeration order.