Hi, On 18 December 2015 at 20:05, Marek Vasut <ma...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
