From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13637 invoked by alias); 19 Jun 2009 15:02:54 -0000 Received: (qmail 13418 invoked by uid 22791); 19 Jun 2009 15:02:51 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,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; Fri, 19 Jun 2009 15:02:46 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1MHfc3-00008p-00; Fri, 19 Jun 2009 17:02:43 +0200 Date: Fri, 19 Jun 2009 15:02:00 -0000 From: Andrew Lunn To: Ross Younger Cc: "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review Message-ID: <20090619150243.GD1188@lunn.ch> References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <20090613163115.GN5179@lunn.ch> <20090619074659.GA1188@lunn.ch> <4A3B9D36.4000704@ecoscentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3B9D36.4000704@ecoscentric.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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/msg00033.txt.bz2 > Properly NAND-aware filesystems take both kinds of bad blocks in their > stride; there's no point in adding the complexity if such a mapping if > you're using such a filesystem. > > Even with something simpler, factory-bad blocks are straightforward: as you > say, one can simply linear-map them into oblivion in the driver at the cost > of extra time complexity *on every NAND operation*. (I add the emphasis > because I expect the overhead will add up fast if the NAND is heavily used.) I'm not suggesting putting this in the driver. I'm suggesting RedBoot commands nandfis load and nandfis create does this. As you said, a full NAND filesystem will handle bad blocks etc. However, just to get an executable image, be it the Linux kernel, or an eCos App, into memory we don't necessarily need the overhead of a NAND filesystem. > > This leads to three things: > > > > 1) Full read/write support for the FS in Redboot. For NOR we normally > > have only read support. > > Do you mean jffs2? jffs2 is i think by default, and the ext2 code is definitely read only. > At the moment my YAFFS layer is fully read-write, but I could add a > read-only switch if this was thought to be useful? It might be, if it saves code/data space. > > 2) mkfs functionality. > > I don't know about other filesystems, but YAFFS always scans the NAND on > mount, and automatically does the Right Thing when asked to mount a > fully-erased array. (My RedBoot patch already includes logic to erase a nand > partition.) Given the unfriendly license of YAFFS, i think uffs is more likely to be the defacto standard NAND filesystem for eCos based systems, once it gets ported and committed into the anoncvs tree. I've no idea what it needs for mkfs like operations. YAFFS makes more sense for Linux, but i also expect there will be pressure to add UBI/UBIFS support, since that seems to be the defacto standard mainline NAND filesystem now, replacing JFFS2. > The original YAFFS tree includes a mkyaffs2image utility for turning a > directory tree into an image file which can then be programmed to NAND with > suitable software. (Being log-based, I suppose bad blocks wouldn't matter.) > I haven't looked into this, but it smells pretty straightforward to add > support to RedBoot to program such an image into NAND - much nicer than > teaching it how to unpack (say) a tarball. The problem with mkyaffs2image is that it is specific to yaffs. What about uffs and UBIFS and even jffs2, etc. Supporting a simple archive format, like cpio, is a much more generic solution. > Dynamic partitions are conceptually not very far from the current model. The > partition "table" is just an array hanging off the cyg_nand_device struct, > which could in theory be modified by any code which chose to - either from > logic, or interactively e.g. from RB. The interesting part is deciding where > and how the table is to be stored, which influences how we would provide a > call to write out a fresh partition table and whether this was accessible > via a hosted Linux partition. (We'd also have to think carefully what it > meant to change the table at runtime; what if there were mounted > filesystems? open files? Would (could) we make it safe?) This is the sort of discussion i want to see. How would Redboot do this? What are the APIs? How does an eCos App get this information via VV? How many times have i asked these questions? You say not very far from the current model, so lets get is right now, rather than have to break the world when we fix it later. Getting the locking right would be nice, but we currently don't do any locking with JFFS2. You can fis delete etc, when the filesystem is mounted. Bad things then happen. Andrew