[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] QEMU-i386-static question

From: Jakob Bohm
Subject: Re: [Qemu-discuss] QEMU-i386-static question
Date: Fri, 13 Sep 2019 14:44:50 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

The qemu-static chroot still uses the native (ARM) kernel and the
native (ARM) device driver for your serial port.

You just need to add the /dev/ttyUSB0 device file in the chroot.

Either as a bind mount accessing the same file in the native root,
or as a another device file inode created with the mknod
command to match the other one.

Then when x86 code opens "/dev/ttyUSB0" it will get the one in its
chroot, which points to the same kernel mode device object as the
one in the real (ARM) root.  Each I/O call (open, close, read, write,
ioctl etc.) will be passed from x86 code, through the qemulated x86
syscall to the identical ARM syscall, and then the ARM kernel will
access the real USB device on the real USB bus.

On 13/09/2019 14:22, Dr. Pedro E. Colla wrote:
Hi Peter,

Thank you very much for your kind and detailed response.

As it's a cross architecture setup chroot operates on a different platform
(ARM host vs. X86 guest) so using binfmt qemu-i386-static is invoked by the
chroot command, therefore when executed qemu has been already executed.
Under that configuration /dev/ttyUSB0 doesn't exists. I might install the
USB Prolific serial port drivers once in X86 but I don't believe that would
make the chrooted environment (under qemu) to share the port with the host,
does it?

Thanks in advance for your thoughts and tips on the subject. 73 de Pedro

On Fri, Sep 13, 2019 at 6:27 AM Peter Maydell <address@hidden>

On Thu, 12 Sep 2019 at 21:28, Dr. Pedro E. Colla <address@hidden> wrote:
I'm trying to implement a chroot environment on a Raspberry Pi with the
ultimate intention to run Windows applications using wine.

To do that first an x86 chroot environment using the subject emulator is
used, then once inside a shell of it wine is invoked.

The whole thing works surprisingly well despite my initial expectations
given the small CPU resources available.

However, I do need for the Windows program to access the serial port
(/dev/ttyUSB0 at the host environment); the Windows problem is unable to
use that port despite different ways to configure it for wine to
it; but ultimately I found the problem is the x86 debian running under
isn't seeing it at all.

It seems this version of qemu doesn't handle the usual arguments to
character devices or usb devices.
QEMU has two modes of operation:
  (1) system emulation, where we emulate an entire hardware
  system for the guest, including various devices. In this mode
  we allow the user to configure how our emulated devices hook
  up to the host system via the command line arguments you mention

  (2) user-mode emulation, where we emulate just a single guest
  Linux process, and pass through all the system calls it makes
  to the host. In this mode there is no need for any kind of
  command line options to configure devices, because there are
  no devices to configure.

qemu-i386-static is the user-mode emulator, case (2). If you
would like binaries you run under it to be able to see
the host's /dev/ttyUSB0 you need to ensure that that (special)
file exists in the chroot before you run QEMU. Then the guest
binary will be able to open it, exactly as a host binary could.

After that, getting it to be visible to Windows programs running
under Wine is a Wine configuration question.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]