SmartMedia FAT

SmartMedia FAT

[simon]

I would like to be able to access FAT partitions on a SMC via Linux. Curently the 
hardare loads its' configuration and boots the hardware from files on a FAT partition. 
The hardware itself has no hardware flash translation layer. The SMC has been 
created on a USB device which contains a flash translation layer conforming to the 
SFFDC standard. After this a JFFS2 root is mounted. It would be nice if I could 
change the hardware and boot files from Linux but I have been unable to find any 
reliable way of accessing the FAT filesystem.

As far as I understand, from the information I have read, I would need to create  a 
block driver which contained a SSFDC compatible translation layer ? In the nand 
FAQ it mentions SmartMedia FAT. I have been unable to find how this is 
implemented. Has anyone implemented this yet ?

I would like to know if my assumptions are correct. If so I guess there are many ways 
this could be achieved. 

1. Wrirte my on block driver ?
2. Bolt on some bits to mtdblock ?
3. As I don't do this all the time write a user app to update via /dev/mtd

All comments welcome.


Many Thanks

Simon.__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: SmartMedia FAT

[Charles Manning]

On Tuesday 28 October 2003 04:45,  wrote:
> I would like to be able to access FAT partitions on a SMC via Linux.
> Curently the hardare loads its' configuration and boots the hardware from
> files on a FAT partition. The hardware itself has no hardware flash
> translation layer. The SMC has been created on a USB device which contains
> a flash translation layer conforming to the SFFDC standard. After this a
> JFFS2 root is mounted. It would be nice if I could change the hardware and
> boot files from Linux but I have been unable to find any reliable way of
> accessing the FAT filesystem.

Ok, I'll first remind you that a SmardMedia card is just NAND flash and you 
can use it with a NAND file system like YAFFS or JFFS2.

I'll also warn you that running FAT on SmartMedia is far from reliable and is 
slow (relative to YAFFS and, I expect, JFFS2).

The rest of my response assumes that you have a valid reason to use FAT + 
SMartMedia (eg. need to share files with a SmartMedia-equipped device).

Iyf you are just using SMC to load images from a PC into an embedded system, 
then you're likely going to get the best result by using YAFFS or JFFS2 and 
just using a simple copy process on the host to copy a YAFFS/JFFS2 image onto 
the SmartMedia card. ie a process like:

* Generate a YAFFS image with mkyaffsimage.
* Copy the image onto the SMC with a program derived from mkyaffs.
* Stuff into your embedded system and boot YAFFS.

>
> As far as I understand, from the information I have read, I would need to
> create  a block driver which contained a SSFDC compatible translation layer
> ? In the nand FAQ it mentions SmartMedia FAT. I have been unable to find
> how this is implemented. Has anyone implemented this yet ?

As I understand it, the SMC FAT format differs slightly from regular FAT. I 
don't know of any Linux implementations.

The Samsung www has various info on the formats. The SSFDC www has some specs 
too. The yaffs_ecc.c ECC code (in the YAFFS CVS)  does SMC compliant ECC 
calcs.


> I would like to know if my assumptions are correct. If so I guess there are
> many ways this could be achieved.
>
> 1. Wrirte my on block driver ?

Currently the md block driver is just a way to get from a name in /dev to the 
internal kernel structures so that it can be used by a flash file system. It 
does not supply full block driver functionality.

A SmartMedia block driver does bad block management, ECC and logical to 
physical block mapping. 


> 2. Bolt on some bits to mtdblock ?

I guess this could be added to mtdblock, but is probably best done as a new 
block driver that uses mtdblock under the hood. Why? Because probably nobody 
really wants all this extra stuff added to mtdblock.

> 3. As I don't do this all the time write a user app to update via /dev/mtd

I guess that's a possibility, but seems like some hard work. Likely a 
YAFFS/JFFS2 path would be simpler.

Re: SmartMedia FAT

[David Woodhouse]

Some SM adapters do the translation in firmware and present themselves
to the host as a real block device. You don't have any _choice_ but to
use the SMTL on those.

You don't actually have to use _FAT_ on that though, any more than you
_have_ to use FAT on floppies or DiskOnChip just because that's how they
are shipped. You could use ext3 or something else powerfail-safe. You
still have the inefficient journalling-on-journalling effect that you
get with all such fake-block-device arrangements, but it shouldn't
actually break before you wear the flash out.

Implementing SMTL really shouldn't be that hard. The mtd_blkdevs code in
CVS handles all the horridness of the Linux block layer for you and you
only need to write readsector() and writesector() routines. There's code
in drivers/usb/storage/sddr09.c which may help, since those devices make
the host do the translation.

-- 
dwmw2

Re: SmartMedia FAT

[Charles Manning]

> Implementing SMTL really shouldn't be that hard. The mtd_blkdevs code in
> CVS handles all the horridness of the Linux block layer for you and you
> only need to write readsector() and writesector() routines. There's code
> in drivers/usb/storage/sddr09.c which may help, since those devices make
> the host do the translation.

The flip side to this is that if you can find an SDDR09  you could likely get 
YAFFS/JFFS2 working with that by bypassing the usb storage driver and 
exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung does 
make a USB device for experimenting with NAND that could be used for the same 
purpose.

I agree with David that the SMTL is simple. I have the code for a Win2K 
version which I am not allowed to release. 

-- Charles

Re: SmartMedia FAT

[David Woodhouse]

On Wed, 2003-10-29 at 12:33 +1300, Charles Manning wrote:
> The flip side to this is that if you can find an SDDR09  you could likely get 
> YAFFS/JFFS2 working with that by bypassing the usb storage driver and 
> exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung does 
> make a USB device for experimenting with NAND that could be used for the same 
> purpose.

Can't you just hang one off the parallel port and bitbang it? Should be
fairly trivial to make a driver which uses the generic NAND code and
does that.... left as an exercise for the reader with a soldering iron.

-- 
dwmw2

Re: SmartMedia FAT

[Jasmine Strong]

> [NAND]
>
> Can't you just hang one off the parallel port and bitbang it? Should be
> fairly trivial to make a driver which uses the generic NAND code and
> does that.... left as an exercise for the reader with a soldering iron.

...in fact, this is very nearly what we did on the ZL103xx NAND
driver.  Rob, are you out there?

-Jasmine.

Re: SmartMedia FAT

[simon]

Thanks too all for your help. I have started to write my own block 
driver using the FTL code as a guide. It seems fairly simple and 
should not take too long.


Thanks Again 

Simon. 

On 27 Oct 2003 at 15:45, simon@baydel.com wrote:

> I would like to be able to access FAT partitions on a SMC via Linux.
> Curently the hardare loads its' configuration and boots the hardware
> from files on a FAT partition. The hardware itself has no hardware
> flash translation layer. The SMC has been created on a USB device
> which contains a flash translation layer conforming to the SFFDC
> standard. After this a JFFS2 root is mounted. It would be nice if I
> could change the hardware and boot files from Linux but I have been
> unable to find any reliable way of accessing the FAT filesystem.
> 
> As far as I understand, from the information I have read, I would need
> to create  a block driver which contained a SSFDC compatible
> translation layer ? In the nand FAQ it mentions SmartMedia FAT. I have
> been unable to find how this is implemented. Has anyone implemented
> this yet ?
> 
> I would like to know if my assumptions are correct. If so I guess
> there are many ways this could be achieved. 
> 
> 1. Wrirte my on block driver ?
> 2. Bolt on some bits to mtdblock ?
> 3. As I don't do this all the time write a user app to update via
> /dev/mtd
> 
> All comments welcome.
> 
> 
> Many Thanks
> 
> Simon.__________________________
> 
> Simon Haynes - Baydel 
> Phone : 44 (0) 1372 378811
> Email : simon@baydel.com
> __________________________
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: SmartMedia FAT

[David Woodhouse]

On Wed, 2003-10-29 at 10:21 +0000, simon@baydel.com wrote:
> Thanks too all for your help. I have started to write my own block 
> driver using the FTL code as a guide. It seems fairly simple and 
> should not take too long.

Send me a SSH key and I'll give you an account so you can put it in CVS.
Commit early and often and I'll try to heckle helpfully... :)

-- 
dwmw2

Re: SmartMedia FAT

[Charles Manning]

On Wednesday 29 October 2003 13:48, David Woodhouse wrote:
> On Wed, 2003-10-29 at 12:33 +1300, Charles Manning wrote:
> > The flip side to this is that if you can find an SDDR09  you could likely
> > get YAFFS/JFFS2 working with that by bypassing the usb storage driver and
> > exposing it as NAND to mtd. However, SDDR09's are pretty rare. Samsung
> > does make a USB device for experimenting with NAND that could be used for
> > the same purpose.
>
> Can't you just hang one off the parallel port and bitbang it? Should be
> fairly trivial to make a driver which uses the generic NAND code and
> does that.... left as an exercise for the reader with a soldering iron.

Last time I tried reading with a soldering iron I burnt the page. 

Samsung had a schematic for their parallel port thingy on their www. This is 
no longer there. If you want, email me.

Samsung's  USB NAND thingy is:
http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/NANDUSB_Introduction.pdf

-- CHarles

Re: SmartMedia FAT

[Simon Haynes]

I have been looking at the OOB data format for SSFDC and it seems I will have 
to create and process my own OOB data as I can not see how the NAND/MTD layer 
will work with this. 

When we started this project there seemed to be a fixed NAND OOB format. Now 
the NAND OOB format is selectable. I have noticed in a couple of kernel 
distributions that the JFFS2 code does not seem to be aware of this and just 
calls pain mtd->read. I guess this would mean no ecc for JFFS2 on NAND unless 
it was done automatically by the hardware. This was the case for latest 
stable kernel, 2.4.22 downloaded from kernel.org today. 

Is this really the case ?

Cheers

Simon.


On Wednesday 29 Oct 2003 10:55 am, David Woodhouse wrote:
> On Wed, 2003-10-29 at 10:21 +0000, simon@baydel.com wrote:
> > Thanks too all for your help. I have started to write my own block
> > driver using the FTL code as a guide. It seems fairly simple and
> > should not take too long.
>
> Send me a SSH key and I'll give you an account so you can put it in CVS.
> Commit early and often and I'll try to heckle helpfully... :)

Re: SmartMedia FAT

[David Woodhouse]

On Thu, 2003-10-30 at 14:26 +0000, Simon Haynes wrote:
> I have been looking at the OOB data format for SSFDC and it seems I will have 
> to create and process my own OOB data as I can not see how the NAND/MTD layer 
> will work with this. 

Yes, that's expected. NFTL and JFFS2 do this too.

> When we started this project there seemed to be a fixed NAND OOB format. Now 
> the NAND OOB format is selectable. I have noticed in a couple of kernel 
> distributions that the JFFS2 code does not seem to be aware of this and just 
> calls pain mtd->read. I guess this would mean no ecc for JFFS2 on NAND unless 
> it was done automatically by the hardware. This was the case for latest 
> stable kernel, 2.4.22 downloaded from kernel.org today. 
> 
> Is this really the case ?

The JFFS2 in the 2.4 kernel doesn't support NAND. The code in CVS does.


-- 
dwmw2