Re: NAND review

[Ross Younger <wry@ecoscentric.com>]

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