[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