Am 03.09.2010 17:13, schrieb Jens Rottmann:
is OHCI / USB storage support supposed to be working or is this still very early experimental stuff?
It's still rather fresh code (from Google Summer of Code 2010), and only tested on a single southbridge so far.
If it's known to work only on few supported chipsets yet, then never mind, just ignore me, we don't actually need this, I just fancied giving it a try.
It's supposed to work everywhere, but given the experiences I had with the UHCI code, this is probably unrealistic ;-)
But if it's supposed to be mostly working now, you might be interested to hear that this is all I'm getting:
Thank you, this is indeed interesting to me!
doing control transfer with 0. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8c0, condition: f
These debug messages can be disabled by commenting out USB_DEBUG in payloads/libpayload/drivers/usb/ohci.c
it uses SCSI transparent command set it uses Bulk-Only Transport protocol using endpoint 81 as in, 2 as out doing control transfer with 1. first_td at f6bf8a0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8d0, condition: f has 1 luns
Up to here it indicates that things are going rather well - both control and bulk transfers (the two transfer types important for mass storage devices) work.
Waiting for device to become ready... bulk: 1f bytes from 233035, finalize: 0, maxpacketsize: 40 doing bulk transfer with 1(2). first_td at f6bf8a0, last f6bf8b0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f bulk: d bytes from 233028, finalize: 1, maxpacketsize: 40 doing bulk transfer with 1(1). first_td at f6bf8a0, last f6bf8b0 intst: 44; ctrl: b4; cmdst: 0; head: f6bf8a0 -> f6bf8b0, tail: f6bf8b0, condition: f [ ... continues infinitely ... ]
I added a counter forcing the loop @ libpayload/drivers/usb/ohci.c:206 to break after 50 repetitions, but this didn't get me anywhere: in the end USB storage would report a complete bogus nr of sectors for my thumb drive.
It's possible that this is more of a problem of your thumb drive than of the USB stack. Thumb drives often do weird stuff at that point, which is why there's a timeout.
If you have some other USB storage devices and some time, I'd like to see some logs (maybe by personal email, not to the list) with these. Should some of them really work, we can still try to figure out what to do about the thumb drive you tried here.
I'd like to be more helpful, but I don't have a clue what this loop is for, or what wait_for_ed() does or who this Ed person is anyway. ;-)
It's the endpoint descriptor ;-) Basically, the function is a loop waiting for the scheduled operation to finish.
Thanks, Patrick