[U-Boot] [PATCH 0/6] ATSTK1000 LCD panel support
Haavard Skinnemoen
haavard.skinnemoen at atmel.com
Wed Sep 3 11:03:11 CEST 2008
Ben Nizette <bn at niasdigital.com> wrote:
>
> On Tue, 2008-09-02 at 14:09 +0200, Haavard Skinnemoen wrote:
> > 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.
>
> If we do end up with libfdt on avr32 then we solve our problems here
> too, we can encapsulate this partitioning in the fdt image.
Yes, we can probably do that. I guess it all depends on what we want to
do first.
> But, as I
> understand it, that involves not only the actual libfdt support but
> making all avr32 driver nice and OF compatible. At least, if we want
> the fdt support to be _useful_ then that needs to happen (CMIIW).
Or we could just add a glue layer which creates platform_devices based
on the fdt information. Perhaps pass along a pointer to the device tree
node for drivers that want to peek at it. PowerPC has a of_node in
struct dev_archdata for this purpose I believe.
> > 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.
>
> Doesn't the MTD system have facility to override partitioning
> information from the boot arguments? If so then any big u-boots can
> just ship with such a clause in their default bootargs, job done. Have
> to look in to that...
Yes. But it won't fix boards which already have a valid environment and
just want to upgrade u-boot. We could perhaps fix up the bootargs and
add partitioning information when preparing to boot the kernel...
Haavard
More information about the U-Boot
mailing list