[U-Boot] Problems with USB 3 hubs

[U-Boot] Problems with USB 3 hubs

[Aaron Williams]

Hi all,

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?

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.

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

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.

-Aaron

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

[U-Boot] Problems with USB 3 hubs

[Marek Vasut]

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.

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

> 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 :)

> -Aaron

Best regards,
Marek Vasut

[U-Boot] Problems with USB 3 hubs

[Aaron Williams]

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)

[U-Boot] Problems with USB 3 hubs

[Marek Vasut]

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] Problems with USB 3 hubs

[Simon Glass]

Hi,

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