"Eirik Aanonsen" eaa@wprmedical.com wrote:
I'm talking about changing the partitioning specifically on ATSTK1000. Other boards can do whatever they want. But it may be a good idea to reserve 256k anyway since it becomes less likely that we'll have to do the same thing all over again in the future.
But making it more likely to have equal partitions makes it easier to test kernels on different boards for debugging. I use my kernel on both the stk1000 and my own custom board. Then again no big deal but makes compliance/testing easier.
Right. I was thinking maybe we could extend the boot protocol to pass partitioning information from u-boot to the kernel -- that should make it possible to run the same kernel on boards with different flash layout as long as the in-flash u-boot is consistent with the flash layout.
One problem this doesn't solve is that if you load an older kernel which doesn't understand the extended boot protocol, it will keep using the old flash layout.
I have to say I was a bit surprised by the size of the NAND code though. The LCD code is sort of excused since it sucks in a big uncompressed logo...
Is there any plans for supporting the UBI/UBIFS, or is it planned? ( prob. not but yes it is large, but too large? )
I've seen some discussions with patches on the upstream u-boot list. Would be very nice to have.
I suspect some of the problem with the NAND code is all the default ops which aren't used by anything but can't be garbage collected by the linker because they are referenced by nand_set_defaults().
Haavard