Re: NAND review

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
------------------------------------------------------------