[U-Boot] Problems with USB 3 hubs

[Simon Glass]

Hi,

On 18 December 2015 at 20:05, Marek Vasut <marex at denx.de> wrote:
> 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.

It might be easier once you move to a newer U-Boot. But it would be
great to have a basic 'boot to a prompt' board implementation.

Regards,
Simon