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
