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

[Ard Biesheuvel]

On 12 December 2017 at 14:17, Peter Maydell <address@hidden> wrote:
> On 12 December 2017 at 14:16, Ard Biesheuvel <address@hidden> wrote:
>> On 12 December 2017 at 14:13, Peter Maydell <address@hidden> wrote:
>>> On 12 December 2017 at 14:12, Ard Biesheuvel <address@hidden> wrote:
>>>> On 12 December 2017 at 14:10, Peter Maydell <address@hidden> wrote:
>>>>> That doesn't actually usefully separate debug output from the
>>>>> console, though, because stdout-path is also going to point
>>>>> to the UART with the lowest physical address...
>>>>>
>>>>
>>>> By default, yes, just like is currently the case. But I would assume
>>>> this new serial port could be appointed 'console' and put into
>>>> stdout-path by QEMU, based on the command line options?
>>>
>>> We don't have any command line options for doing that, and I'm
>>> generally reluctant to introduce new command line UI, especially
>>> new command line UI that's specific to Arm and not also needed
>>> for x86.
>>>
>>
>> If stdout-path is always going to point to address@hidden, why would
>> we need to parse it?
>
> If you had always parsed stdout-path, we wouldn't need to worry
> about the order in which the UART nodes appear in the dtb...
>

That's a fair point. But it still does not justify introducing added
complexity in the firmware, if the conclusion is always going to be
that the console will be on address@hidden

To Drew's point re DEBUG builds, I don't think we should generally
enable DEBUG and send the output to nowhereland if the user does not
wire it up. That's a MMIO trap and two world switches for each
character written, if I am not mistaken, and the DEBUG builds are very
noisy.

But still, given that stdout-path is essentially written in stone
anyway, could we also decide that it will always refer to
address@hidden by its nodename? That way, we can easily implement the
early DEBUG logic by using any non-disabled non-secure PL011 that is
not referenced in stdout-path, and falling back to the one that is in
stdout-path, which will essentially work as it does today. And for the
more elaborate DXE driver, we can find the nodename from stdout-path.