[coreboot] xHCI support for x86

[Nico Huber]

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