O QEMU -M virt no arm / aarch64 possui vários TTYs seriais, como PL011 ttyAMA0 e ttyAMA1?

0

Eu estava brincando com TTYs e, para qemu-system-x86_64 -M pc , sempre que eu passar a opção -serial , cria um novo TTY e posso anexar uma série como ttyS0 e ttyS1 ao Linux.

No entanto, para o ARM, não consigo passar do primeiro ttyAMA0 . Se eu adicionar -serial , ele não será mostrado em info qtree e as mensagens de inicialização do kernel só encontrarão uma:

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

É possível, e se não, existe uma razão de design específica para isso?

Estou no QEMU v3.0.0. A partir da fonte, não parece possível: link é apenas um UART no mapa de memória:

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

Estou fazendo isso porque estou tentando ver se a conexão de uma serial diferente fará o KGDB funcionar. No x86_64 eu posso conectar-me a ttyS0 , mas achei que valeria a pena experimentar isso no ARM. Veja também: link

    
por Ciro Santilli 01.11.2018 / 10:42

1 resposta

0

O Pete esclareceu que não é suportado no momento e por que no link :

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

    
por 02.11.2018 / 09:49