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

[Jakob Bohm]

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
> LU7DID
>
> On Fri, Sep 13, 2019 at 6:27 AM Peter Maydell <address@hidden>
> wrote:
>
> > 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
> > recognize
> > > it; but ultimately I found the problem is the x86 debian running under
> > qemu
> > > isn't seeing it at all.
> > >
> > > It seems this version of qemu doesn't handle the usual arguments to
> > define
> > > 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.


Enjoy

Jakob
--
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