Peter & Jakob,
Thank you very much for your very clear explanation.
The /dev/ttyUSB0 is at the host and it does work, now it's clear for me how
to make it visible from the chroot environment as well (and a bit of
additional information on how qemu does work in user mode).
Thanks! Pedro.
--
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
On Fri, 13 Sep 2019 at 13:23, Dr. Pedro E. Colla wrote:
> 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
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
On Thu, 12 Sep 2019 at 21:28, Dr. Pedro E. Colla 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
Hi,
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
