Re: NAND review

On Thu, Jun 18, 2009 at 03:10:12PM +0100, Nick Garnett wrote:
> Andrew Lunn <[email protected]> writes:
> 
> > > It is sometimes best to think about a concrete example, and my
> > > thoughts on NAND use were informed by thinking about how to use the
> > > NAND on an Atmel AT91SAM9 based device. 
> > 
> > I agree with the sentiment. Lets take another couple of examples.
> > 
> > Both Rutger and Simon have NOR flash to boot from. They will put one
> > filesystem onto the NAND device. For them partitioning is just
> > bloat. I think that should be a strong argument for having an API
> > which does not enforce the use of partitions.
> 
> 
> The disk drive interface attempts to hide the partitioning behind a
> conventional driver interface and is forced to take a somewhat
> tortuous approach. I think trying to do the same in the NAND layer
> would be similarly tortuous.

We don't need to follow the disk driver approach to partitioning. As
Ross said, he used the name "partition" because he could not think of
a better name. However the name does not imply we need to follow the
normal ways for partitions. All we need is a suitable API which is
efficient when used with partitions and without partitions.

> I believe that an API that is partition-aware from the start is
> preferable.

and i prefer an API which works well with and without partitions. 

> I don't believe the code or data structures needed to
> support the partitions are particularly onerous. However, perhaps
> there is scope for making some of this more conditional if only one
> partition is expected.

Looking at the existing use cases we know about, the systems which
don't need partitions are the ones with the most resource
constrains. Simon does not need partitions, he plans to use a very
lean and mean FS, and only has a small amount of ROM and RAM. With
Ross's API there is the partitions data structure in the HAL, the code
to get this out of the HAL and into the flash library, the extra
function call needed to get a partition handle, and then the checks
used to validate addresses are inside the partition. I've no idea how
much this adds up to in terms of code and data, so i've no idea how
big the overhead is.

> It is not entirely clear exactly what they are doing there. Does their
> flash driver handle wear levelling and bad blocks?
> 
> Our approach is that a NOR flash emulation driver would operate within
> a partition of the NAND, rather than cover the whole thing. I am
> unconvinced that FIS is the right thing to use for partitioning a NAND
> flash.

Lets thinks of a few use cases. These are somewhat hypothetical, since
i don't actually have any NAND device in my hands, but hopefully they
are realistic.

Category 1: Getting Linux booted

I see two layouts here:

1) A dedicated partition which contains the kernel and then addition
partitions for the root FS and maybe other FSs.

2) No dedicated kernel partition, the kernel is in /boot on the root
FS.

Having the kernel separate could make it easier/faster to update
during development, since you don't need to touch the rootfs. And the
same is true the other way around, you can replace the rootfs without
touching your known good kernel.

If you have a dedicates partition, sized about right for the kernel,
level wearing brings you nothing. There are no hot blocks in the
kernel image, you replace it all every time. And how often do you
replace the kernel? During development work, maybe quite often, but
once the system is deployed, rarely. What is the typical life of a
block? 10000 erases? A developer may conceivably replace the kernel
10,000 times, but in a deployed product i doubt this will happen. So i
say forget about wear leveling for this case.

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. I'm assuming here that a NAND block
goes bad because of writes and erases, not reads and age. So once the
image has been successfully written, it should be readable forever.

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. This
leads to three things:

1) Full read/write support for the FS in Redboot. For NOR we normally
   have only read support.

2) mkfs functionality.

3) Redboot needs to support some simple archive format, cpio, tar,
   etc, so you can upload the rootfs as an archive and unpack it onto
   the filesystem. And given that the NAND is likely to be bigger than
   RAM, maybe this has to be done as a stream.

Unlike NOR, you cannot write a filesystem image to a NAND
partition. So you need to write individual files, using the file
system code itself. You also need to be able to create the empty file
system, so mkfs is needed.

Once you have redboot with mkfs support, you have all you need to
support dynamic partition sizes. Its then just of question of having
somewhere to store this dynamic information, and FIS or NandFIS seems
the obvious candidate.

Category 2: Getting eCos images booted

The same two layouts as for Linux make sense here. 

One difference is that an eCos image could do something useful without
a "rootfs". The mkfs code could be in the eCos image, so that on first
boot it detects the filesystem is invalid and formats it. This would
allow a smaller redboot image, when using the first layout, since no
filesystem support is needed, just the simple linear log structure.
Also, dynamic partitions is again possible, the mkfs code has to be
somewhere, either in the eCos application image or in Redboot.


For me, dynamic partitions make sense. I'm not saying that release 1.0
needs to have them, we just need to make sure that the design of
release 1.0 is sufficiently flexible that adding dynamic partitions is
just a release 1.1 feature and not a rip the guts out and start again
for release 2.0.

    Andrew