Sancho Dauskardt wrote:
> Now I'm doing the SSFDC stuff. Of course I could just copy sddr09 and
> fudge in the differences USB protocol stuff, but I would prefer to
> transfer all the SSFDC-things into a separate ssfdc_mgr.c which could be
> used by all SSFDC devices, regardless of the bus/device there connected
> to. An of course we're still missing write-access ?
I've been trying to work on write-access, hoping to have it done by the
end of the weekend, but I ran into a problem with writes stalling. I'll
keep trying, though.
Do the other media (MemoryStick, etc) use SSFDC format, in that there is
a data area and a redundancy or control area?
> Now:
> * does sddr09.c work with 1&2 MB Cards ?
> These cards would show up as 256bytes/sector devices to the scsi layer ?
> From all specs/docs I've seen, one should really hide this detail from
> other layers ?
The driver *should* work with those cards, although I haven't tested
them since I don't have those cards. The driver is set up to report 256
bytes/sector for those cards.
Something in the driver would definitely need to know about the number
of bytes per sector, because otherwise the driver wouldn't know how to
translate sectors to blocks and bytes.
>
> * do we really need a full two-way pba<-->lba mapping for read-only ?
> SSFDC Block 0 (not Page/Sector 0 !) can't contain any user data anyway
> (always card info there).
> for write-access we definitely need them: finding free blocks,...
For sure, lba->pba is important for read access, but not for write
access. For write access pba->lba shouldn't be necessary -- all you
would need is to know whether a pba is allocated or not. So I think we
don't need pba->lba at all.
> struct ssfdc_abstract_manager {
I'd rather see it called ssfdc_info or ssfdc_abstract_info. But that's
just me :)
>
> void *connected_via_device; // for read/write calls
>
> int vendorID,deviceID;
>
> ssfdc_geometry geo;
>
> int *lba2pba;
unsigned char *pba_alloc; // allocation bitmask
>
> // Functions to read/write/copy complete 256+8/512+16
> sectors (data+redundancy)
> //
> int (*read_raw_sector_func)(ssfdc_abstract_manager *mgr,int
> block,int page,char *data,int size);
> int (*write_raw_sector_func)(ssfdc_abstract_manager *mgr,int
> block,int page,char *data,int size);
This might be inefficient... on the SmartMedia, when you want to write
sectors, you would read the entire block (up to 32 sectors) with control
information, update the block, and write it back in a different place.
So in the driver I don't have a "write one sector" function, but rather
an entire "write data" function, since you never really need to write
just one raw sector -- you always end up writing a whole block.
I'm just worried that people using these functions might be tempted to
write one sector at a time.
Maybe we should have a write_raw_block_func instead? Also
read_raw_block_func as well as the read_raw_sector_func?
Is the size argument in bytes or in sectors?
> int (*copy_raw_sector_func)(ssfdc_abstract_manager *mgr,int
> sourceblock,int sourcepage,int destblock);
>
> // Erase a block after it's been copied somewhere else..
> //
> int (*erase_block_func)(ssfdc_abstract_manager *mgr,int block);
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.
>
> // Read data only or redundancy only.
> //
> // Multiple sectors ok, but don't cross block boundarys.
> //
> int (*read_data_func)(ssfdc_abstract_manager *mgr,int
> block,int page,char *data,int size);
> int (*read_redundancy_func)(ssfdc_abstract_manager *mgr,int
> block,int page,char *data,int size);
> };
>
> I'm not familiar with the SCM commands for writing, therefor: will this
> match the SCM Command-set ?
I think you'll want a read_data_and_redundancy_func, since the SCM write
command requires the data in data+redundancy form.
> Can we use the SMIL stuff published by Toshiba/SSFDC (see
> http://www.ssfdc.or.jp/english/smil/down.htm) ?
> I guess not.
It's written in a strange language? Also it assumes you're programming
the hardware directly, rather than going through a USB translation. I've
found reading that code useful as a base for writing my own code.
--Rob
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
