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