From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21329 invoked by alias); 3 Jun 2009 10:21:07 -0000 Received: (qmail 21306 invoked by uid 22791); 3 Jun 2009 10:21:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_ADVERT2,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 10:20:59 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 077CC3B40054; Wed, 3 Jun 2009 11:20:56 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhCXX08JcRTR; Wed, 3 Jun 2009 11:20:54 +0100 (BST) Message-ID: <4A264E85.6030202@ecoscentric.com> Date: Wed, 03 Jun 2009 10:21:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Andrew Lunn CC: "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> In-Reply-To: <20090603085115.GA27508@lunn.ch> Content-Type: text/plain; charset=ISO-8859-1 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/msg00006.txt.bz2 Hi Andrew, Thanks for the summary. If I may comment on a couple of technical points... > IMHO Ross's partitioning scheme/API is broken. I've tried to trigger > discussion about this, but there has not been much interest. I've been quiet recently as I've been pushing to get YAFFS and RedBoot integration up to the "complete first cut" stage. This has now happened; I have successfully loaded and run an eCos application image from a YAFFS filesystem on NAND flash using RedBoot. (YAFFS is on the BZ ticket; I will sort out the eCos-v-eCosPro differences and push my [minimal] RedBoot work to the ticket later today.) Now I've got time to take stock of all the useful feedback, and figuring out what I do with the partitioning scheme is one of the major issues! > [...] This got me a bit > worried about GPL issues, but there was an interesting comment from > Ross that an older version of MTD has a more eCos friendly license. For clarity, this related only to the ECC code in MTD, which I incorporated. The rest of my code is all fresh. > Initially i was a bit worried about Rutgers need for dynamic memory > allocation. [...] However, on > second thoughts, i don't think this is too big an issue. YAFFS needs > malloc/free. [...] So in general, redboot is going > to need malloc/free for supporting file systems, so having the NAND > library using it is not that bad. 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? > 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...") > There was comments from Ross about excessive stack usage blowing his > target away. This might indicate the immaturity of his code? Stack usage by my NAND layer is not a problem on my target in a default eCos config. It only becomes an issue when you try and use it under minimal (possibly another vertex case?), when it turns out that the default isn't big enough. I've fiddled the CDL in my working tree as a stopgap, and my todo list includes figuring out ways to improve this. (It's only one particularly stack-greedy function that has caused trouble, which might well benefit from a bit of algorithmic tuning. Or indeed, if we decide that it's OK for NAND to require malloc, then I can do a temporary malloc and free.) Similarly, I found that when RedBoot has CYGPKG_MEMALLOC loaded, its default heap size isn't big enough to mount even an empty YAFFS filesystem. There's another stopgap in place, and another todo list entry... Ross -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com