> Since I'm new to Linux-USB, where should I send the source to (~20K) ?
Can you tar and bzip/gzip it? Then I think it could go on this list.
> Size is ment to be bytes --> O.K. to write multiple pages in one shot.
> I'll add comments.
Ok, that's better then. But then I probably wouldn't call it raw_sector,
but just write_raw_func, or maybe write_physical_func. That way it's
clear the function isn't limited to writing a single sector. However,
the SDDR requires writing whole sectors at a time. So would it make
sense to change the size to sectors rather than bytes?
Then maybe the flip side of physical is write_logical_func.
In addition, all the SCSI commands are sector-based (read and write
whole sectors), so maybe all the functions can have size be sectors and
not bytes.
> Doesn't the SDDR have a copy command ?
Nope!
>> I'm not sure about these. Although the SDDR09 SmartMedia reader has an
>> independent erase function, its write function does a simultaneous
>> erase. So I would say that the write function does what these do
>> anyway. I don't know about the other media.
>
> How does that work ??
First you read the whole block, then modify what you want. When you
write it back, of course you will write it to a different physical block
(although I'm not sure why "of course", but that's what the Windows
driver and the SSFDC SMIL code does). In the command, you specify the
new block to write the data to, and also the old block to erase. If you
specify 0 as the old block, no erasure happens -- you use that when you
want to allocate a new block. If you specify the same block, the block
is first erased and then written to.
>
> If I've got it all right, for writing a single page, we need to:
>
> * Find a free "block"
> * Copy all other pages+unchanged redundancy to that block
> * Write out new page+redundancy to the new block
> * Erase the old block
That will work, yes. But it is inefficient when using the SDDR command
set. The copy step would require reading the whole block and writing it
back (two commands). The write and erase steps are a single command, for
a total of three commands.
For the SDDR, you would implement this as:
1. Find a free block
2. Read the old block (data+redundancy)
3. Alter the block in memory
4. Write the block (data+redudancy) in the newly allocated area
5. Erase the old block.
Step 2 is one command, and steps 4 and 5 combined are one command, for a
total of two commands.
I would guess that for the other media, if they implement separate copy,
write, and erase commands, then your original algorithm will work fine
(3 commands). However, using the SDDR algorithm for those media, you
will still get three commands, but more data flies around because you're
not letting the hardware do the copy -- you're reading and writing whole
blocks.
Perhaps these could be combined:
1. Find free block
2. If no copy command then:
2a. Read old block
2b. Alter block in memory
else:
2c. Copy old block
3. If no write+erase command then:
3a. Write sector(s)
3b. Erase old block
else:
3c. Write+erase entire block
This way, we become efficient for those devices which support funky
commands.
> BTW: what happend if we loose contact to the device between write &
> erase ?
> Then we have two PBA mapped to one LBA, right ?
I guess that's why the write+erase is atomic in the SDDR. If you do the
erase first, then lose contact, you'd have a corrupted card (missing
LBA). If you do the write first, then lose contact, you'd also have a
corrupted card (duplicate LBA).
In either case you'll end up with a corrupted card, so I don't think
there is anything to do -- there's no way to recover.
Same thing in devices which support copy. If you copy a block and then
lose contact, the card gets corrupted because of a duplicate LBA. At
least that could be fixed by not using the copy command -- read the
entire block and alter it in memory. Then all you have to do is worry
about losing contact between write and erase (in whatever order you do
it in).
> As above: read_raw should do just that.
Yes, but SDDR supports read data only, read redundancy only, and read
data+redundancy. Read data only is used during ordinary reads. Read
redundancy is used during LBA->PBA mapping, and read data+redundancy is
used during writes.
We will need to support all three read modes.
--Rob
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
