[U-Boot] Problems with USB 3 hubs

[Aaron Williams <Aaron.Williams@caviumnetworks.com>]

Hi Marek,

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.
>> 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.

>
>> 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.

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.
>
>> -Aaron
> Best regards,
> Marek Vasut
-Aaron

-- 
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198  (510) 789-8988 (cell)