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 -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
