Bootloader
Werner Almesberger
werner at openmoko.org
Wed Mar 19 23:32:30 CET 2008
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.
> - backup kernel
> - backup rootfs
That would be kernel+initramfs, and again, it could easily be implicit.
(3rd valid eraseblock.)
> - main kernel
> - main rootfs (biggest)
Yup. Or look into scanning, say, the top-level directory of the
rootfs - for anything that doesn't have O(nand_size) lookup time.
> Burning a few MB of 256MB in padding sounds OK.
Cool. With the NAND we use in GTA02, the worst-case padding would be
40 blocks = 5MB. Padding on the rootfs would be implicit.
> 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.
> 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 :-)
> 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.
The future looks bright ;-)
- Werner
More information about the openmoko-kernel
mailing list