[Qemu-discuss] Can QEMU -M virt on arm / aarch64 have multiple serial TTYs like such as PL011 ttyAMA0 and ttyAMA1?

[Ciro Santilli]

https://unix.stackexchange.com/questions/479085/can-qemu-m-virt-on-arm-aarch64-have-multiple-serial-ttys-like-such-as-pl011-t

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

[Peter Maydell]

Post by Ciro Santilli
https://unix.stackexchange.com/questions/479085/can-qemu-m-virt-on-arm-aarch64-have-multiple-serial-ttys-like-such-as-pl011-t
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
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?

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.)

thanks
-- PMM