Bad block are important. But a simple linear log structure should be
sufficient. When reading/writing if the BBT says the block is good,
use it, if it is bad, skip it.
Properly NAND-aware filesystems take both kinds of bad blocks in their
stride; there's no point in adding the complexity if such a mapping if
you're using such a filesystem.
Even with something simpler, factory-bad blocks are straightforward: as you
say, one can simply linear-map them into oblivion in the driver at the cost
of extra time complexity *on every NAND operation*. (I add the emphasis
because I expect the overhead will add up fast if the NAND is heavily used.)
Worn-bad blocks are harder; you can't ever add one to the mapping, because
you'd have changed the in-flash address of everything above it.
I've been thinking about this sort of question in the context of a simple
layer to make NAND look like NOR for RedBoot, and have had an interesting
idea which I'm going to propose on this list when I've written it up.
The rootfs is a more interesting issue. Linux is very unlikely to boot
into a useful system without its rootfs. I see two options here. You
could tftp boot using a initramfs loaded to RAM to boot into linux
with a minimal system to perform a rootfs on NAND installation. Or
redboot has to somehow put the rootfs into the NAND partition.
You could also embed your entire rootfs into the kernel image as a cramfs.
This leads to three things:
1) Full read/write support for the FS in Redboot. For NOR we normally
have only read support.
Do you mean jffs2?
At the moment my YAFFS layer is fully read-write, but I could add a
read-only switch if this was thought to be useful?
2) mkfs functionality.
I don't know about other filesystems, but YAFFS always scans the NAND on
mount, and automatically does the Right Thing when asked to mount a
fully-erased array. (My RedBoot patch already includes logic to erase a nand
partition.)