Re: qemu emulation for USB ports of Allwinner H3

[Guenter Roeck]

On 9/13/24 15:20, Niek Linnenbank wrote:
> 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
>  
> <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.
Yes, I found that as well, and Gerd has reported the same. The main difference,
as far as I can see, is that the host sees different register contents.
I am not sure if that is worth fixing. Either case it is not my highest 
priority.

Thanks,
Guenter

> Regards,
> Niek
>
> On Mon, Sep 9, 2024 at 11:33 AM Gerd Hoffmann <kraxel@redhat.com 
> <mailto:kraxel@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