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!