From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20982 invoked by alias); 20 May 2009 14:16:50 -0000 Received: (qmail 20972 invoked by uid 22791); 20 May 2009 14:16:49 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:16:40 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 205233B4004A; Wed, 20 May 2009 15:16:36 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TzCw+Bb42Y7; Wed, 20 May 2009 15:16:34 +0100 (BST) Message-ID: <4A1410BA.3040808@ecoscentric.com> Date: Wed, 20 May 2009 14:16:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Andrew Lunn CC: Simon Kallweit , "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: <20090519141710.GJ20046@lunn.ch> 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/msg00051.txt.bz2 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. 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. Cheers, Ross -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com