Re: NAND review

[Ross Younger <wry@ecoscentric.com>]

Hi Andrew,

Thanks for the summary. If I may comment on a couple of technical points...


> IMHO Ross's partitioning scheme/API is broken. I've tried to trigger
> discussion about this, but there has not been much interest. 

I've been quiet recently as I've been pushing to get YAFFS and RedBoot
integration up to the "complete first cut" stage. This has now happened; I
have successfully loaded and run an eCos application image from a YAFFS
filesystem on NAND flash using RedBoot. (YAFFS is on the BZ ticket; I will
sort out the eCos-v-eCosPro differences and push my [minimal] RedBoot work
to the ticket later today.) Now I've got time to take stock of all the
useful feedback, and figuring out what I do with the partitioning scheme is
one of the major issues!


> [...] This got me a bit
> worried about GPL issues, but there was an interesting comment from
> Ross that an older version of MTD has a more eCos friendly license.

For clarity, this related only to the ECC code in MTD, which I incorporated.
The rest of my code is all fresh.


> Initially i was a bit worried about Rutgers need for dynamic memory
> allocation. [...] However, on
> second thoughts, i don't think this is too big an issue. YAFFS needs
> malloc/free. [...] So in general, redboot is going
> to need malloc/free for supporting file systems, so having the NAND
> library using it is not that bad.

The philosophical question for us all is whether NAND on its own should be
allowed to use malloc, given that a NAND array will probably always be used
in conjunction with a log-structured filesystem which will chew up
comparatively large amounts of RAM (and, of course, RAM is forever getting
cheaper). Is this a corner or even N-dimensional vertex case; will it
necessarily always be the case that a device with NAND flash will have
enough RAM to support it? Do boards with NAND but not much RAM exist, and if
so do we care about them?


> Rutgers API allows reading/writing less than a page, eg just a few
> bytes. Ross's API is page based. I don't know if this is an advantage
> or a disadvantage. 

This is a tough one to call. I went for simplicity and a tight mapping to
the hardware. One could argue that providing a bytewise API might encourage
programmers unfamiliar with NAND flash to use it in a bytewise manner and
risk prematurely wearing out their chips. (I believe MTD has something along
these lines. "If it looks like a hammer...")


> There was comments from Ross about excessive stack usage blowing his
> target away. This might indicate the immaturity of his code? 

Stack usage by my NAND layer is not a problem on my target in a default eCos
config. It only becomes an issue when you try and use it under minimal
(possibly another vertex case?), when it turns out that the default isn't
big enough. I've fiddled the CDL in my working tree as a stopgap, and my
todo list includes figuring out ways to improve this. (It's only one
particularly stack-greedy function that has caused trouble, which might well
benefit from a bit of algorithmic tuning. Or indeed, if we decide that it's
OK for NAND to require malloc, then I can do a temporary malloc and free.)

Similarly, I found that when RedBoot has CYGPKG_MEMALLOC loaded, its default
heap size isn't big enough to mount even an empty YAFFS filesystem. There's
another stopgap in place, and another todo list entry...


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com