USB gadgetfs not reading multiples of wMaxpacketsize data

[Akar]

I am using imx35 with ltib linux 2.6.31.

I am using the OTG in the device mode and configured the device using gadgetfs, connected to linux ubuntu host

USB device configurations:

wMaxpacketsize is 64 bytes.

I am issuing the gadgetfs read with buffer length of 1024 and writing 511 bytes from ubuntu, gadgetfs unblocks immediately and read returns 511 bytes.

but when i send 512 bytes of data from ubuntu gadgetfs does not unblock or read the the data sent from host until another 512 bytes are sent from host that is till read buffer (1024) gets full.

I tried the sending 64 bytes of data from ubuntu, and gadgetfs does not read until 1024 buffer is full that is i have to send 64 bytes of data 16 times.

but when i send 63  bytes of data, gadgetfs reads 63 bytes immediately. And when i send 65  bytes of data, gadgetfs reads 65 bytes immediately.

Please help us understand why this is happening.

Thanks in advance for help.

[daiane_angolini]

In a internal research I was able to find in a USB documentation/FAQ the following text regarding this issue. I hope it helps:

This is actually quite normal behavior.

It is all described in the USB specification and the EHCI specification how this works.

First of all, MaxPacketSize should be 512 bytes for high-speed bulk. 64 bytes is for full speed, but that is not the actual problem.

The reason is that in US a transfer ends when either a short packet is received (= packet is less than MaxPacketSize), or when all data is transferred.

So in this case, with MaxPacketSize = 64, sending 512 bytes means 8 packets of 64 bytes. All packets are MaxPacketSize so the transfer is not complete since there are 1024 bytes in total to be sent. (512 more before the transfer is complete).

When 511 bytes are sent, it means 7 packets of 64 bytes plus 1 packet of 63 bytes => short packet. This indicates the end of the transfer.

i.e. the receiver will not wait for the 513 remain bytes that were originally scheduled.

[CarlosCasillas]

Hi Amol,

You could try the workaround for ENGcm11601, explained on document IMX35CE.

Hope this will be useful for you.
Best regards!
/Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Akar]

Hi Carlos,

Thanks for your response.

What ever suggested in Errata is already taken care that is SBUSCFG (offset 0x0090) is set to Zero.

Still we face the same problem as mentioned above.

This is the blocking issue for us. It's because of this problem we have huge quantity of boards are held in production also stopped procuring the I.mx35 SOC so that we can start after we get this issue resolved. So please make this as high priority and help us solving the issue.

Regards

Amol

[fabio_estevam]

Hi Amol,

Can you try to reproduce this problem on 4.0.5?

You would need to create a dts file for your board.

There is a mx35 board from Eukrea that supports USB OTG and USB host that you can refer to:

arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts

Regards,

Fabio Estevam

[Ragan_Dunham]

Amol,

This is not a problem we have encountered before, and the LTIB 2.6 kernel is no longer actively supported or maintained. My suggestion would be to see if the problem occurs in a more modern kernel, or to contact your sales representative for professional support options.

Best regards,

Ragan