- Status Closed
- Percent Complete
- Task Type Patches
- Category Drivers
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes 5
- Private
FS#7962 - USB device code for sansa
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.
Closed by zagor
2007-11-23 21:48
Reason for closing: Accepted
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
2007-11-23 21:48
Reason for closing: Accepted
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Committed to SVN
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Thanks!
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):
http://lxr.linux.no/source/drivers/usb/gadget/fsl_usb2_udc.c#L448 http://lxr.linux.no/source/drivers/usb/gadget/fsl_usb2_udc.c#L318
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.
No luck. Endpoints don't have to be uniquely numbered. And even when they are, no interrupts fire.
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.
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 http://bjorn.haxx.se/usbmon.txt.
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.
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?
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.
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!
Synced to svn and updated to also work on e200.
Make it work on H10 too.
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
No, I mean make it work as well as the c200 with is not usable and ready for testing.