ttyO as portas não possuem o endereço de porta bom no QEMU 1.4.0 executando a imagem para o beagleboard-xm

Question

Estou executando uma imagem do Linux (kernel 3.2.8) para o beagleboard-xm na distribuição Ubuntu do emulador 1.4.0 do QEMU para o 13.04. Minha imagem é criada usando o Builderot beagle_defconfig. Eu adicionei alguns pkgs para poder depurar um pouco.

Chamada do QEMU cmd:

'$ sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty'
[sudo] password for emperador: 

char device redirected to /dev/pts/3 (label serial1)
char device redirected to /dev/pts/4 (label serial2)

O que eu quero fazer é ter uma comunicação entre o convidado e o host através dos quatro diferentes tipos de presentes presentes no convidado. O QEMU oferece facilidades para redirecionar o tráfego para algum dispositivo no lado do host. Meu problema é assim:

Na inicialização do kernel convidado, consigo ver que minha UART estava habilitada

[    2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
[    2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
[    2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
[    2.966825] console [ttyO2] enabled
[    2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3

Na verdade, quando eu vou ver o /proc/tty/driver e eu faço um gato no OMAP-SERIAL eu consigo ver isso serinfo: revisão do driver 1.0:

0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD
1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD
2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD
3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD

Eu sei que o ttyO2 está funcionando porque meu console foi redirecionado para ele. A coisa é que fazendo um set serial em qualquer um dos ttyO recebo a seguinte mensagem:

 [root@enu driver]# setserial -a /dev/ttyO0
/dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72
    Baud_base: 3000000, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal

O mesmo acontece com ttyO2. Eu tentei definir algumas configurações para qualquer um dos ttyO com setserial , mas eu sempre recebo a mesma mensagem:

[root@enu ~]# setserial /dev/ttyO0 uart 8250                              
setserial: can't set serial info: Invalid argument
[root@enu ~]# setserial /dev/ttyO0 port 0x4806a000
setserial: can't set serial info: Invalid argument

Ao olhar para o convidado /proc/tty/drives , é isso que vemos

/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
sdio_uart            /dev/ttySDIO  249 0-7 serial
acm                  /dev/ttyACM   166 0-31 serial
ttyprintk            /dev/ttyprintk   5       3 console
OMAP-SERIAL          /dev/ttyO     253 0-3 serial
serial               /dev/ttyS       4 64-95 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
unknown              /dev/tty        4 1-63 console

Basicamente, quero estabelecer uma comunicação serial entre um convidado e um host, mas as portas seriais no lado convidado não estão bem configuradas.

/sys/class/tty mostra que os drivers tty tinham sido vinculados a um dispositivo serial.

apareci antes, somente o omap uarts foi inicializado e anexado ao ttyO *. observe que o console foi redirecionado para ttyO2 pelas configurações do kernel. mas porque eu adicionei -serial stdio , o console foi redirecionado para o terminal que invocou o QEMU.

Se eu redirecionar o console usando primeiro -serial pty em vez de -serial stdio , posso solicitar ao console no minicom abrindo o arquivo criado no lado do host. Ainda nada acontece nos outros arquivos criados no lado do host para se comunicar através de outras portas.

No lado do host, eu abro /dev/pts/3 e /dev/pts/4 com o minicom ou fazendo cat neles

No lado do convidado:

Fiz echo "test" > /dev/ttyO0 ou 1 ou 3 nada. mas quando eu faço isso no ttyO2, "teste" no terminal do console (o que é normal).

agora ao usar qualquer um dos ttyS:

echo "test" > /dev/ttyS0

Eu obtenho

-bash: echo: write error: Input/output error

Eu fiz algumas pesquisas sobre esse erro e o que eu descobri é que isso pode ser muitas coisas. Mas uma coisa que notei foi que nenhum dispositivo ao lado da serial foi atribuído ao ttyS. e olhando para / proc / tty / driver / serial, vemos isto:

serinfo:1.0 driver revision:
0: uart:unknown port:00000000 irq:0
1: uart:unknown port:00000000 irq:0
2: uart:unknown port:00000000 irq:0
3: uart:unknown port:00000000 irq:0

também setserial -a /dev/ttyS0 confrim this:

/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
    Baud_base: 0, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal

Eu consegui fazer comunicação serial com muliples ports usig grml image em uma arquitetura x86. Então, parece que o lado do anfitrião é bom.

Se alguém já fez algo como este trabalho antes no QEMU -M beaglexm ou em qualquer outra arquitetura ARM, ficaria feliz em dar detalhes sobre a VM usada, a versão e distribuição do QEMU, bem como os detalhes do kernel e as configurações de imagem usadas.

    

Answer 1

Eu descobri qual era o meu problema, o QEMU não mapeia o chardev serial de nenhum arquivo extra-serial.

Depois de fazer o comando Invoke:

sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clonix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/5 (label compat_monitor0)
char device redirected to /dev/pts/7 (label serial1)
char device redirected to /dev/pts/10 (label serial2)

Podemos ver que 2 séries extras foram criadas com o rótulo serial 1 e 2. Mas se eu olhar a informação da árvore

 (qemu) info qtree

dev: omap_uart, id "uart4"
    revision = 82
    mmio_size = 4096
    baudrate = 812500
    chardev = uart4
    irq 3
    mmio 0000000049042000/0000000000001000
  dev: omap_uart, id "uart3"
    revision = 82
    mmio_size = 4096
    baudrate = 812500
    chardev = serial0
    irq 3
    mmio 0000000049020000/0000000000001000
  dev: omap_uart, id "uart2"
    revision = 82
    mmio_size = 4096
    baudrate = 812500
    chardev = uart2
    irq 3
    mmio 000000004806c000/0000000000001000
  dev: omap_uart, id "uart1"
    revision = 82
    mmio_size = 4096
    baudrate = 812500
    chardev = uart1
    irq 3
    mmio 000000004806a000/0000000000001000

Verificamos claramente que apenas o rótulo serial0 foi anexado a um uart (aquele definido para ser o console). As outras etiquetas (serial1 e serial2) não podem ser encontradas.

Com a imagem funcional de grml que jofel foi muito bom para me dizer, vemos isso:

  dev: i440FX-pcihost, id ""
    irq 0
    bus: pci.0
      type PCI
      dev: PIIX3, id ""
        addr = 01.0
        romfile = <null>
        rombar = 1
        multifunction = on
        command_serr_enable = on
        class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100)
        bus: isa.0
          type ISA
          dev: isa-serial, id ""
            index = 2
            iobase = 0x3e8
            irq = 4
            chardev = serial2
            wakeup = 0
            isa irq 4
          dev: isa-serial, id ""
            index = 1
            iobase = 0x2f8
            irq = 3
            chardev = serial1
            wakeup = 0
            isa irq 3
          dev: isa-serial, id ""
            index = 0
            iobase = 0x3f8
            irq = 4
            chardev = serial0
            wakeup = 0
            isa irq 4

todos os 3 lebels em série foram anexados a um chardev.

Agora só preciso fazer uma nova pergunta sobre como fazer o QEMU vincular essas lables ao meu beagleboard uarts.

Além disso, eu gostaria de acrescentar que o setserial não gerou nenhuma informação sobre o ttyO porque ele não suporta o omap uarts. setserial ? mostra quais dispositivos são suportados. No caso do ttyS, eu acho que é porque os drivers tty estão instalados, mas não há nenhum outro tipo de oem uarts bisede omap uarts para o bealgeboard no QEMU.

Muito obrigado a todos que deram uma olhada nesta questão e especialmente jofel.

    

Answer 2

O problema está no lado do host:

Você deve usar Pseudo-terminais ( -serial pty ) em vez de conectar-se a dispositivos de char "reais" (% código%).

qemu exibe o pty -chardev tty,... que ele realmente usa. Agora você pode usar este arquivo como uma porta serial normal do seu host.

Você pode repetir essa opção para obter mais ptys conectados a /dev/pts/xx no guest (se você usar /dev/ttyS[0-*] , será -serial stdio no guest, a primeira pty será /dev/ttyS0 ).