From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21208 invoked by alias); 3 Jun 2009 12:26:54 -0000 Received: (qmail 21195 invoked by uid 22791); 3 Jun 2009 12:26:53 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_ADVERT2 X-Spam-Check-By: sourceware.org Received: from smtp-vbr10.xs4all.nl (HELO smtp-vbr10.xs4all.nl) (194.109.24.30) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 12:26:47 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n53CQfsE014415; Wed, 3 Jun 2009 14:26:42 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A266C50.2030301@cs.vu.nl> Date: Wed, 03 Jun 2009 12:26:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Andrew Lunn CC: Ross Younger , "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <4A264E85.6030202@ecoscentric.com> <20090603104817.GC27508@lunn.ch> In-Reply-To: <20090603104817.GC27508@lunn.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00009.txt.bz2 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