From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25865 invoked by alias); 20 May 2009 14:21:48 -0000 Received: (qmail 25855 invoked by uid 22791); 20 May 2009 14:21:47 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hermes.mlbassoc.com (HELO mail.chez-thomas.org) (76.76.67.137) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:21:38 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 049FE3B52620; Wed, 20 May 2009 08:21:37 -0600 (MDT) Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id 3C8823B5261E; Wed, 20 May 2009 08:21:36 -0600 (MDT) Message-ID: <4A1411F0.1070805@mlbassoc.com> Date: Wed, 20 May 2009 14:21:00 -0000 From: Gary Thomas User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ross Younger CC: Andrew Lunn , Simon Kallweit , "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <4A12B877.9030404@ecoscentric.com> <20090519141710.GJ20046@lunn.ch> <4A1410BA.3040808@ecoscentric.com> In-Reply-To: <4A1410BA.3040808@ecoscentric.com> 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-05/txt/msg00053.txt.bz2 Ross Younger wrote: > Andrew Lunn wrote: >> Why cannot this partition information be configured by redboot? >> Why must it be platform specific? > > When I was designing my NAND library, I was striving for compatibility with > Linux - that is to say, the ability for an eCos app (RedBoot?) and a Linux > kernel to share the same NAND array. > > There has to be some sort of partition mechanism, but there is no really > standard way of doing so. The Linux MTD layer doesn't define anything in > this regard; typically, the partition info is passed to the kernel at boot > time (having been hard-coded into the bootloader or read from EEPROM or > somesuch) and it then appears in /dev as the relevant number of devices > (mtdblock*). What this means is - if I understand the situation correctly - > if whoever put the platform together wanted the chip to appear as multiple > partitions for whatever reason, they had to invent their own mechanism to > specify the dimensions. I don't know what/where you were looking to come to these conclusions :-( Linux MTD has had the ability to use the RedBoot FIS directory for many (7+) years. > If compatibility with Linux is not a selling point, then we can of course do > what we like. For example, it would be relatively straightforward for me to > carve off a block or two to robustly store a partition table - as Rutger > hints, the MTD bad block table as mimicked by both of our NAND libraries > already does this - and a little more work to add helper commands to RedBoot > to allow it to be manipulated interactively. However, if we went down this > route, it would be dangerous to maintain the pretence of compatibility with > Linux; this could of course be trivially given up by changing the signature > magic numbers on our BBT. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------