This is the mail archive of the
mailing list for the eCos project.
Re: NAND review
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: Ross Younger <wry at ecoscentric dot com>, "ecos-devel at ecos dot sourceware dot org" <ecos-devel at ecos dot sourceware dot org>
- Date: Wed, 03 Jun 2009 14:28:00 +0200
- Subject: Re: NAND review
- References: <4A126D59.firstname.lastname@example.org> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <4A264E85.email@example.com> <20090603104817.GC27508@lunn.ch>
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
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.