[U-Boot] [PATCH 0/6] ATSTK1000 LCD panel support

Haavard Skinnemoen haavard.skinnemoen at atmel.com
Tue Sep 2 14:09:03 CEST 2008


"Eirik Aanonsen" <eaa at 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


More information about the U-Boot mailing list