Bootloader

[Andy Green]

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

Somebody in the thread at some point said:

>> 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?
> 
> In the worse case, we keep u-boot for development purposes, but devices
> will ship with a minimal bootloader.

If we had to still use U-Boot to do something serious we admitted defeat
on the effort I think.  Working on two kinds of bootloader is not a
great idea.  If it panned out like that we should just use U-Boot
configured without any features.  But I don't think it panned out like that.

Werner pointed out later we can at least infer the device for root= and
patch the commandline (since we know what device we are pulling the
kernel image from).  So we have a fixed kernel part index really which
we could live with if also done by device (so it is always mmcblk0p1 and
mtdblock3 for example).  But then not having a soft commandline means we
have to also fix the filesystem type and worse the init=.  That is a bit
of a cramp although we could live with it I suppose.

Later we figured we could have a soft commandline (alone) in an
"environment block" and get this flexibility.

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

iD8DBQFH4rvDOjLpvpq7dMoRAorLAJ9mro310ZX+4q5FMymtPc9TGhW86ACfX04J
LdXyzHQZGKaw1LWi5MHwrvk=
=KLqr
-----END PGP SIGNATURE-----