From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16730 invoked by alias); 18 Jun 2009 14:10:25 -0000 Received: (qmail 16717 invoked by uid 22791); 18 Jun 2009 14:10:23 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from lon1-post-2.mail.demon.net (HELO lon1-post-2.mail.demon.net) (195.173.77.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Jun 2009 14:10:16 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by lon1-post-2.mail.demon.net with esmtp (Exim 4.69) id 1MHIJh-0003bI-bw; Thu, 18 Jun 2009 14:10:13 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id E49CD138776; Thu, 18 Jun 2009 15:10:12 +0100 (BST) 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> <20090613163115.GN5179@lunn.ch> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Thu, 18 Jun 2009 14:10:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00027.txt.bz2 Andrew Lunn writes: > > It is sometimes best to think about a concrete example, and my > > thoughts on NAND use were informed by thinking about how to use the > > NAND on an Atmel AT91SAM9 based device. > > I agree with the sentiment. Lets take another couple of examples. > > Both Rutger and Simon have NOR flash to boot from. They will put one > filesystem onto the NAND device. For them partitioning is just > bloat. I think that should be a strong argument for having an API > which does not enforce the use of partitions. The disk drive interface attempts to hide the partitioning behind a conventional driver interface and is forced to take a somewhat tortuous approach. I think trying to do the same in the NAND layer would be similarly tortuous. I believe that an API that is partition-aware from the start is preferable. I don't believe the code or data structures needed to support the partitions are particularly onerous. However, perhaps there is scope for making some of this more conditional if only one partition is expected. > > http://pokylinux.org/releases/pinky-3.1/readme.hardware > > The freescale ADS section talks about using NAND devices and putting > the partition table in the FIS directory. > > I found other freescale extensions for Redboot, but most information > seems to require that you register. However it looks like Freescale > have a redboot which fully integrated NAND devices into FIS and FIS > can be used to partition the flash. It is not entirely clear exactly what they are doing there. Does their flash driver handle wear levelling and bad blocks? Our approach is that a NOR flash emulation driver would operate within a partition of the NAND, rather than cover the whole thing. I am unconvinced that FIS is the right thing to use for partitioning a NAND flash. > > Your argument about the HAL knowing about the boot block sections > makes a lot of sense. However i think we need an architecture where > additional partition information can come from other places. FIS, or a > NandFIS would be one such other place. We also need to think about how > this information is exported, eg into file systems, to Linux, and to > RAM versions of eCos running on top of ROM or ROMRAM Redboot etc. My main concern is that we avoid reinventing the wheel, or end up inventing a square wheel. Looking at the more mature Linux NAND support, no consensus seems to have emerged over NAND partitioning. A very small number of platforms seem to use FIS in some form, but others just seem to define the partitions statically. I'm wary of jumping in here and defining something of our own, just for the sake of it. I would prefer a more cautious approach, keeping to a static approach until a consensus emerges. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071