I was playing around with TTYs, and for qemu-system-x86_64 -M pc, whenever I pass the -serial option it crates a new TTY and I can attach a serial like ttyS0 and ttyS1 to it from Linux.

For ARM however, I can't get past the first ttyAMA0. If I add -serial, it does not show on info qtree and the kernel boot messages only find one:

9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54, base_baud = 0) is a PL011 rev1

Is it possible, and if not, is there a specific design reason for that?

I'm on QEMU v3.0.0. From the source it does not seem possible: https://github.com/qemu/qemu/blob/v3.0.0/hw/arm/virt.c#L138 as there is only one UART in the memory map:

[VIRT_GIC_REDIST] =         { 0x080A0000, 0x00F60000 },
[VIRT_UART] =               { 0x09000000, 0x00001000 },
[VIRT_RTC] =                { 0x09010000, 0x00001000 },

I'm doing this because I'm trying to see if connecting from a different serial will make KGDB work. On x86_64 I can connect to ttyS0, but I thought it was worth giving this a try on ARM. See also: https://stackoverflow.com/questions/22004616/how-to-debug-the-linux-kernel-with-qemu-and-kgdb/44197715#44197715


Pete has clarified that it is not currently supported and why at http://lists.nongnu.org/archive/html/qemu-discuss/2018-11/msg00001.html :

No, we only have a single UART on the virt board (because at the time I wrote the code I didn't see a reason for having more). We've had requests for a second UART before. The problem with adding it is that it will break UEFI booting, because if you have two UARTS in the dtb then Linux will use the first listed but UEFI will use the second, so commandlines which used to work will stop working.

This is probably handleable by either:

  • only creating the 2nd UART if given a -machine option to specifically ask for it
  • creating the 2nd UART on-demand based on how many -serial options were passed

but the first of those is clunky and I'm a bit worried the second will have unexpected side effects (eg via however libvirt starts QEMU.)

So it kind of went on the "wishlist" feature list. (The actual code required is probably only a dozen or so lines, it's figuring out the best mechanism for determining whether to create the second UART that's hard.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.