[ECOS] Re: NAND & YAFFS

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

Hi Folks

Last week a conversation started on the ecos maintainers list about
eCosCentric contributing their NAND flash framework. The emails are
archived at:

http://ecos.sourceware.org/ml/ecos-maintainers/2009-05/

and take a look at the thread NAND & YAFFS, started by Ross Younger.

We now have two NAND frameworks for integration consideration. Putting
the political situation to one side for a moment, i've started
reviewing the documentation for eCosCentrics code. This documentation
can be found at: http://bugs.ecos.sourceware.org/attachment.cgi?id=723
The code itself is not yet available. 

Those of you interesting in doing a side by side comparison with
Rutger Hofman's NAND framework, you can find his documentation at:

http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/nand-flash-doc-r595/io-nand-flash.html

and the code is available from:

http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/

I started a technical discussion about eCosCentrics partitioning
concept, however the ecos-maintainers list was not the right place for
it. So now i'm moving to ecos-discuss. 

On Sat, May 16, 2009 at 01:51:17PM +0100, Ross Younger wrote:
> Hi Andrew,
>
>> Im having trouble getting my head around partitions. 
>>
>> If i understand the documentation correctly, the only thing the
>> concept does it prevent a buggy filesystem or application reading data
>> from a different partition than it "opened" with
>> cyg_nand_get_partition(). The partition has zero affect on addressing.
>>
>> Am i missing something? What else are partitions good for?
>
> Partitions may be a bit of a misleading term for it, but it's the best I  
> could come up with. It seems quite common for boards (both dev boards, 
> and deployed products) to have a single NAND device or array, carved up 
> into two (or more) separate filesystems. As you observe, addressing is 
> completely unaffected, and this is based on my observations of other 
> devices; I added in the boundary enforcement purely out of paranoia.

So i guess there is no way to not compile it either? You have to go
from a flash device to a partition, so there is no easy way to remove
this functionality to save code space...

So it could be considered as bloat?

> Also, having the partition information in one place means that 
> filesystems can read out their limits from it, rather than having to be 
> configured separately.

Well, this sounds nice in theory, but there is no API call for
this. The documentation does not list a way to discover how many
partitions a device has. There is no way to find out a name for the
partition. There is no way to discover the size of a partition, what
the first and last page is etc... 

How does this also fit with redboot? You probably want a command in
redboot to list the partitions. You want to be able to mount a
filesystem from one of these partitions and then load the linux kernel
and maybe the ramfs into memory. How does redboot get to know the size
of the partition, etc. In fact, for NOR systems, it is redboot which
performs the partitioning, using the fis commands. The partition table
is stored in the fis configuration block. The flashdev layer can then
either use the fis block, or can be configured with cdl about
partitions.

How does this fit with Linux? mtd can also use the fis configuration
block so allowing linux to discover the partition information for NOR
devices. How is linux supposed to get the partition information out of
the eCos HAL for NAND devices?  By the time mtd gets around to wanting
this information, i guess the Linux kernel has destroyed the in memory
eCos/Redboot context information, so the HAL partition information is
no longer available.

My current feeling is that this partition concept does not belong in
the NAND core. It probably belongs in an optional layer above the NAND
flash. However, that is just my fist feelings.

It seems to me this partition idea has not yet been fully thought out
and needs further work. Maybe it is time for eCosCentric to post to
ecos-devel a design document for the partition concept and APIs as an
RFC?

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss