Re: NAND review

[Andrew Lunn <andrew@lunn.ch>]

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

The answer is yes. Simon, could you describe your board. From what i
understand you don't have much RAM. 

An example application area would be a data logger. It has a few
inputs, eg ADC, temperature sensors etc, and a NAND flash where it
stores the results. Its the sort of thing an AT91SAM7SE could do, 32K
RAM and 256K NOR FLASH for the code. 

There are two different major categories:

1) Using eCos/Redboot to get Linux booted. RAM is not going to be a problem.
2) eCos is the target OS and RAM could be limited.
 
> > 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...")
 
That is what i was thinking. Bytewise read makes more sense than
writing. Also, if the underlying chipset does not support bytewise
reading/writing, you end up needing a page buffer low down in the
stack, rather up in the application where it might be reusable for
other things when memory is tight.
 
        Andrew