FS#7962 - USB device code for sansa

Attached to Project: Rockbox
Opened by Björn Stenberg (zagor) - Monday, 15 October 2007, 11:49 GMT
Last edited by Björn Stenberg (zagor) - Friday, 23 November 2007, 21:48 GMT
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No


Current state of my USB implementation. Configuration/enumeration/setup works, but the bulk input (OUT) endpoint doesn't trigger any interrupt so the usb-storage commands are not received.
This task depends upon

Closed by  Björn Stenberg (zagor)
Friday, 23 November 2007, 21:48 GMT
Reason for closing:  Accepted
Additional comments about closing:  Committed to SVN
Comment by Bertrik Sikken (bertrik) - Monday, 15 October 2007, 18:24 GMT

Something that looks suspicious is the endpoint number assignment, you use endpoint number 1 for both the bulk in and the bulk out endpoints, with the two endpoints only distinguished by the direction bit. The USB2.0 spec is a bit vague on whether this is supported, but I can't remember ever seeing something like this being used in other USB devices. Better would be endpoint addresses 0x01 for OUT and 0x82 for IN.

Also nothing seem to happen yet on reception of a USB_REQ_SET_CONFIGURATION request. I think this is a good place to enable/configure the endpoints.
Example from Linux driver (fsl_ep_enable / dr_ep_setup):
Comment by Björn Stenberg (zagor) - Tuesday, 16 October 2007, 07:44 GMT
Ahhh, the endpoint numbering looks to be a basic USB misunderstanding on my part. This is most likely the cause of my problems. Thanks!

SET_CONFIGURATION is not looked at (only ACKed immediately) because the device only has one configuration, which is already active. If we add more configurations, SET_CONFIGURATION will do more.
Comment by Björn Stenberg (zagor) - Tuesday, 16 October 2007, 09:13 GMT
No luck. Endpoints don't have to be uniquely numbered. And even when they are, no interrupts fire. :-(
Comment by Björn Stenberg (zagor) - Tuesday, 16 October 2007, 11:37 GMT
Problem solved, and your set_configuration point was what turned me on the right track. The USB controller requires endpoints to be configured _after_ the PORT_CHANGED interrupt.
Comment by Björn Stenberg (zagor) - Wednesday, 17 October 2007, 23:42 GMT
Current state of the code, if anyone wants a look. Beware: The endpoint number fix in usb-drv is quick&dirty, not the final state.

The problem I'm fighting currently is that my CSWs (command status wrappers, sort of ACKs for usb-storage) don't come out on the bus the way I send them to the driver. The first CSW is all zeroes, and subsequent ones have a too old cbw tag! See

It's almost as if old CSWs are being buffered in the driver and sent later. Yet the driver only uses a single transmit buffer, which inbetween the failed CSWs is also used for sucessfully sending the data-in portions (the INQUIRY struct). So that's a bit of a mystery at this point.
Comment by Christian Gmeiner (austriancoder) - Sunday, 28 October 2007, 14:07 GMT
Looks quite nice... so it seems you want to remove my code and use yours. Or are you willing, with the help of me, to merge your improvements into the current usb stack?
Comment by Björn Stenberg (zagor) - Monday, 29 October 2007, 09:34 GMT
The reason I started writing this code is that I think the linux stack is too generic and therefore too complex for Rockbox. Rockbox is a very static platform where things don't change in runtime. Therefore we don't need all the runtime dynamic flexibility "framework" features that the linux stack offers.

The purpose of my effort is to try and implement USB with simple straight-forward code that is easy to understand and easy to debug.
Comment by Björn Stenberg (zagor) - Sunday, 04 November 2007, 22:09 GMT
Current state of the code. Usb storage device registration works and linux creates a new scsi device, but when host requests first READ_10 device fails. This frequently causes kernel oops in linux, so beware!
Comment by Barry Wardell (barrywardell) - Wednesday, 14 November 2007, 16:42 GMT
Synced to svn and updated to also work on e200.
Comment by Barry Wardell (barrywardell) - Wednesday, 14 November 2007, 17:36 GMT
Make it work on H10 too.
Comment by Sander Sweers (infirit) - Wednesday, 14 November 2007, 17:51 GMT
Does "make it work" mean it is usable and ready for testing? If so I'll try it out and report any problems that might appear. Thanks
Comment by Barry Wardell (barrywardell) - Wednesday, 14 November 2007, 18:27 GMT
No, I mean make it work as well as the c200 with is not usable and ready for testing.