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! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
