[U-Boot] Problems with USB 3 hubs

[Marek Vasut]

On Saturday, December 19, 2015 at 01:55:22 AM, Aaron Williams wrote:
> Hi Marek,

Hi!

> On 12/17/2015 07:06 AM, Marek Vasut wrote:
> > On Thursday, December 17, 2015 at 10:12:08 AM, Aaron Williams wrote:
> >> Hi all,
> > 
> > Hi Aaron,
> > 
> >> I maintain U-Boot for the Cavium Octeon series of 64-bit MIPS processors
> >> and have been experiencing problems with USB 3 hubs with XHCI.
> >> 
> >> If I plug in a USB 3 thumb drive into a USB 3 hub it is not seen. After
> >> fixing numerous endian issues USB 3 thumb drives are fully supported via
> >> XHCI as long as there is no USB hub in the path.
> >> 
> >> Delving into the XHCI and USB hub code it appears that there is no
> >> proper support for USB 3 hubs which have a number of differences from
> >> USB 2. Is any work going on in this area?
> > 
> > Not to my knowledge, sorry.
> > 
> >> For example, the hub descriptor format has changed as well as the BOS
> >> descriptor. I'm looking at the Linux XHCI and hub code and see a lot of
> >> USB 3 changes not present in U-Boot.
> >> 
> >> I have been backporting a lot of the support to our current bootloader
> >> code base which is based on the 7/2013 release.
> >> 
> >> I might add that I found a lot of issues in the USB code, especially
> >> XHCI that are endian related since our Octeon processors are running in
> >> big endian mode, plus the fact that DMA addresses are not the same as
> >> pointer addresses, plus the USB code is not 64-bit friendly.
> > 
> > I see, I suspect the code was mostly tested on ARMv7 which is why those
> > issues went undetected.
> 
> I agree. The EHCI code also had some endian issues and 64-bit issues. We
> also run U-Boot in virtual memory (believe it or not, it makes things a
> lot easier for us since we have been doing this long before U-Boot had
> any 64-bit support. While pointers are 32-bit addresses, they must be
> mapped to 64-bit addresses for DMA. Even without virtual memory,
> pointers on MIPS are typically not DMA addresses when running out of
> KSEG0 or using XKPHYS addresses.

Okay, that's fine. There already is some sort of mapping support in U-Boot.

> >> While I can gladly share my code and changes, we currently are not using
> >> the latest release, nor will I have time to upgrade to it for at least
> >> several months due to too many other projects on my plate (it doesn't
> >> help matters that we don't use git internally for U-Boot).
> > 
> > Is it possible for you to boot latest mainline U-Boot on octeon, fix the
> > issues, submit the fixes and then backport them?
> 
> Unfortunately the work involved to make the mainline work on Octeon
> would be very significant. We have over 900K lines of code specific to
> our chip in U-Boot, not counting all of the drivers and start-up code.

Well, that's a lot. You can start small, I don't believe basic boot and
serial port support would require all that.

> >> At some point I would love to get our code base merged in but this will
> >> be a significant effort due to the sheer amount of code involved.
> > 
> > Patches are welcome :)
> 
> I can provide our code. I have tried to minimize our changes as much as
> possible to existing U-Boot code in order to make upgrading the U-Boot
> base easier. Mostly we're missing the new DM code and using uintptr_t
> stuff. All changes I made that are specific to our CPU are handled by
> #ifdefs. Most of the changes could be handled in a portable manner by
> replacing the virt_to_phys() calls with some other name to map pointers
> to DMA addresses. On MIPS platforms this mapping is typically required,
> even without virtual memory.

CCing some more people.

> I have also had to make fixes for certain things in the USB storage. I
> will try and follow up later with a list of what fixes are needed where
> in the code.

Thanks!