small update

Herald van der Breggen herald at
Mon Dec 31 19:44:16 CET 2001

On 12/31/2001 05:53 PM, Chris Niekel wrote:

>On Sun, Dec 30, 2001 at 10:23:49PM +0100, Herald van der Breggen wrote:
>>Not much progress, but made en newer version anyway:
>In version 001 (and again in 002) I removed the first line of
>It says #include "linux/rhconfig.h", which apparently my linux doesn't
Next time I will not include the linux-directory, it should not be there 
I think.

The directory was part of what I did: a quick work around to avoid other 
drivers to be compiled in (sometimes they had compile errors), so that I 
could focus on the usbat2 driver. I could mention this work around in 
the README instead...

>Furthermore, I think it would be a good idea to use CVS. Maybe you (or
>anyone else) could start a sourceforge project? 
Actually, there *is* a CVS for usb-storage (not especially for usbat2). 
I don't know how Matthew thinks about making it available for us. It 
seems the best solution to me, because in that case we don't have to 
merge versions together all the time. I wil ask it soon.
Otherwise a sourceforge project sounds ok to me, never done it so far... 
Is it free?

>>In this one extended debug info is printed into the logfile and the 
>>INQUIRE request is handled by de standard fill_inquiry_response of 
>>usb.c. So now this scsi-like message wil appear in the logfile:
>>Dec 30 21:04:23 chita kernel: Command INQUIRY (6 bytes)
>>Dec 30 21:04:23 chita kernel: 12 00 00 00 ff 00 f6 cf b4 0e f6 cf
>>Dec 30 21:04:23 chita kernel: usbat2_ata_command is called
>>Dec 30 21:04:23 chita kernel: usbat2_ata_command:  INQUIRY.  Returning 
>>bogus responsescsi cmd done, result=0x0
>The information isn't completely bogus. I changed it and the output made
>a lot less sense :). 
You are complete right (I think). I took this piece of code from 
datafab.c and had the same reaction when I saw it the first time. I just 
forgot to change the message.

>Maybe you should mention in the code what is bogus
>and what is correct information. 
I guess it not bogus.

>But it's good to have an example of how
>the information is reported back to the SCSI layer.
>>Also other requests appear:
>>Dec 30 21:04:24 chita kernel: Command TEST_UNIT_READY (6 bytes)
>>Dec 30 21:04:24 chita kernel: Command READ_CAPACITY (10 bytes)
>>Dec 30 21:04:24 chita kernel: Command MODE_SENSE (6 bytes)
>>I Don't now what to do with these, so far...
>I'm not sure but the first sounds like it wants to see whether the unit
>is ready (we have to find out: ready for what?"). 
Makes sense... never thought of this... Hee, you're good!

>The SCSI-Programming
>howto is helpfull here, it gives an example to handle the SCSI part, and
>explains that TEST_UNIT_READY is to check whether media is
>loaded into our device. This is very useful to have implemented.
If a TEST_UNIT_READY request is done, we can be shure that the usbat 
device is connected and alive, or am I wrong? Then there is the 
possiblity that there is not a compactflash card in the device. What 
should we report in this case... the device is ready but there is no 
media, no filesystem.... I don't know.
Anyway there is a command to check whether a card is there (see page 41 
of the SCM documentation).

>>Now, the most difficult part (for me) starts: trying to understand the 
>>sniffed data, what ATA commands do, and how to fit this in the driver....
>I have the feeling ATA is not interesting for us. Usb-storage implements
>a SCSI-like device. The isb200 talks ATA-like on the USB-bus I think.
I am afraid we have to do that too...

>But if the sniffed data is very ATA-like, then maybe that's an easier
>way then reverse engineering from the sniffed data. I still have no
I guess so. I have studied some time on the 
usb-sniff-003-dosbox-copy-to.LOG (logging of "copy c:\q.txt e:\" in a 
dosbox, where e: is the usbat2 device) and I see a lot of ATA commands 
and still find it hard to understand. I see that ATA read and write 
operations use addresses 14, 15 and 16, and I keep asking myself "what 
are those addresses?" why should it read/write to that?"

>To implement the TEST_UNIT_READY ('is there a card?') could be an
>interesting next step. You'll have to talk really to the device, and
>there is an explanation in the SCSI-Programming-Howto that might tell
>how to report back what is revealed. 
Good idea. At the same time I try to focus on the ata side (if my wife 
and three children permit ;-))

>When wife and son permit, I'll try
>whether I can report back that nothing is present. Then a mount-attempt
>should cleanly fail, I presume.
Probably, yes. I would like to see that :-)

Maybe we should collect some (fundamental) questions and ask them to 
Matthew, or at lost post them on the usb-storage mailinglist 
(usb-storage at I have a lot of 
to-me-almost-impossible questions that are easy ones for Matthew (I 


More information about the Usbat2 mailing list