Bootloader

Andy Green andy at openmoko.com
Thu Mar 20 00:18:05 CET 2008


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

Somebody in the thread at some point said:
> Andy Green wrote:
>>  - bootloader
>>  - kernel commandline string
> 
> The command line position could be implicit, e.g., the 2nd valid
> eraseblock. So we get this partition basically for free.

"dynparts" rides again :-(  I wonder if we steadily regenerate
everything we wanted to discard.

>>  - backup kernel
>>  - backup rootfs
> 
> That would be kernel+initramfs, and again, it could easily be implicit.
> (3rd valid eraseblock.)

Thing that bothers me about initramfs is you have to sit there while you
pull the whole thing before the kernel boots.  It is okay if the
initramfs is a few MB but maybe this will not be the case here if people
want graphical bits and bobs.  So maybe this should be a rootfs with its
own part, we only fetch what we use when we use it and boot will
complete quicker.

>> 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.
> 
> Ah, sorry, I meant hard-coding these things on the boot loader side,
> at the interface to the kernel. That would be the parameters, including
> the (now device-independent) partition table.

I figured you meant the hard-coded kernel commandline in the kernel
itself.  The issue about the partition number remains if not the device
that way.

>> 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.
> 
> Hmm, might be a little bit tricker, because we may have to skip a bad
> block (or, every 10'000 devices or so, two of them :-)

Not so if we deliver the correct partition starting block through this
dynparts thing accounting for it, since the bootloader is bad block aware.

But it is pretty ugly if we expose the block devices in linux bad blocks
and all, with no OOB in there to even figure out if they are bad, that
doesn't sound right.

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

iD8DBQFH4Z8tOjLpvpq7dMoRAodiAJ91+Dbr7030x7o86G0dDoihNZdB8ACgi6vw
IS/u4fPfOE2k9PDDqE4gTp4=
=J9qR
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list