Re: NAND review

[Andrew Lunn <andrew@lunn.ch>]

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

I'm not suggesting putting this in the driver. 

I'm suggesting RedBoot commands nandfis load and nandfis create
does this.

As you said, a full NAND filesystem will handle bad blocks etc.

However, just to get an executable image, be it the Linux kernel, or
an eCos App, into memory we don't necessarily need the overhead of a
NAND filesystem. 

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

jffs2 is i think by default, and the ext2 code is definitely read
only.
 
> 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?

It might be, if it saves code/data space.

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

Given the unfriendly license of YAFFS, i think uffs is more likely to
be the defacto standard NAND filesystem for eCos based systems, once
it gets ported and committed into the anoncvs tree. I've no idea what
it needs for mkfs like operations. 

YAFFS makes more sense for Linux, but i also expect there will be
pressure to add UBI/UBIFS support, since that seems to be the defacto
standard mainline NAND filesystem now, replacing JFFS2. 
 
> The original YAFFS tree includes a mkyaffs2image utility for turning a
> directory tree into an image file which can then be programmed to NAND with
> suitable software. (Being log-based, I suppose bad blocks wouldn't matter.)
> I haven't looked into this, but it smells pretty straightforward to add
> support to RedBoot to program such an image into NAND - much nicer than
> teaching it how to unpack (say) a tarball.

The problem with mkyaffs2image is that it is specific to yaffs. What
about uffs and UBIFS and even jffs2, etc. Supporting a simple archive
format, like cpio, is a much more generic solution.

> Dynamic partitions are conceptually not very far from the current model. The
> partition "table" is just an array hanging off the cyg_nand_device struct,
> which could in theory be modified by any code which chose to - either from
> logic, or interactively e.g. from RB. The interesting part is deciding where
> and how the table is to be stored, which influences how we would provide a
> call to write out a fresh partition table and whether this was accessible
> via a hosted Linux partition. (We'd also have to think carefully what it
> meant to change the table at runtime; what if there were mounted
> filesystems? open files? Would (could) we make it safe?)

This is the sort of discussion i want to see. How would Redboot do
this? What are the APIs? How does an eCos App get this information via
VV? How many times have i asked these questions?

You say not very far from the current model, so lets get is right now,
rather than have to break the world when we fix it later.

Getting the locking right would be nice, but we currently don't do any
locking with JFFS2. You can fis delete etc, when the filesystem is
mounted. Bad things then happen. 

         Andrew