Bootloader

[Werner Almesberger]

Andy Green wrote:
>  - If we have NAND back again, how are we going to manage the bad block
> stuff with this minimal bootloader?

There are two things we need bad block information for:

1) Avoid storing data in bad blocks.

2) Make sure the partitions have enough good blocks.

I think JFFS2 is fine with just the bad block information already
stored in NAND, i.e., it doesn't actually need the bad block table.
This needs verifying, also from a performance aspect.

For basic sequential read/write operations, we can skip over bad
blocks easily enough.

So issue 1) should be okay.

For issue 2), I'd attack from two angles: a) reduce the number of
partitions and make them larger. b) don't try to have "exact" sizes
but just add some spare blocks (and use statistical assurances, see
below)

b) consumes a certain number of blocks per partition, depending on
the number of bad blocks the NAND is supposed to have, the partition
size, distribution of bad blocks, and with which probability we want
to be able to fit our partitions onto a given NAND.

If the number of partitions is very small (two sounds like a good
number to me, one for booting and one for the file system), then we
could just allocate the worst-case number of bad blocks per partition
and take no risk at all.

Note that this is actually safer than the current supposedly exact
approach, since we can lose good blocks also during use, after
which our precisely fitted partition might be too small.

There are other tricks one could use if partition boundaries can be
roughly predicted, such as marking partitions in OOB data, but I'd
rather stay away from becoming overly dependent on NAND-specific
features.

>  - What about an environment?

Radical approach: hard-code anything that's environment (which would
be basically the boot parameter line - everything else is just the
partition table, internal u-boot housekeeping, or boot menu). Users
pick the kboot kernel if they want to pass their own parameters. (*)

Slightly less radical approach: have a well-known location with a
block that's used as the boot parameter line.

(*) Did we mention the "fastpath" yet ? The idea would be that the
    boot loader can boot either the "real" kernel directly, which
    would be the default, or the intermediate kernel which implements
    the boot loader user interface and any more advanced features.

> U-Boot env seems to be a place where bugs
> can come from in terms of the same devices acting different.

Yeah, and that's mainly because the partition table lives there.

What's nice is that, once you start to unravel the very complex
design we have now, it all falls into place in a much simpler way.

- Werner