[coreboot] CS5536 OHCI not working

Patrick Georgi patrick at georgi-clan.de
Fri Sep 3 18:23:05 CEST 2010


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




More information about the coreboot mailing list