SmartMedia FAT

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 : [email protected]
__________________________

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

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.

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.

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

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

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

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

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

-Jasmine.

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.

__________________________

Simon Haynes - Baydel
Phone : 44 (0) 1372 378811
Email : [email protected]
__________________________

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

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

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.

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

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

dwmw2