Find the answer to your Linux question:
Results 1 to 4 of 4
I am using qemu on a linux host (Fedora 19), with a linux guest (a RaspberryPi - arm1176 - running Wheezy Raspbian), and I'm wondering how an outside (host) application ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2013
    Posts
    2

    How does one set up serial communications in QEMU?


    I am using qemu on a linux host (Fedora 19), with a linux guest (a RaspberryPi - arm1176 - running Wheezy Raspbian), and I'm wondering how an outside (host) application can communication with an inside (guest) application.

    The command I'm using to run qemu is...

    qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/sda2 panic=1" -hda 2013-09-25-wheezy-raspbian.img

    I'd like to have a simple serial link from the host to the guest. For example, I assume having something send bytes to a /dev/xxx serial device somewhere on the host, which will reappear in the guest as some kind of /dev/yyy serial device, which can then read from it and write to it (or may be a separate device for each way).

    How can I do this?

    The qemu documentation says I can use the '-serial dev' argument, where dev could be a number of things (vc[:WxH], pty, none, null, /dev/XXX, /dev/parportN, file:filename, stdio, pipe:filename, ...), which apparently attaches to said device as seen from the host side, but where exactly does it appear inside the Raspbian guest linux? I.e. if I have something feeding bytes into a chosen /dev/xxx on the host, then where should I be reading from in the guest?

    Any help would be greatly appreciated, or if anyone could point me onto a tutorial on how to set this up, or let me know if this is not the way to do communications like this. - I want to avoid network communication as the board we're ultimately going to use will not have networking attached to it and will signal to it directly.

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,598
    Here is the qemu documentation on setting up the virtual serial port:
    Code:
    ‘-serial dev’
    Redirect the virtual serial port to host character device dev. The default device is vc in graphical mode and stdio in non graphical mode.
    
    This option can be used several times to simulate up to 4 serial ports.
    
    Use -serial none to disable all serial ports.
    
    Available character devices are:
    
    ‘vc[:WxH]’
    Virtual console. Optionally, a width and height can be given in pixel with
    
     	
    vc:800x600
    It is also possible to specify width or height in characters:
    
     	
    vc:80Cx24C
    ‘pty’
    [Linux only] Pseudo TTY (a new PTY is automatically allocated)
    
    ‘none’
    No device is allocated.
    
    ‘null’
    void device
    
    ‘/dev/XXX’
    [Linux only] Use host tty, e.g. ‘/dev/ttyS0’. The host serial port parameters are set according to the emulated ones.
    
    ‘/dev/parportN’
    [Linux only, parallel port only] Use host parallel port N. Currently SPP and EPP parallel port features can be used.
    
    ‘file:filename’
    Write output to filename. No character can be read.
    
    ‘stdio’
    [Unix only] standard input/output
    
    ‘pipe:filename’
    name pipe filename
    
    ‘COMn’
    [Windows only] Use host serial port n
    
    ‘udp:[remote_host]:remote_port[@[src_ip]:src_port]’
    This implements UDP Net Console. When remote_host or src_ip are not specified they default to 0.0.0.0. When not using a specified src_port a random port is automatically chosen.
    
    If you just want a simple readonly console you can use netcat or nc, by starting qemu with: -serial udp::4555 and nc as: nc -u -l -p 4555. Any time qemu writes something to that port it will appear in the netconsole session.
    
    If you plan to send characters back via netconsole or you want to stop and start qemu a lot of times, you should have qemu use the same source port each time by using something like -serial udp::4555@:4556 to qemu. Another approach is to use a patched version of netcat which can listen to a TCP port and send and receive characters via udp. If you have a patched version of netcat which activates telnet remote echo and single char transfer, then you can use the following options to step up a netcat redirector to allow telnet on port 5555 to access the qemu port.
    
    Qemu Options:
    -serial udp::4555@:4556
    
    netcat options:
    -u -P 4555 -L 0.0.0.0:4556 -t -p 5555 -I -T
    
    telnet options:
    localhost 5555
    
    ‘tcp:[host]:port[,server][,nowait][,nodelay]’
    The TCP Net Console has two modes of operation. It can send the serial I/O to a location or wait for a connection from a location. By default the TCP Net Console is sent to host at the port. If you use the server option QEMU will wait for a client socket application to connect to the port before continuing, unless the nowait option was specified. The nodelay option disables the Nagle buffering algorithm. If host is omitted, 0.0.0.0 is assumed. Only one TCP connection at a time is accepted. You can use telnet to connect to the corresponding character device.
    
    Example to send tcp console to 192.168.0.2 port 4444
    -serial tcp:192.168.0.2:4444
    
    Example to listen and wait on port 4444 for connection
    -serial tcp::4444,server
    
    Example to not wait and listen on ip 192.168.0.100 port 4444
    -serial tcp:192.168.0.100:4444,server,nowait
    
    ‘telnet:host:port[,server][,nowait][,nodelay]’
    The telnet protocol is used instead of raw tcp sockets. The options work the same as if you had specified -serial tcp. The difference is that the port acts like a telnet server or client using telnet option negotiation. This will also allow you to send the MAGIC_SYSRQ sequence if you use a telnet that supports sending the break sequence. Typically in unix telnet you do it with Control-] and then type "send break" followed by pressing the enter key.
    
    ‘unix:path[,server][,nowait]’
    A unix domain socket is used instead of a tcp socket. The option works the same as if you had specified -serial tcp except the unix domain socket path is used for connections.
    
    ‘mon:dev_string’
    This is a special option to allow the monitor to be multiplexed onto another serial port. The monitor is accessed with key sequence of <Control-a> and then pressing <c>. See monitor access Keys in the -nographic section for more keys. dev_string should be any one of the serial devices specified above. An example to multiplex the monitor onto a telnet server listening on port 4444 would be:
    
    -serial mon:telnet::4444,server,nowait
    ‘braille’
    Braille device. This will use BrlAPI to display the braille output on a real or fake device.
    
    ‘msmouse’
    Three button serial mouse. Configure the guest to use Microsoft protocol.
    In any case, I would recommend configuring your emulated operating system to allow ssh or telnet connections. That would be easier (in my opinion) to configure and run.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Nov 2013
    Posts
    2
    Quote Originally Posted by Rubberman View Post
    Here is the qemu documentation on setting up the virtual serial port:
    Yes, I have looked at the qemu documentation, it says I can use the '-serial dev' argument, where dev could be a number of things, which apparently attaches to said device as seen from the host side, but where exactly does it appear inside the Raspbian guest linux (or any other linux)? I.e. if I have something feeding bytes into a chosen /dev/xxx on the host, then where should I be reading from in the guest?

    Quote Originally Posted by Rubberman View Post
    In any case, I would recommend configuring your emulated operating system to allow ssh or telnet connections. That would be easier (in my opinion) to configure and run.
    I want to avoid network communication as the board we're ultimately going to use will not have networking attached to it, so we intended to signal in and out via a serial connection.

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,598
    I would assume it would be one of the /dev/ttyNN ports. It may be configurable, though if your host has some tty (serial) ports, then you would not want to use those. These issues are why I recommend you use a network connection (telnet or ssh) to get a console type of connection with the VM.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •