[U-Boot] [EXT] Re: XHCI behavior

[Aaron Williams]

Yes, I'm looking at the top of trunk xhci.h from the master branch. There is 
no definition for bit 8 of the HCCPARAMS1 register. Also, in looking at the 
latest kernel xhci.c I don't see any reference to the PAE bit.

With USB NIC cards if the buffer spans a 64K boundary and the data fits in the 
first half, I get two event responses. The first is a short packet, but the 
length is based only on the first TRB and a second success event is also 
received. We have also seen stability problems in the Linux kernel which we 
now suspect is due to this.

-Aaron

On Friday, September 6, 2019 8:59:00 PM PDT Bin Meng wrote:
> External Email
> 
> ----------------------------------------------------------------------
> Hi Aaron,
> 
> On Sat, Sep 7, 2019 at 11:08 AM Aaron Williams <awilliams at marvell.com> 
wrote:
> > Hi,
> > 
> > I am seeing crashes in our XHCI implementation based on a Designware USB
> > 3.1 core. One thing I noticed is that this core sets the PAE bit in the
> > HCCparams. The result of this is that when there is a short packet and
> > there are two TDs, then when PAE is set there will be two responses with
> > the second one being success. I'm still not sure if the length field I'm
> > seeing is correct or not, but it appears that neither Linux nor U-Boot
> > can handle HCs with the PAE bit set. See the eXtendable Host Controller
> > Interface 1.1 sections 4.10.1.1 and 5.3.6.
> 
> It looks this PAE bit was introduced in spec 1.1. U-Boot xHCI driver
> was ported from an earlier version of Linux xHCI driver, and I doubt
> it could correctly handle it. But you mentioned that Linux could not
> handle HCs with PAE set. Did you try the latest kernel?
> 
> > With short packets with the PAE bit set with to TRBs I get two responses
> > when the data fits in the first TRB. The first event TRB contains a short
> > packet response with the length set to the amount of space within the
> > first TRB that is actually used. The second TRB event is a success
> > completion code, as is described in section 4.10.1.1.1.
> > 
> > Personally I find this PAE bit a major pain in the arse that causes more
> > trouble than it's worth.
> 
> Regards,
> Bin

-- 
Aaron Williams
Senior Software Engineer
Marvell Semiconductor, Inc.
(408) 943-7198	(510) 789-8988 (cell)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190906/3531855b/attachment.sig>