* [U-Boot] XHCI Issues
@ 2014-01-14 2:20 Aaron Williams
2014-01-14 4:28 ` Aaron Williams
0 siblings, 1 reply; 3+ messages in thread
From: Aaron Williams @ 2014-01-14 2:20 UTC (permalink / raw)
To: u-boot
Hi all,
I am bringing up XHCI support for our SOC and have run into several
issues with U-Boot's XHCI code.
1. I need to use a wrapper I call xhci_readl/xhci_writel since all of
our I/O is to 64-bit addresses rather than readl/writel which work for
PCIe. While xhci_readl/xhci_writel is used in most places there are a
few places this is missing.
2. A memory address used by a pointer is not a DMA address on MIPS. On
MIPS a wrapper is needed for all read/write operations to descriptors to
map the addresses. Generally U-Boot runs in KSEG0 where a pointer always
has bit 31 set. In our case we run it in virtual memory with U-Boot
loaded at the top of memory (which might be as high as 64GB+256MB).
3. xhci_alloc_virt_device is missing a conversion from big endian to
little endian on line 401 of xhci-mem.c.
4. I keep getting hit with
BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
!= COMP_STOP)));
on line 491 in xhci-ring.c. Commenting this out seems to work fine.
5. I also hit the BUG_ON on line 722 of xhci-ring.c since on MIPS a
pointer is not a DMA address and the fact that we use 64-bit addresses
where pointers are 32-bits.
I ran into similar issues with EHCI where again we have to map pointers
to physical addresses and use our own wrappers for register accesses.
At some point I would love to merge our stuff back into the mainline
U-Boot but it's going to be a huge job given that we probably have
almost 250K lines of code involved for our MIPS SOCs.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] XHCI Issues
2014-01-14 2:20 [U-Boot] XHCI Issues Aaron Williams
@ 2014-01-14 4:28 ` Aaron Williams
2014-01-15 7:13 ` Aaron Williams
0 siblings, 1 reply; 3+ messages in thread
From: Aaron Williams @ 2014-01-14 4:28 UTC (permalink / raw)
To: u-boot
On 01/13/2014 06:20 PM, Aaron Williams wrote:
> Hi all,
>
> I am bringing up XHCI support for our SOC and have run into several
> issues with U-Boot's XHCI code.
>
> 1. I need to use a wrapper I call xhci_readl/xhci_writel since all of
> our I/O is to 64-bit addresses rather than readl/writel which work for
> PCIe. While xhci_readl/xhci_writel is used in most places there are a
> few places this is missing.
>
> 2. A memory address used by a pointer is not a DMA address on MIPS. On
> MIPS a wrapper is needed for all read/write operations to descriptors
> to map the addresses. Generally U-Boot runs in KSEG0 where a pointer
> always has bit 31 set. In our case we run it in virtual memory with
> U-Boot loaded at the top of memory (which might be as high as
> 64GB+256MB).
>
> 3. xhci_alloc_virt_device is missing a conversion from big endian to
> little endian on line 401 of xhci-mem.c.
>
> 4. I keep getting hit with
>
> BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
> != COMP_STOP)));
> on line 491 in xhci-ring.c. Commenting this out seems to work fine.
>
> 5. I also hit the BUG_ON on line 722 of xhci-ring.c since on MIPS a
> pointer is not a DMA address and the fact that we use 64-bit addresses
> where pointers are 32-bits.
>
> I ran into similar issues with EHCI where again we have to map
> pointers to physical addresses and use our own wrappers for register
> accesses.
>
> At some point I would love to merge our stuff back into the mainline
> U-Boot but it's going to be a huge job given that we probably have
> almost 250K lines of code involved for our MIPS SOCs.
>
> -Aaron
>
I have a follow-up:
I am seeing error messages when hub ports are reset.
In the output below I have a USB 3 thumb drive plugged into USB0 and a
USB 2 thumb drive plugged into USB1. Each USB device has "2" ports,
where port 0 is treated as a USB 3 port and port 1 is treated as a USB
1/2 port. I think the "cannot reset port X!?" message is invalid since
otherwise everything appears to be working.
I am also seeing rather slow transfers of around 1.9MiB/sec. Is this
normal for XHCI? This is for both USB 2 and a high-speed USB 3 thumb
drive when loading a 40MiB Linux kernel image.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] XHCI Issues
2014-01-14 4:28 ` Aaron Williams
@ 2014-01-15 7:13 ` Aaron Williams
0 siblings, 0 replies; 3+ messages in thread
From: Aaron Williams @ 2014-01-15 7:13 UTC (permalink / raw)
To: u-boot
More info
On 01/13/2014 08:28 PM, Aaron Williams wrote:
> On 01/13/2014 06:20 PM, Aaron Williams wrote:
>> Hi all,
>>
>> I am bringing up XHCI support for our SOC and have run into several
>> issues with U-Boot's XHCI code.
>>
>> 1. I need to use a wrapper I call xhci_readl/xhci_writel since all of
>> our I/O is to 64-bit addresses rather than readl/writel which work
>> for PCIe. While xhci_readl/xhci_writel is used in most places there
>> are a few places this is missing.
>>
>> 2. A memory address used by a pointer is not a DMA address on MIPS.
>> On MIPS a wrapper is needed for all read/write operations to
>> descriptors to map the addresses. Generally U-Boot runs in KSEG0
>> where a pointer always has bit 31 set. In our case we run it in
>> virtual memory with U-Boot loaded at the top of memory (which might
>> be as high as 64GB+256MB).
>>
>> 3. xhci_alloc_virt_device is missing a conversion from big endian to
>> little endian on line 401 of xhci-mem.c.
>>
>> 4. I keep getting hit with
>>
>> BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
>> != COMP_STOP)));
>> on line 491 in xhci-ring.c. Commenting this out seems to work fine.
>>
>> 5. I also hit the BUG_ON on line 722 of xhci-ring.c since on MIPS a
>> pointer is not a DMA address and the fact that we use 64-bit
>> addresses where pointers are 32-bits.
>>
>> I ran into similar issues with EHCI where again we have to map
>> pointers to physical addresses and use our own wrappers for register
>> accesses.
>>
>> At some point I would love to merge our stuff back into the mainline
>> U-Boot but it's going to be a huge job given that we probably have
>> almost 250K lines of code involved for our MIPS SOCs.
>>
>> -Aaron
>>
> I have a follow-up:
>
> I am seeing error messages when hub ports are reset.
>
> In the output below I have a USB 3 thumb drive plugged into USB0 and a
> USB 2 thumb drive plugged into USB1. Each USB device has "2" ports,
> where port 0 is treated as a USB 3 port and port 1 is treated as a USB
> 1/2 port. I think the "cannot reset port X!?" message is invalid since
> otherwise everything appears to be working.
>
> I am also seeing rather slow transfers of around 1.9MiB/sec. Is this
> normal for XHCI? This is for both USB 2 and a high-speed USB 3 thumb
> drive when loading a 40MiB Linux kernel image.
>
> -Aaron
>
I have made some progress on the performance issue. The poor performance
is due to the fact that usb_storage.c limits a transfer to 20 blocks
except for EHCI where it limits it to 65535 blocks (see USB_MAX_XFER_BLK
in usb_storage.c).
For XHCI if I set it to 65535 blocks I get failures where I se
Unexpected XHCI event TRB. The type received is 33 but it expects 32.
When I lowered this value to 4096 everything worked fine for a
high-speed USB 3 device where I was getting over 90MiB/sec but it would
fail with a USB 2 flash drive. Lowering this number to 1024 seems to
work for both. I am guessing that something is timing out or something
when the number of blocks is large.
Note that we have no issues with our XHCI implementation in Linux.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-01-15 7:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-14 2:20 [U-Boot] XHCI Issues Aaron Williams
2014-01-14 4:28 ` Aaron Williams
2014-01-15 7:13 ` Aaron Williams
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.