[SLOF] [PATCH v2 0/5] usb: Add support for USB3 devices behind a hub
aik at ozlabs.ru
Wed Aug 3 18:01:29 AEST 2016
On 03/08/16 17:20, Thomas Huth wrote:
> On 03.08.2016 06:28, Alexey Kardashevskiy wrote:
>> On 02/08/16 19:19, Thomas Huth wrote:
>>> The current XHCI code in SLOF can not deal with USB devices that
>>> are attached to a hub, since it does not set up the so-called
>>> "route string" in the slot context data yet. For example, with the
>>> following command, SLOF fails to detect the keyboard and it is not
>>> possible to type in any key in the VGA console:
>>> qemu-system-ppc64 -nodefaults -vga std \
>>> -device nec-usb-xhci,id=controller1 \
>>> `for ((i=0;i<32;i++)); do echo " -device usb-mouse" ; done ` \
>>> -device usb-kbd -serial stdio
>> I applied and pushed it to github
>> however I got few questions.
>> The command line above does not add any hub, this does:
> Have you tried it? For me, QEMU automatically adds some hubs here
> inbetween because otherwise, there would not be enough free ports to
> connect all USB devices.
Ah, this is why 32 mice :) I have not tried mice, I am using as little
devices as I can.
>> /home/aik/qemu-system-ppc64 -enable-kvm -m 4G \
>> -trace events=qemu_trace_events -vga std -nodefaults \
>> -device nec-usb-xhci,id=nec-usb-xhci0 \
>> -device usb-hub,id=usb-hub0,port=1 \
>> -device usb-kbd,id=usb-kbd0,port=1.2 \
>> -serial stdio -bios slof-xhci.bin -machine pseries -smp 16,threads=8
>> I am surprised there is no "usb-hub0.1"-ish bus in "info qtree" so I am not
>> sure my command line puts the keyboard to that hub but I think it does.
> Simply type "dev / ls" at the SLOF prompt. There you can see that it is
> indeed connected to a hub:
> 0 > dev / ls
> 7e520340 : /
> 7e520718 : |-- cpus
> 7e5209a0 : | +-- PowerPC,POWER7 at 0
> 7e5212d0 : |-- pci at 800000020000000
> 7e523858 : | |-- usb at 1
> 7e559960 : | | +-- hub at 1
> 7e55a020 : | | +-- usb-keyboard at 2
Right, this is what I get.
>> What I also noticed, quite often (60% of attempts actually), keyboard does
>> not work in VNC at all. It seems to be a QEMU/VNC issue as
>> minimizing/maximizing the VNC window helps in 80% cases - have you seen this?
> No, I haven't experienced this. But I've already heard of VNC keyboard
> issues in the past, especially when the server is located far away and
> there is a network lag inbetween (see
> https://bugs.launchpad.net/qemu/+bug/1502884 for example) ... maybe
> you're suffering from such a problem? Maybe try a different VNC client?
> Do you also have got problems when the guest has finally booted the
> Linux kernel?
I am using tightvnc 1.3.10 running on KVM host which is here, in the lab,
and grub seems to have the same issue. I cannot tell about linux - I tried
some images and they just do not show the login prompt :) Weird.
More information about the SLOF