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