I'm Cc'ing this to the tech-kern@netbsd.org mailing list in order to hopefully 
solicit a few other expert opinions on the subject.

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