Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs

["Laszlo Ersek" <lersek@redhat.com>]

On 9/21/23 14:02, ardb at kernel.org (Ard Biesheuvel) wrote:
> On Thu, 21 Sept 2023 at 10:50, Peter Maydell <peter.maydell at linaro.org> wrote:
>>
>> Hi; I've been looking again at a very long standing missing feature in
>> the QEMU virt board, which is that we only have one UART. One of the
>> things that has stalled this in the past has been the odd behaviour of
>> EDK2 if the DTB that QEMU passes it describes two UARTs.
>>
>> I'm going to describe the behaviour I see in more detail below, but to
>> put the summary up front:
>>  * EDK2 puts some debug output on one UART and some on the other
>>    (the exact arrangement depends on ordering of the dtb nodes)
>>  * EDK2 doesn't look at either stdout-path or the serial* aliases,
>>    so its choices about how to use the UARTs differ from those
>>    made by the guest kernel it is booting (and it also seems to be
>>    iterating through the dtb in the opposite order to the kernel)
>>
>> The current proposal for adding a second UART is that it only happens
>> if you explicitly add one on the command line (with a second "-serial
>> something" option), so whatever we do won't break existing user
>> setups. So we have scope for saying "if you want to use a second UART,
>> you're going to want a newer EDK2 which handles it better". Exactly
>> what "better" means here is up for grabs, but honouring stdout-path
>> and the serial aliases would be the ideal I think. It would also be
>> possible to select a particular ordering for the DTB nodes to produce
>> "least-worst" behaviour from an existing EDK2 binary, but I'm not
>> sure if that's worth doing.
>>
>> What do the EDK2 folks think about what the correct behaviour
>> should be for a 2-UART setup?
>>
> 
> Hi Peter,
> 
> Thanks for the elaborate analysis.
> 
> EDK2's DEBUG output is extremely noisy, so being able to redirect this
> output to a different UART would be very useful.
> 
> The stdout-path is the intended console, and so we should honour that.
> This also means that we should parse aliases. But the console is
> actually configurable [persistenly] via the UEFI menu, and so it would
> be nice if we could take advantage of this flexibility. This means in
> principle that the UARTs should be represented via different device
> paths (which would include the base address so they are
> distinguishable) with perhaps a magical alias which is the default and
> is tied to whatever stdout-path points to. This way, all the logic we
> introduce is spec compliant and reusable on physical platforms with
> multiple UARTs.
> 
> The DEBUG output is a different matter. On physical hardware, this is
> typically configured at build time, as the info is needed extremely
> early and on a physical platform, the debug port generally doesn't
> change. Currently, we just grab the first UART that we encounter in
> the DT, but the logic used by the DEBUG code and the ordinary console
> driver are mostly separate.
> 
> What we might do is use stdout-path as well, unless a certain DT alias
> exist perhaps? We should probably align here with other projects,
> although this a distinction of the same nature may not exist there.
> 

Alias parsing in edk2 would be a bit too complicated for my taste. :)

I see the following two problems with the current state (based on
Peter's captures, using the original UART order in the DTB, i.e.,
<https://people.linaro.org/~peter.maydell/uart0.txt> and
<https://people.linaro.org/~peter.maydell/uart1.txt>):

(1) The DEBUG output switches from one UART to the other when we reach
the DXE_CORE (in this case, from UART0 to UART1, but the precise numbers
aren't the problem, the switchover is),

(2) The UEFI console (which is used by the setup browser, the UEFI
shell, grub, etc) is on UART1, while the kernel stuff is on UART0.

Here's what I'd propose:

- if there is only one UART in the DTB, no change

- otherwise, direct all DEBUG messages to the UART found *second* via
forward traversal in the DTB (let's call this UART1), and include the
UART found *first* via forward traversal in the DTB (let's call this
UART0) in the UEFI console. Furthermore, do not expose UART1 in the UEFI
protocol database *at all* (don't install devpath protocol / SerialIo
protocol); make it effectively hidden hardware (similarly how the x86
QEMU debug console, IO Port 0x402, is not exposed at all). Let the
system think there is only one UART (UART0), and treat UART1 as a
"bespoke", custom debug device only. This also ensures that existent
higher level products such as libvirt, which may only handle UART0 at
the moment, will expose the interactive console (UEFI and Linux) to the
user, and at worst the firmware debug log will not be captured.

For this a few custom DebugLib / SerialPortLib instances may have to be
created, but that should be doable.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109141): https://edk2.groups.io/g/devel/message/109141
Mute This Topic: https://groups.io/mt/101498371/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-