On Tue, Dec 12, 2017 at 02:31:05PM +0000, Ard Biesheuvel wrote: > On 12 December 2017 at 14:17, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 12 December 2017 at 14:16, Ard Biesheuvel <ard.biesheu...@linaro.org> > > wrote: > >> On 12 December 2017 at 14:13, Peter Maydell <peter.mayd...@linaro.org> > >> wrote: > >>> On 12 December 2017 at 14:12, Ard Biesheuvel <ard.biesheu...@linaro.org> > >>> wrote: > >>>> On 12 December 2017 at 14:10, Peter Maydell <peter.mayd...@linaro.org> > >>>> 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 pl011@0x9000000, 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 pl011@9000000. > > 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.
100% agree, which is why I said "If a user wires up a second UART...", but I guess my "Not wiring it up would lose the messages..." sentence was ambiguous. I didn't mean they'd output to no where, I meant those messages wouldn't be output. I.e. some sort of debug_printf() function would be written that only actually does a write when there's a debug UART on the other end to write to. I just commented on patch 2/3 of this series asking if we shouldn't just not allocate the second UART's MMIO region and IRQ, when the user doesn't provide a '-serial' option for it. If we didn't, then AAVMF would just not output debug messages when only one UART (the console) is found in the DT. Thanks, drew
