Re: NAND review

[Rutger Hofman <rutger@cs.vu.nl>]

Andrew Lunn wrote:
>> 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. 

As I didn't want to tie the NAND user to malloc, I designed in a 
pluggable allocator. Often, the application can calculate beforehand how 
much memory is needed: 1) BBT, which depends on the NAND size; 2) 
per-thread space for the error handling. If there is no threaded kernel, 
it would be just the BBT which can be allocated statically by the 
application/platform.

>>> 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...")

The number of writes to a page between erases is often severely limited, 
like 2 or 4. Therefore bytewise writes are not really an option.

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

The file systems I took a look at read/write a complete page. NAND chips 
all support byte/word addressing, though. Like Andrew and Ross, I am not 
completely certain which is the best way to go. Limiting reads and 
writes to complete pages would make the code a little bit simpler in one 
or two places.

Rutger