I haven't implemented anything for the onboard TS72xx flash support because the best course of action isn't yet perfectly clear (to me anyway). I know what I'd like to see avoided in an implementation, but don't yet have a good plan of action to offer that would avoid all the chaos thats currently in Linux in the form of "MTD" drivers and special filesystems unique to each type of flash chip (JFFS2, YAFFS, YAFFS2, FTL/EXT2, NFTL/EXT2, etc). There are certain things unique about using direct mapped NAND/NOR flash (as opposed to something like CF, or USB flash which has an onboard controller), but a completely new filesystem (and one also for each type and variant of chip) seems a bit overkill. Some ideas:
* Come up with some sort of "unreliable/quirky block device" layer that can be used to implement the same sort of internal logic already present in devices like CompactFlash and hard drives such that a regular FFS filesystem could be placed on it. Devices (512B NAND, NOR, 2KB NAND) simply register some generic block device access functions and their quirks with this layer, and then a regular FFS filesystem could be placed on the "de-quirked" block device. The de-quirking driver has all the intelligence of filesystem agnostic wear-leveling, ECC generation/checking, and bad block management (by reserving a driver-defined percentage of blocks)
* Perhaps 1) extend ffs's block allocation policy to be random within free space, (with preference to a sector already erased or in an area already marked for erase/rewrite) 2) force block rewrites to go through a block reallocation instead of using the same block, 3) rate-limit/aggressively buffer FS metadata (inode, block bitmap, etc) writes. This would still have issue w/NAND for bad block management, and having to erase/rewrite an entire erase block at a time would expose ourselves to potential major data-lossage on crashes. The more I think about this one, the more it seems it won't work.
* LFS would be a good place to start, since it naturally wear levels, though there are certain "near-full" runaway conditions that are quite hard to accomodate the possibility for unless you (for instance) reserve 50% of the disk. They are statistically unlikely to appear in most real workloads, though still quite possible, especially if you run the disk close to full. I understand the Linux logging flash FS's also have issue with RAM usage with larger chips.
* Maybe do something by using something like fss with mfs and periodically writing out/commiting changes to the real FFS. (Still have bad block managment problems) By rate-limiting sector erase/rewrites you can acheive results similar to wear leveling for a given target flash minimum lifetime.
* Maybe relegate the whole thing to userland and use some of the Linux GPL'ed filesystems and an NFS loopback mount. (prohibits use as root filesystem)
* Just use a ramdisk image and mfs union mount and have an easy way to say "save me" and thereafter write out a new ramdisk to the original flash location the kernel+ramdisk reside.
//Jesse Off
Why is there on support in NetBSD for TS-72xx on-board flash and how can I help? I.e., is it a problem of file-system (NetBSD has no flash oriented file-system) or just a lack of a flash driver? Thanks Francis.Dupont%enst-bretagne.fr@localhost