From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15110 invoked by alias); 20 May 2009 13:34:58 -0000 Received: (qmail 15101 invoked by uid 22791); 20 May 2009 13:34:57 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr15.xs4all.nl (HELO smtp-vbr15.xs4all.nl) (194.109.24.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 13:34:53 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4KDYmZF005689; Wed, 20 May 2009 15:34:49 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A14083B.2040107@cs.vu.nl> Date: Wed, 20 May 2009 13:34:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <4A12B877.9030404@ecoscentric.com> <20090519141710.GJ20046@lunn.ch> In-Reply-To: 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-05/txt/msg00044.txt.bz2 Bart Veer wrote: >>>>>> "Andrew" == Andrew Lunn writes: > > >> The partition definition is necessarily platform-specific, so > >> doesn't fit anywhere else. > > Andrew> I simply don't get this. > > Andrew> Take a case i recently had with a NOR based system. I had > Andrew> a linux kernel bug i had to trace down. So that i had > Andrew> human readable kernel opps information, i rebuilt the > Andrew> kernel to include debug symbols. The resulting kernel was > Andrew> too big to fit in the space allocated to it. So i used > Andrew> redboot fis to zap both the root filesystem and the space > Andrew> holding the kernel. I recreated the kernel partition a bit > Andrew> bigger and made the root filesystem a bit smaller. I then > Andrew> installed the new kernel and the root filesystem. I then > Andrew> had a booting system with opps with symbols, not hex > Andrew> addresses. > > Andrew> At no point did i need to edit the HAL, rebuild and > Andrew> install a new redboot. Why should NAND be different? Why > Andrew> cannot this partition information be configured by > Andrew> redboot? Why must it be platform specific? > > I am not a NAND expert, but I think the answer is that NAND is > fundamentally different from NOR: it is unreliable. > [snip] > Or, we could try to implement a robust layer on top of the basic NAND > layer. If you want to store N pages reliably, reserve (N+f(N)+k) > pages in the NAND flash. When one of the pages starts failing, start > using one of the spare pages. Assume that updates will be infrequent > so that you do not need to worry about wear-levelling, just bad > blocks. This would give us a way of storing the partition info in the > NAND flash with a high degree of reliability. Unfortunately it means a > fairly complicated extra layer which will not be needed by e.g. > NAND-aware flash filesystems - those expect to handle the bad pages > etc. themselves. FWIW, this is the approach taken by MTD with the BBT (Bad Block Table). Rutger