XHCI bringup on the Raspberry Pi 4

Nicolas Saenz Julienne nsaenzjulienne at suse.de
Wed Apr 1 22:47:57 CEST 2020


On Wed, 2020-04-01 at 22:14 +0200, Marek Vasut wrote:
> On 4/1/20 10:13 PM, Nicolas Saenz Julienne wrote:
> > On Wed, 2020-04-01 at 20:50 +0200, Marek Vasut wrote:
> > > On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote:
> > > > Hi All,
> > > 
> > > Hi,
> > > 
> > > > I'm working on enabling the VIA805 XCHI controller found on the new
> > > > Raspberry
> > > > Pi 4. The controller sits behind a PCIe bus, which I've already
> > > > implemented[1]
> > > > and will submit once the XCHI issues are resolved, as it's worthless
> > > > otherwise.
> > > > 
> > > > The XHCI initialization gets stuck after issuing the fist 'enable slot'
> > > > command. I've been reviewing the whole init process and comparing it to
> > > > Linux's
> > > > for days without finding anything fishy. DMA constraints, which are
> > > > important
> > > > on the RPi are mantained, and on top of that, I can confirm DMA trough
> > > > PCIe
> > > > works fine as I see two 'port status change' events available in the
> > > > ring
> > > > before completly stalling. Also note that, unsurprisingly, the CRR bit
> > > > in
> > > > the
> > > > CRCR register (which marks the running state of the Command Ring state
> > > > machine)
> > > > is never set after ringing the relevant doorbell.
> > > > 
> > > > I'm clueless at this point, I figure the VIA805 is sensitive to the
> > > > ordering
> > > > of
> > > > some of the operations we perform in u-boot, or worse, the timing. For
> > > > example,
> > > > I tried replicanting Linux's behaviour with regard to 'port status
> > > > change'
> > > > events, processing them before calling the 'enable slot' command. I also
> > > > tried
> > > > to mimic Linux by enabling port-0's power (the USB3 port) before
> > > > starting
> > > > the
> > > > HC. Again, no luck.
> > > > 
> > > > I attached the usb/xhci debug output, any ideas on where to look will be
> > > > apreciated.
> > > 
> > > Try disabling caches (dcache off ; icache off) and see if it magically
> > > starts working. That comes to mind.
> > 
> > Same outcome :(
> 
> Hmmm, no idea then, maybe others have some.
> 
> I presume PCIe works correctly , right?

I was also responsible for the Linux version of the PCIe driver so I know it
fairly well. I also double-checked all pcie-brcmstb's registers have the
expected values.

From the USB perspective, I'm both able to map XHCI's registers into memory and
get some output out of the event ring, which implies XHCI accessed memory
trough the bus. On top of that if something went wrong with PCI there is a
register that should point it out, Host System Error (HSE), which so far has
been silent.

Overall I'm confident PCIe is fine.

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200401/df562ad7/attachment.sig>


More information about the U-Boot mailing list