This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND review


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]