Re: NAND review

[Nick Garnett <nickg@ecoscentric.com>]

Andrew Lunn <andrew@lunn.ch> 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.

I believe that an API that is partition-aware from the start is
preferable. 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.

> 
> http://pokylinux.org/releases/pinky-3.1/readme.hardware
> 
> The freescale ADS section talks about using NAND devices and putting
> the partition table in the FIS directory.
> 
> I found other freescale extensions for Redboot, but most information
> seems to require that you register. However it looks like Freescale
> have a redboot which fully integrated NAND devices into FIS and FIS
> can be used to partition the flash.

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.

> 
> Your argument about the HAL knowing about the boot block sections
> makes a lot of sense. However i think we need an architecture where
> additional partition information can come from other places. FIS, or a
> NandFIS would be one such other place. We also need to think about how
> this information is exported, eg into file systems, to Linux, and to
> RAM versions of eCos running on top of ROM or ROMRAM Redboot etc.

My main concern is that we avoid reinventing the wheel, or end up
inventing a square wheel. Looking at the more mature Linux NAND
support, no consensus seems to have emerged over NAND partitioning. A
very small number of platforms seem to use FIS in some form, but
others just seem to define the partitions statically. I'm wary of
jumping in here and defining something of our own, just for the sake
of it. I would prefer a more cautious approach, keeping to a static
approach until a consensus emerges. 

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071