From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25180 invoked by alias); 19 Jun 2009 16:54:33 -0000 Received: (qmail 25172 invoked by uid 22791); 19 Jun 2009 16:54:32 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from d5152C2DE.access.telenet.be (HELO lx-dmz.televic.com) (81.82.194.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 16:54:26 +0000 Received: (qmail 17053 invoked from network); 19 Jun 2009 16:54:23 -0000 Received: from srv-vs06.televic.com (10.0.0.46) by lx-dmz.televic.com with (RC4-MD5 encrypted) SMTP; 19 Jun 2009 16:54:23 -0000 Received: from [127.0.0.1] (10.0.56.4) by SRV-VS06.TELEVIC.COM (10.0.0.46) with Microsoft SMTP Server id 8.1.291.1; Fri, 19 Jun 2009 18:55:06 +0200 Message-ID: <4A3BC2BF.3050106@televic.com> Date: Fri, 19 Jun 2009 16:54:00 -0000 From: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ross Younger CC: Andrew Lunn , "ecos-devel@ecos.sourceware.org" Subject: Re: Re: NAND review References: <4A3B9D36.4000704@ecoscentric.com> In-Reply-To: <4A3B9D36.4000704@ecoscentric.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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/msg00034.txt.bz2 Ross Younger wrote: >> Nick Garnett wrote: >> >> What is the typical life of a >> block? 10000 erases? A developer may conceivably replace the kernel >> 10,000 times, but in a deployed product i doubt this will happen. So i >> say forget about wear leveling for this case. >> > > I have been thinking about lifespan and how likely we are to come across > worn-bad blocks. The Samsung chip on the EA 2468 board specifies 100k > write/erase cycles per block and data retention of at least ten years, which > seems to be pretty typical for NAND parts, and comparable to most NOR parts? > yes, but 20 years data retention (Spansion NOR). > >> I'm assuming here that a NAND block >> goes bad because of writes and erases, not reads and age. So once the >> image has been successfully written, it should be readable forever. >> > > This is my understanding as well. > mine too. > >> Bad block are important. But a simple linear log structure should be >> sufficient. When reading/writing if the BBT says the block is good, >> use it, if it is bad, skip it. >> > > 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.) > > Worn-bad blocks are harder; you can't ever add one to the mapping, because > you'd have changed the in-flash address of everything above it. > > I've been thinking about this sort of question in the context of a simple > layer to make NAND look like NOR for RedBoot, and have had an interesting > idea which I'm going to propose on this list when I've written it up. > > > >> The rootfs is a more interesting issue. Linux is very unlikely to boot >> into a useful system without its rootfs. I see two options here. You >> could tftp boot using a initramfs loaded to RAM to boot into linux >> with a minimal system to perform a rootfs on NAND installation. Or >> redboot has to somehow put the rootfs into the NAND partition. >> > > You could also embed your entire rootfs into the kernel image as a cramfs. > > > >> 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? > > 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? > > >> 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.) > > The same with JFFS2 (after a bugfix in my case). Kind regards, Juergen