Hello Guenter, Gerd, Thanks for bringing up the question. To be honest I do not know a lot about USB internals. When adding the orangepi-pc board emulation, it seemed fairly easy to add it, but apart from a few basic tests, I did not use the USB functionality extensively.
I do own the actual Orange Pi PC board hardware, so I downloaded the 'Orangepipc_2.0.8_ubuntu_bionic_server_linux5.4.65.7z' image from the official page to test: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-PC.html After booting that image from an SD card with a serial console, this is the output from the same 'lsusb' command: root@orangepipc:~# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepipc:~# uname -a Linux orangepipc 5.4.65-sunxi #2.0.8 SMP Mon Oct 26 10:20:38 CST 2020 armv7l armv7l armv7l GNU/Linux root@orangepipc:~# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS" It does look like the same output compared to what we see under Qemu. But I'm not very sure if this confirms we are emulating correctly or not. Regards, Niek On Mon, Sep 9, 2024 at 11:33 AM Gerd Hoffmann <kra...@redhat.com> wrote: > On Sun, Sep 08, 2024 at 11:36:18AM GMT, Guenter Roeck wrote: > > Hi, > > > > the Allwinner H3 USB port qemu emulation creates separate USB ports > > for its EHCI and OHCI controllers, resulting in a total of 8 USB ports. > > From the orangepi-pc emulation: > > > > # lsusb > > Bus 005 Device 001: ID 1d6b:0002 > > Bus 003 Device 001: ID 1d6b:0002 > > Bus 001 Device 001: ID 1d6b:0002 > > Bus 008 Device 001: ID 1d6b:0002 > > Bus 006 Device 001: ID 1d6b:0001 > > Bus 004 Device 001: ID 1d6b:0001 > > Bus 002 Device 001: ID 1d6b:0002 > > Bus 009 Device 001: ID 1d6b:0001 > > Bus 007 Device 001: ID 1d6b:0001 > > > > The SoC supports EHCI companion interfaces, and my understanding is that > > it only has four physical USB ports. Does the real hardware instantiate > > separate EHCI and OHCI interfaces (for a total of 8 USB ports), or does > it > > use the companion functionality ? > > Well, on the guest side you'll see 8 ports even when using the companion > functionality. Each physical usb port has one ehci port (used when you > plug in usb 2.0+ devices) and one ohci port (used when you plug in usb > 1.1 devices). > > The main difference is on the qemu backend side. When using the > companion functionality you have a single qemu usb bus accepting both > 1.1 and 2.0+ devices. When not using the companion functionality you > have one usb bus accepting 2.0+ devices and another usb bus accepting > usb 1.1 devices ... > > The guest-visible difference is an per-port bit in ehci registers which > controls whenever ehci or the companion manages the device plugged in. > This bit exists for backward compatibility (guests without ehci driver > can manage all devices via ohci, with usb 2.0+ devices being downgraded > to 1.1 compatibility mode then). > > > If the real hardware only instantiates four USB ports (or, in other > words, > > if it utilizes EHCI companion functionality), would it make sense to > > reflect that in qemu ? > > Yes. > > take care, > Gerd > > -- Niek Linnenbank
