Bootloader

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

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

Well that will be simpler.

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

OK.

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

Hum.  Since we can't parse ext2 at the moment we will need at least
these partitions if I understood the intention for NAND

 - bootloader
 - kernel commandline string
 - backup kernel
 - backup rootfs

and additionally if we accept to use NAND for the main rootfs

 - main kernel
 - main rootfs (biggest)

Burning a few MB of 256MB in padding sounds OK.

>>  - 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. (*)

I agree that if we define the bootloader as just a kernel loader, then
the only legitimate settings in there would be directly to do with how
to run the kernel.  But isn't it a serious problem that we need a
different kernel image to run from SD (root=mmcblk<n>p<m>...) in that
case than from NAND?  And then the kernels will only function when
coming from a specific partition index on their specific media?

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

Yes I thought of this too I think it is better.  One can echo into the
partition block device even to update it if we take \n as end of 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.

I think this is fine but I just think of it as an alternate kernel +
rootfs because we can do that from day 1.  If that kexec thing comes
into being it can seamlessly replace the old normal alternate kernel
with no changes on the bootloader side.

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

Also the kernel commandline too.

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

So we didn't see that U-Boot clawed its way out of the grave, we avoided
any environment except kernel commandline, and we think we discarded the
bad block table and customized partition sizing stuff.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4YaiOjLpvpq7dMoRAoeiAJ9L6Uenvj20MRbNevsv/KmZ6XK8dgCeMzre
GpAhzkefCD1x/UrS0aFCG6E=
=P94S
-----END PGP SIGNATURE-----