Hi,
On 23.11.2016 11:09, Pitrolle Jean-Jacques wrote:
Hello *, I try to integrate coreboot *libpayload usb stack* in a custom binary for x86. I already succeed integration of *ehci* for *qemu* and *core 2 duo* platforms.
But things seems to be not so easy for *xhci*. When I try to run coreboot master branch (with hash 8bf3f7a) on qemu (version 2.7.0) with following line : % qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -drive if=none,id=usbstick,file=/tmp/qemu_usb.disk -usb -device nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=usbstick
I get these output lines concerning xHCI controller (nec-usb-xhci) : 8<--- [..] 00:04.0 0194:1033.0 xHCI controller xhci_init: regbase: 0xfe070000 xhci_init: caplen: 0x40 xhci_init: rtsoff: 0x1000 xhci_init: dboff: 0x2000 xhci_init: hciversion: 0.0 xhci_init: Unsupported xHCI version [..] --->8
The same result is reached with qemu-system-i386...
Is it the expected result on qemu?
it looks odd to me. We wrote the ancestor of this xHCI driver against qemu but stopped testing it when we switched to real hardware. I would have expected an hciversion around 0.9*. The libpayload driver currently checks for hciversion > 0.96. The values above hciversion look sane, so I suspect qemu to tell a bad version.
I don't have any motherboard supported by coreboot, so I try a custom binary on
How is this custom binary build? In which environment does it run? It's hard to make assumptions about the driver without knowing the details.
a *Xeon* processor (processor D-1500).
So you are using the xHCI controller built into the SoC? or an extension card?
The xHCI version is supported (hciversion: 1.0) but things turn bad when starting xHCI controller i.e xhci->opreg->usbcmd |= USBCMD_RS in *xhci_start* : the program hangs... The registers usbcmd and usbsts before this command seems to have proper values (a usb key is connected.) 8<--- [..] xhci_start - usbcmd:0 - usbsts:11 [..] --->8
This seems to be related to interrupter configuration. When I comment out the two lines in *xhci_reinit* 8<--- [..] xhci->hcrreg->intrrs[0].erstba_lo = virt_to_phys(xhci->ev_ring_table);
I'd suspect that the address returned by virt_to_phys() is wrong or not accessible by the controller.
xhci->hcrreg->intrrs[0].erstba_hi = 0;
Are you sure it's a 32-bit address?
[..] --->8 xhci_start works as expected i.e not hangs.
But the sequence following with *NOOP* to test command ring and event ring mechanism fails. 8<--- [..] NOOP run #0 Transfer TRB (@0x8051700): PTR_L 0x00000000 PTR_H 0x00000000 STATUS 0x00000000 CNTRL 0x00005c00 TL 0x0000 TDS 0x0000 C 0x0000 ISP 0x0000 CH 0x0000 IOC 0x0000 IDT 0x0000 TT 0x0017 DIR 0x0000 Command 23 (@0x8051700) Warning: Timed out waiting for TRB_EV_CMD_CMPL. Command ring is running [..] --->8
As I understand it is mandatory to have the first interrupter configure to manage at least one event ring (4.9.4 Event Ring Management - eXtensible Host Controller Interface Revision 1.1).
Does someone succeed with xHCI support for x86 board? Did I miss something concerning xHCI configuration?
It's working in coreboot payloads in many production systems.
Nico