Bootloader

Andy Green andy at openmoko.com
Thu Mar 20 01:37:27 CET 2008


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

Somebody in the thread at some point said:
> Andy Green wrote:
>> Yep, dynamic generation of kernel commandline has managed to exist based
>> on bad blocks :-)
> 
> The command line content would not be affected by bad blocks. The
> kernel also sees it always at the same place. Just the boot loader
> wouldn't always see it at the same place, but that's also true for
> any other block it loads.

OK.  This being because we did the padding thing all partition starts
can ignore the bad blocks that went before.  Well that is good.

>> We need to decide about that based on the max size allocated for this
>> recovery system, not the minimum and "optimize later".  What max size
>> are you thinking of here for recovery kernel and rootfs / initrd?
> 
> I think we'll be fine with 2MB for kernel plus 2MB for initramfs.
> When selecting memory chips or allocating partition space, I'd
> double that figure as "engineering tolerance".

<= 2MB is fine as initramfs for me but aren't we closing off the
possibility for a wonderland of graphical apps and so on in there?  Or
these must come from the main rootfs?

>> No, I mean if you open the block device for dd or whatever, there is no
>> "out of band" information in that device node.  You just get
>> dysfunctional blocks.
> 
> You get that now as well.

Wow NAND really sucks badly.  I have used dd on the mtd block devices
and just been lucky I guess.

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

iD8DBQFH4bHHOjLpvpq7dMoRAsTsAJ4knuNO1I5w9F7BJri3baWNUrqsuACfXWlE
x0Ro7vbYGnqOZEnKWy4419M=
=oZQD
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list