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