From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7641 invoked by alias); 3 Jun 2009 10:48:30 -0000 Received: (qmail 7628 invoked by uid 22791); 3 Jun 2009 10:48:28 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_40,KAM_ADVERT2,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 10:48:22 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1MBo13-0002Y1-00; Wed, 03 Jun 2009 12:48:17 +0200 Date: Wed, 03 Jun 2009 10:48:00 -0000 From: Andrew Lunn To: Ross Younger Cc: Andrew Lunn , "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review Message-ID: <20090603104817.GC27508@lunn.ch> References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <4A264E85.6030202@ecoscentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A264E85.6030202@ecoscentric.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00007.txt.bz2 > 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