0

There is a sensor. This sensor is connected via USB, the file name is ttyUSB0 lying in the /dev folder. There is a set of commands:

1: -m 1024 \
2: -cpu core2duo \
3: -serial stdio \
4: -display none \
5: -hda /dev/sdb \
6: -usb \
7: -usb -device usb-host:productid=0x1a86,vendorid=0x7523 \
8: -drive file=/home/fedor/Git/usb.img \
9: -kernel $BUILD/$E_INIT/$BUILD_TARGET

The commands to connect the USB device are on lines 6,7,8 and they don't work. The following error message is displayed:

-device usb-host:productid=0x1a86,vendorid=0x7523: Parameter 'driver' is missing

The file is given full read/write rights sudo chmod -R uog=rwx /dev/ttyUSB0

Create a file image using the command:mkisofs -J -o usb.img /dev/ttyUSB0

fedor@fedor-VirtualBox:~$ lsusb
Bus 001 Device 003: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I have already reviewed a bunch of sources, tried a bunch of options, but the device could not be connected.

ADDITIONAL RESPONSE:

the first link - enter link description here

second link - enter link description here

Third link - enter link description here

That's it, I won't find anything else. Yes, these are the instructions to run, they are in a file with the extension .sh, it's big, it's just a small part of it. Everything works if instead of 3 lines I insert -serial /dev/ttyUSB0, but there is no exchange with the device.I just want to throw a USB device into qemu and nothing else.

to sum up. The device could not be reset, why? I do not know, maybe someone else can tell me.

1: sudo modprobe -r ch341 To return how everything was, you need to write sudo modprobe ch341.

2: sudo chown -R fedor /dev/bus/usb.

3: qemu-system-x86_64 -helpI write in the terminal and get 'USB options':

3.1: -usb enable on-board USB host controller (if not enabled by default).

3.2: -usbdevice name add the host or guest USB device 'name'.

4: lsusb -v Next, I write the command not lsusb, but lsusb -v. I find two lines: idVendor 0x1a86 QinHeng Electronics, idProduct 0x7523 CH340 serial converter.

5: Next, I open qemu and check whether the device is visible or not. I write in the terminal: qemu-system-x86_64. Qemu opens.

5.1: I open the qemu terminal by pressing Ctrl+Alt+2

5.2: Inside qemu I write info usbhost. After that, I am given the following information: Bus 1, Addr 3, Port 2, Speed 12 Mb/s, Class ff: USB device 1a86:7523

6: After making sure that the device is available, I write the following in a file with the .sh extension:

1:  -m 1024 \
2:  -cpu core2duo \
3:  -serial stdio \
4:  -display none \
5:  -hda /dev/sdb \
6:  -usb \
7:  -usbdevice host,vendorid=0x1a86,productid=0x7523 \
8:  -kernel $BUILD/$E_INIT/$BUILD_TARGET

Added lines 6 and 7

7: The following error is displayed: could not add USB device 'host,vendorid=0x1a86,productid=0x7523'

Improve this question
4
  • Your "set of commands" looks like a series of options to some unspecified command on the line preceding your line #1. (The backslash at the end of the line is a common way to indicate "this command continues on the next line".) /dev/ttyUSB0 is a USB-serial port converter, which may be integrated into your sensor. Unfortunately that means the lsusb output only tells about the converter chip, not about the sensor itself. Commented Dec 6, 2021 at 13:12
  • Your mkisofs command would create an ISO image file as usb.img with just one file named ttyUSB0, supposedly containing either nothing at all or maybe a dump of information coming in from your sensor. Since it looks like you might be trying to run a qemu VM with usb.img as its system disk, that seems counterproductive - it would overwrite the existing usb.img virtual disk with non-bootable data. Commented Dec 6, 2021 at 13:23
  • To be honest, I do not know how to do it correctly, I found a similar example on this site and it featured a file with the .img extension. I tried to just specify /dev/ttyUSB0, but he started swearing. I do not know what the difference is. Commented Dec 6, 2021 at 13:29
  • Please provide links to the instructions you're trying to follow and/or describe in more detail what you're trying to achieve. From what you've written so far, it's only clear that you seem to be trying to run some kind of a Qemu virtual machine with some kind of a sensor that is attached via a USB-serial converter, but without any further facts it's going to be really difficult for anyone to guess what you're trying to do and help you. Please edit your question rather than answering in the comments. Commented Dec 6, 2021 at 13:36

2 Answers 2

Reset to default
1

It looks like you're doing nested virtualization: you are running Linux in a VirtualBox VM, and trying to run another Qemu VM inside that VM - is that correct?

You should also specify the name and version of the Linux distribution you're using, or at least the version of Qemu you're using.

If you use -serial /dev/ttyUSB0, then the sensor should appear within the Qemu VM as a "real" serial device, i.e. as /dev/ttyS0 if the OS of the Qemu VM is Linux, or as COM1: if Windows.

If you want to give the serial converter (and thus the sensor) to the Qemu VM's control as a USB device, you will have to first have VirtualBox present it to your Linux VM. Since it's visible in the lsusb listing, you have already achieved that. The next step would be to disconnect the Linux VM's usbserial driver from the device. There are many ways to achieve that:

Unload the USB serial driver module responsible for the serial converter support:

sudo modprobe -r ch341

Or find the USB path specification for the serial converter, and tell the driver to unbind it. For example:

ls -l /sys/bus/usb-serial/devices/ttyUSB0
lrwxrwxrwx 1 root root 0 Dec  6 16:47 /sys/bus/usb-serial/devices/ttyUSB0 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/ttyUSB0/

Here in my example, the USB path is 1-8:1.0. To unbind it:

echo -n "1-8:1.0" > sudo tee /sys/bus/usb/drivers/ch341/unbind

You must find the correct path for your system.

Once the USB-serial converter driver is out of the way, you'll need to ensure that Qemu has permission to access the "raw" USB device. If you are running the VM as user fedor:

 sudo chown -R fedor /dev/bus/usb

After this, you should be able to start your Qemu VM and have it claim the USB-serial converter device for itself.

Note that your list of options specifes -usb twice, on lines #6 and #7. Perhaps just once would be enough?

Also, the Qemu USB emulation documentation for Qemu 4.2.50 says the USB -device option should be

-device usb-host,productid=0x1a86,vendorid=0x7523 \

instead of your

-device usb-host:productid=0x1a86,vendorid=0x7523 \

Note the comma instead of the colon. This might be the cause of your error message, or the syntax might vary in different versions of Qemu.

None of your three links mention your mkisofs command: it's still unclear to me what you wish to achieve with that.

Improve this answer
13
  • You're right, I'm using VirtualBox from Windows. As soon as I used the command, the device disappeared from the list(/dev/ttyUSB0). So after the first step I got stuck. Where there is a comma error, I wrote it wrong here, everything is correct in the code. Kindly write down the steps of how to do everything. Commented Dec 7, 2021 at 8:38
  • Here is the qemu version = qemu-system-x86_64 QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-9ubuntu3.2) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers Commented Dec 7, 2021 at 8:47
  • 1
    The vanishing of /dev/ttyUSB0 from the VirtualBox VM is expected - the USB device must not be controlled by the VirtualBox VM's USB-serial driver, so that the raw USB device can be given to the Qemu VM's control. When -device usb-host,productid=0x1a86,vendorid=0x7523 is specified to Qemu, it controls the USB device via /proc/bus/usb/*, not through /dev/ttyUSB0. If the VirtualBox VM has its USB-serial driver attached to the same USB device, Qemu's control attempt will fail. Commented Dec 7, 2021 at 9:36
  • I wrote the command sudo modprobe -r ch341 the file from /dev/ttyUSB0 has disappeared. But the /usb folder in /proc/bus did not appear. Commented Dec 7, 2021 at 10:27
  • Sorry, my mistake. Although it used to be /proc/bus/usb, it's /dev/bus/usb on modern distributions - so the command should be sudo chown -R fedor /dev/bus/usb instead. (Now I feel old - it has been that way for quite a long time now...) Commented Dec 7, 2021 at 10:34
1

There's no need to modprobe -r whatsoever. AFAIK qemu handles everything for you except permission (hence the setfacl; chown / chmod are fine too).

enter image description here

enter image description here

In my experience one should emulate a host controller of the same type as the one that the device is attached to on the host. Therefore with most modern machines the choice would be qemu-xhci, and for some older machine you might want to try usb-ehci instead.

EDIT: It seems like if the device is a full (12M) or low (1.5M) speed device and you can't use an emulated XHCI host controller for whatever reason, -usb (which emulates a UHCI controller) device is a right switch to use.

If your qemu is too old to have either of them, you can find out what alternatives are available with:

$ qemu-system-x86_64 -device help | grep '[e|x]hci'
name "ich9-usb-ehci1", bus PCI
name "ich9-usb-ehci2", bus PCI
name "nec-usb-xhci", bus PCI
name "qemu-xhci", bus PCI
name "usb-ehci", bus PCI

Ref.: https://github.com/qemu/qemu/blob/master/docs/system/devices/usb.rst

Improve this answer
5
  • INPUT - -device qemu-xhci \. -device usb-host,vendorid=0x1a86,productid=0x7523 \ OUTPUT - 'usb-host' is not a valid device model name Commented Dec 9, 2021 at 7:49
  • /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/12p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ch341, 12M I am interested in 3 device Commented Dec 9, 2021 at 7:52
  • How old is your qemu (qemu-system-x86_64 -version)? Could you also add the output of qemu-system-x86_64 -device help | grep usb to your question? Commented Dec 9, 2021 at 7:59
  • Btw are you trying to "nested passthrough"? (i.e. the qemu VM is running on a VirtualBox VM?) Not sure if that could work anyway. Also, while there's pci-ohci, you might have a higher chance to succeed if you switch to the XHCI host controller provided by the Oracle VirtualBox extension (assuming the device is attached to an XHCI controller on the "real" host). Commented Dec 9, 2021 at 8:06
  • There is a Windows operating system, it has a VirtualBox program, the Linux operating system is running in VirtualBox, it has QEMU, a third-party operating system is running in QEMU. In Windows, the device is connected as a COM port, and in Linux it is visible as a USB device. How should it be transmitted correctly? Commented Dec 9, 2021 at 8:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.