Unable to do serial communication using -chardev tty

Bug #1188991 reported by Franco
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Invalid
Undecided
Unassigned

Bug Description

Im running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator.

What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side.

The command that I use to lauch QEMU is :

    sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -see -device usb-kbd -chardev tty,id=mytty,path=/dev/ttyS0

As it says in the QEMU's manual -chardev is suppose to connect to a local tty device at the path given

My problem goes like this:

At the guest kernel boot I'm able to see that my UART where enabled

    [ 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

In fact, when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this serinfo:1.0 driver revision:

    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

I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message:

     [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

The same goes with ttyO2. I tryed to set some sethings to any of the ttyO with setserial but I always get the same message:

    [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

basicly I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured.

When I open ttyS0 with minicom on the host side and do on the guest side

    echo "test" > /dev/ttyO0

The host recives nothing.

Anyone can tell me how I could remove tty modules on the guest side and try to insert it again to see if the setup resets properly or give me any advice on how to solve this problem. Plus if anyone has already tryed doing this kind on serial communication I would like to here from you.

Thank,
Francisco

t0n1 (dirtytoni)
information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
t0n1 (dirtytoni) wrote :

for me qemu crashes if I try to connect on /dev/pts/<whatever i'll be>

Revision history for this message
Peter Maydell (pmaydell) wrote :

Hi. The beaglexm model isn't part of upstream QEMU (it was in a set of downstream patches for OMAP3 which were never merged upstream and which are now essentially abandoned.) The root cause of this bug is that support for pass-through of a host serial port requires specific support in the device model for the UART to pass through the serial parameters (baud rate etc); this is implemented in some UART models but not all and apparently not in the OMAP3 UART code.

Since this isn't a bug in upstream QEMU, I'm going to close this (now four year old) bug report; sorry we can't be more helpful here :-(

Changed in qemu:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.