small update

Chris Niekel chris at niekel.net
Mon Dec 31 20:56:51 CET 2001


On Mon, Dec 31, 2001 at 07:44:16PM +0100, Herald van der Breggen wrote:
> Next time I will not include the linux-directory, it should not be there 
> I think.

If I remove it, everything compiles fine. 

> 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?

Yes, it's free for open source projects.

> >
> >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!

Thanks. :)

> >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.

Since the device is unplugged, there is no SCSI interface, so the
TEST_UNIT_READY wouldn't be called. So, the device at least responds to 
the USB hotswappable stuff. But, there is the slightest chance that
someone unplugs it at the moment the TEST_UNIT_READY is about to come
in. So if you determine that the device isn't responding anymore, you
better return an error. 


> Anyway there is a command to check whether a card is there (see page 41 
> of the SCM documentation).

Euhm, where can I find that document? I found only some less than
insightful one page document on how to use the device (plug it in and
point explorer at it). (tib4210.pdf).

> 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?"

Could you point me at some of the lines where that happens? The format
of the files puzzles me. If these addresses are blocks then it could be
that the FAT is there (where information about blocks in use and such
things is written). Did you copy a file with all zeroes by the way?
I see a lot of zeroes being sent in that file.

> 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 one-eyed-alien.net). I have a lot of 
> to-me-almost-impossible questions that are easy ones for Matthew (I 
> guess/hope).

That would be a good idea.

greetings,
    Chris

-- 
Geek code version 3.1:
GCS d- s++: a- C++$ ULSI++ P+(---) L+++>++++ E--- W++ N++ o K? w--- O M- 
V?>-- PS+ PE-() Y PGP+ t+>+++ 5? X- !R tv+ b DI++ D+ G>++ e+++ h--- r+++ y++++



More information about the Usbat2 mailing list