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

[Laszlo Ersek]

On 12/13/17 14:56, Peter Maydell wrote:
> On 12 December 2017 at 11:06, Laszlo Ersek <address@hidden> 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). 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.)

Thanks,
Laszlo