On Thu, 21 Sept 2023 at 10:50, Peter Maydell <peter.mayd...@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. -- Ard.
