Device tree.

Device tree.

[Ian Molton]

I've found some references to this in the mailinglist archives but 
nothing conclusive.

Whats the recommended way of dealing with devicetree when one is stuck 
with an unco-operative bootloader?

I've made a small hack (below) to allow me to append a .dtb to the end 
of the kernel image. I note that other similar hacks have not been 
picked up, but I can't see why. Or I've missed the one that did get chosen.

TTFN!

-Ian

------------------------------- arch/arm/Kconfig 
-------------------------------
index 519b5e0..cd82cbc 100644
@@ -1105,6 +1105,10 @@ source "arch/arm/mach-vt8500/Kconfig"

  source "arch/arm/mach-w90x900/Kconfig"

+config EMBEDDED_DTB
+    string "Embedded device tree blob" if OF
+    default ""
+
  # Definitions to make life easier
  config ARCH_ACORN
      bool

---------------------------- arch/arm/boot/Makefile 
----------------------------
index c877087..8e43741 100644
@@ -44,6 +44,9 @@ $(obj)/xipImage: FORCE
      @echo 'Kernel not configured for XIP (CONFIG_XIP_KERNEL!=y)'
      @false

+#append Device Tree .dtb file after vmlinux
+cmd_do_append_dtb = if [ "$(CONFIG_EMBEDDED_DTB)" != "" ]; then cat 
$(CONFIG_EMBEDDED_DTB) >> $@ ; fi
+
  $(obj)/Image: vmlinux FORCE
      $(call if_changed,objcopy)
      @echo '  Kernel: $@ is ready'
@@ -53,6 +56,7 @@ $(obj)/compressed/vmlinux: $(obj)/Image FORCE

  $(obj)/zImage:    $(obj)/compressed/vmlinux FORCE
      $(call if_changed,objcopy)
+    $(call if_changed,do_append_dtb)
      @echo '  Kernel: $@ is ready'

  endif

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 12:55:53 +0100,
Ian Molton <ian.molton@codethink.co.uk> a ?crit :

> I've found some references to this in the mailinglist archives but 
> nothing conclusive.
> 
> Whats the recommended way of dealing with devicetree when one is
> stuck with an unco-operative bootloader?
> 
> I've made a small hack (below) to allow me to append a .dtb to the
> end of the kernel image. I note that other similar hacks have not
> been picked up, but I can't see why. Or I've missed the one that did
> get chosen.

You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does
what you want and is already part of the ARM kernel.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Ian Molton]

On 17/07/12 13:01, Thomas Petazzoni wrote:
> You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does 
> what you want and is already part of the ARM kernel.

Hi, and thanks.

Unless I'm misunderstanding it, thats not quite what I need - although I 
should probably have made my hack depend on it.

I'm using a uImage; The prepending needs to happen to the zImage / Image.

-Ian

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 13:13:03 +0100,
Ian Molton <ian.molton@codethink.co.uk> a ?crit :

> Unless I'm misunderstanding it, thats not quite what I need -
> although I should probably have made my hack depend on it.
> 
> I'm using a uImage; The prepending needs to happen to the zImage /
> Image.

What I typically do is generate a zImage, do the appending, and then
generate the uImage manually with mkimage. But I agree it could be
useful to have a 'make uImage.myboard' target which would happen the
myboard.dtb before preparing the uImage.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Josh Coombs]

On Tue, Jul 17, 2012 at 8:13 AM, Ian Molton <ian.molton@codethink.co.uk> wrote:
> On 17/07/12 13:01, Thomas Petazzoni wrote:
>>
>> You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does what
>> you want and is already part of the ARM kernel.
>
>
> Hi, and thanks.
>
> Unless I'm misunderstanding it, thats not quite what I need - although I
> should probably have made my hack depend on it.
>
> I'm using a uImage; The prepending needs to happen to the zImage / Image.
>
> -Ian

CONFIG_ARM_APPENDED_DTB sets the kernel up to expect a dtb appended to
the end of the zImage.  Neither make or make uImage do the appending
for you however.  What I've been doing is:

make
make target.dtb
cat arch/arm/boot/target.dtb >> arch/arm/boot/zImage
make uImage
move arch/arm/boot/uImage to wherever it needs to be and try booting

My understanding is you can only append one DTB, there is no
restriction on how many systems a given kernel could support, so at
the moment there isn't a clean way of defining which DTB to append
during make uImage?

Josh C

Device tree.

[Florian Fainelli]

On Tuesday 17 July 2012 14:29:26 Thomas Petazzoni wrote:
> Le Tue, 17 Jul 2012 13:13:03 +0100,
> Ian Molton <ian.molton@codethink.co.uk> a ?crit :
> 
> > Unless I'm misunderstanding it, thats not quite what I need -
> > although I should probably have made my hack depend on it.
> > 
> > I'm using a uImage; The prepending needs to happen to the zImage /
> > Image.
> 
> What I typically do is generate a zImage, do the appending, and then
> generate the uImage manually with mkimage. But I agree it could be
> useful to have a 'make uImage.myboard' target which would happen the
> myboard.dtb before preparing the uImage.

Appending a given device tree blob to a zImage is something that should be 
solved outside of the kernel build imho.

Since your bootloader is already "non-cooperative" wrt DTBs, you need to 
provide a specific uImage (zImage + dtb) for it.

I do not think the kernel build should try to generate as many zImages as 
there dtb files, nor any other combination, this really is distribution 
specific.
--
Florian

Device tree.

[Ian Molton]

On 17/07/12 13:32, Josh Coombs wrote:
> make make target.dtb
> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
 >make uImage

Yick...

 >My understanding is you can
 > only append one DTB, there is no restriction on how many systems a
 > given kernel could support, so at the moment there isn't a clean way
 > of defining which DTB to append during make uImage? Josh C

Yes, hence why it'd be useful to have a way of specifying a .dtb file as 
a config option...

There isnt really a good way to solve this, AFAICT.

-Ian

Device tree.

[Ben Dooks]

On 17/07/2012 14:07, Ian Molton wrote:
> On 17/07/12 13:32, Josh Coombs wrote:
>> make make target.dtb
>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>make uImage
>
> Yick...

How about adding a dts=<address> argument to the current
command line handling. If this is found, then the system
ignores the rest of the atags passed and uses the passed
address for the device-tree settings.

This means in u-boot, you just need to load the .dts file
into place before booting the kernel.

-- 
Ben

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 14:41:35 +0200,
Florian Fainelli <florian@openwrt.org> a ?crit :

> > What I typically do is generate a zImage, do the appending, and then
> > generate the uImage manually with mkimage. But I agree it could be
> > useful to have a 'make uImage.myboard' target which would happen the
> > myboard.dtb before preparing the uImage.
> 
> Appending a given device tree blob to a zImage is something that
> should be solved outside of the kernel build imho.

Well, both PowerPC and Microblaze, and apparently C6X, have some sort
of <imageFormat>.<dtbName> make target:

$ make ARCH=microblaze help
[...]
  simpleImage.<dt> - ELF image with /boot/dts/<dt>.dts linked in
                   - stripped elf with fdt blob
  simpleImage.<dt>.unstrip - full ELF image with fdt blob

$ make ARCH=powerpc help
[...]
  cuImage.<dt>    - Backwards compatible U-Boot image for older
                    versions which do not support device trees
  dtbImage.<dt>   - zImage with an embedded device tree blob
  simpleImage.<dt> - Firmware independent image.
  treeImage.<dt>  - Support for older IBM 4xx firmware (not U-Boot)

$ make ARCH=c6x help
[...]
  dtbImage.<dt>   - ELF image with /boot/dts/<dt>.dts linked in
                  - stripped elf with fdt blob

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Rob Herring]

On 07/17/2012 08:25 AM, Ben Dooks wrote:
> On 17/07/2012 14:07, Ian Molton wrote:
>> On 17/07/12 13:32, Josh Coombs wrote:
>>> make make target.dtb
>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>> make uImage
>>
>> Yick...
> 
> How about adding a dts=<address> argument to the current
> command line handling. If this is found, then the system
> ignores the rest of the atags passed and uses the passed
> address for the device-tree settings.
> 
> This means in u-boot, you just need to load the .dts file
> into place before booting the kernel.
> 
You mean dtb...

But no, we don't need a 3rd boot interface in the kernel. I don't see
why cat + mkimage is too hard to run.

Now that u-boot has direct support for zImage booting, I doubt anything
uImage building related will ever be accepted into the kernel.

Rob

Device tree.

[Ben Dooks]

On 17/07/2012 14:52, Rob Herring wrote:
> On 07/17/2012 08:25 AM, Ben Dooks wrote:
>> On 17/07/2012 14:07, Ian Molton wrote:
>>> On 17/07/12 13:32, Josh Coombs wrote:
>>>> make make target.dtb
>>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>>> make uImage
>>>
>>> Yick...
>>
>> How about adding a dts=<address> argument to the current
>> command line handling. If this is found, then the system
>> ignores the rest of the atags passed and uses the passed
>> address for the device-tree settings.
>>
>> This means in u-boot, you just need to load the .dts file
>> into place before booting the kernel.
>>
> You mean dtb...
>
> But no, we don't need a 3rd boot interface in the kernel. I don't see
> why cat + mkimage is too hard to run.

I suppose we can produce our own build-script

> Now that u-boot has direct support for zImage booting, I doubt 
> anything
> uImage building related will ever be accepted into the kernel.

Depends on u-boot, the one we have been supplied doesn't seem to
have any interest in booting zImages.

-- 
Ben

Device tree.

[Florian Fainelli]

On Tuesday 17 July 2012 14:56:33 Ben Dooks wrote:
> On 17/07/2012 14:52, Rob Herring wrote:
> > On 07/17/2012 08:25 AM, Ben Dooks wrote:
> >> On 17/07/2012 14:07, Ian Molton wrote:
> >>> On 17/07/12 13:32, Josh Coombs wrote:
> >>>> make make target.dtb
> >>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
> >>>> make uImage
> >>>
> >>> Yick...
> >>
> >> How about adding a dts=<address> argument to the current
> >> command line handling. If this is found, then the system
> >> ignores the rest of the atags passed and uses the passed
> >> address for the device-tree settings.
> >>
> >> This means in u-boot, you just need to load the .dts file
> >> into place before booting the kernel.
> >>
> > You mean dtb...
> >
> > But no, we don't need a 3rd boot interface in the kernel. I don't see
> > why cat + mkimage is too hard to run.
> 
> I suppose we can produce our own build-script
> 
> > Now that u-boot has direct support for zImage booting, I doubt 
> > anything
> > uImage building related will ever be accepted into the kernel.
> 
> Depends on u-boot, the one we have been supplied doesn't seem to
> have any interest in booting zImages.

In that case you just need to make sure that you produce a valid uImage of 
your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions 
without any issues.
--
Florian

Device tree.

[Mark Brown]

On Tue, Jul 17, 2012 at 08:52:34AM -0500, Rob Herring wrote:
> On 07/17/2012 08:25 AM, Ben Dooks wrote:

> > This means in u-boot, you just need to load the .dts file
> > into place before booting the kernel.

> You mean dtb...

> But no, we don't need a 3rd boot interface in the kernel. I don't see
> why cat + mkimage is too hard to run.

> Now that u-boot has direct support for zImage booting, I doubt anything
> uImage building related will ever be accepted into the kernel.

u-boot isn't the only bootloader that does uImage, and of course the
issue here is people stuck with old bootloaders that they don't want to
upgrade for whatever reason (or just don't want to let the bootloader
know about DT due to the incompatibility with non-DT kernels) so the
availability of new bootloaders doesn't help as much as it should.

Device tree.

[Ian Molton]

On 17/07/12 15:02, Florian Fainelli wrote:
> Depends on u-boot, the one we have been supplied doesn't seem to
> have any interest in booting zImages.
> In that case you just need to make sure that you produce a valid uImage of
> your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions
> without any issues.

Thats what my little patch does. It just makes life a bit less painful 
if you're stuck with a particular bootloader. Its not an uncommon problem.

-Ian

Device tree.

[Nicolas Pitre]

On Tue, 17 Jul 2012, Ian Molton wrote:

> On 17/07/12 15:02, Florian Fainelli wrote:
> > Depends on u-boot, the one we have been supplied doesn't seem to
> > have any interest in booting zImages.
> > In that case you just need to make sure that you produce a valid uImage of
> > your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions
> > without any issues.
> 
> Thats what my little patch does. It just makes life a bit less painful if
> you're stuck with a particular bootloader. Its not an uncommon problem.

That pain is the only leverage we have to have you fix the bootloader 
somehow.  If you prefer or have to bodge around it then you keep the 
hack for yourself.

We want people to get into the habit of building and distributing a 
generic kernel image.  Appending a dtb to zImage and/or wrapping it into 
a uImage should be considered installation steps which are best done 
outside of the kernel build system.  And they are quite trivial to do as 
well.


Nicolas

Device tree.

[Ian Molton]

On 17/07/12 22:18, Nicolas Pitre wrote:

> That pain is the only leverage  we have to have you fix the bootloader
 > somehow.

Yes, because this tactic has worked just great historically...

Other than chainbooting /another/ bootloader, how do you propose people 
fix this issue? Not everyone has a co-operative vendor.

> If you prefer or have to bodge  around it then you keep the
 > hack for yourself.

And for those of us where this is not an option?

> We want people to get into the  habit of building and distributing a
 > generic kernel image.

Which is all lovely, but sometimes simply not appropriate.

> Appending a dtb to zImage  and/or wrapping it
 > into a uImage should be considered installation steps which are best
 > done outside of the kernel build system. And they are quite trivial
 > to do as well.

Then perhaps the 'hack' to allow appending should be removed from the 
kernel, too, by the same logic - after all, its only 'enabling' people 
to cling to ancient bootloaders...

Honestly, all the fuss about "R2 + ATAGS must be the only way", and now 
we can pass in data in non-ATAG form, via appending to the kernel image, 
at whatever random location that might wind up being.

Either ATAGs the only way, or they aren't. If appending to zImage is 
'way 2' then it should be possible to choose what gets appended at build 
time. If not, the option has no business being in the kernel at all. Do 
it properly or not at all.

Whats the point in make uImage if you cant use it?

Device tree.

[Nicolas Pitre]

On Wed, 18 Jul 2012, Ian Molton wrote:

> On 17/07/12 22:18, Nicolas Pitre wrote:
> 
> > That pain is the only leverage  we have to have you fix the bootloader
> > somehow.
> 
> Yes, because this tactic has worked just great historically...

It certainly did.  Look at the latest u-Boot which 1) has support for 
device tree on ARM, and 2) has support to boot a zImage directly.  And 
some people were able to modify their old u-Boot as well because of this 
policy.

> Other than chainbooting /another/ bootloader, how do you propose people fix
> this issue? Not everyone has a co-operative vendor.

Ask your vendor harder.  They would care even less if the kernel was 
more accommodating.

> > If you prefer or have to bodge  around it then you keep the
> > hack for yourself.
> 
> And for those of us where this is not an option?

This is always an option to you.  You have the patch already, it doesn't 
necessarily have to live in mainline.

> > We want people to get into the  habit of building and distributing a
> > generic kernel image.
> 
> Which is all lovely, but sometimes simply not appropriate.

Please deal with it.  Going the other way isn't appropriate for mainline 
either.

> > Appending a dtb to zImage  and/or wrapping it
> > into a uImage should be considered installation steps which are best
> > done outside of the kernel build system. And they are quite trivial
> > to do as well.
> 
> Then perhaps the 'hack' to allow appending should be removed from the kernel,
> too, by the same logic - after all, its only 'enabling' people to cling to
> ancient bootloaders...

Absolutely.  But it is there now and that's the extent of what mainline 
is providing in terms of accommodation.

> Honestly, all the fuss about "R2 + ATAGS must be the only way", and now we can
> pass in data in non-ATAG form, via appending to the kernel image, at whatever
> random location that might wind up being.
> 
> Either ATAGs the only way, or they aren't. If appending to zImage is 'way 2'
> then it should be possible to choose what gets appended at build time. If not,
> the option has no business being in the kernel at all. Do it properly or not
> at all.

The "proper" way is to remove the DTB append option and force everyone 
to use a DT aware bootloader.  Are you ready for that?

Instead, we made a compromise which is to let you append a DTB to 
zImage.

> Whats the point in make uImage if you cant use it?

I advocated its removal for quite a long time now.  But it is still 
there which is also a compromise.  This way, people with ancient target 
which are not DT enabled aren't affected.


Nicolas

Device tree.

[Ian Molton]

On 18/07/12 14:42, Nicolas Pitre wrote

TL;DR: Summary

* make uImage is *broken* with CONFIG_ARM_APPENDED_DTB
* Trimmed down single-configuration kernels have merit. forcing
   .dtb to be passed from the bootloader
   - Increases bootloader complexity
     - and we know bootloaders suck and can be hard (if not impossible)
       to replace.
   - buys you nothing.
* Three other architectures support
   'make <image>.<embedded_dtb>'
* Old bootloaders cant always be replaced (ROM) or chainload (lack
   of flash) a newer one.
* No way to pass a .dtb address on the kernel commandline (where
   the bootloader cant pass it in a register, but can load arbitrary data
   into RAM, which most u-boot versions can.)

Conclusion:

There are three 'real' solutions, IMO.
1) Copy the other arches, and have make <image>.<embedded_dtb>
   - dtb could be properly embedded, linked into the kernel image.
   - makes for a consistent way of building images across more archs.
   - allows for simpler bootloaders.

2) Display a warning when building a uImage with
CONFIG_ARM_APPENDED_DTB, because that simply wont work the way
things are now.
   - Doesn't really fix anything, but at least it helps people see why
     its not working...

3) Add an option to specify the address of a .dtb file in RAM via
the kernel commandline.
  - removes the need for appending .dtb files to the kernel
  - still requires the bootloader to grok .dtb

 >> Yes, because this tactic has worked just great historically...
 >
 > It certainly did.  Look at the latest u-Boot which 1) has support
 > for device tree on ARM, and 2) has support to boot a zImage
 > directly. And some people were able to modify their old u-Boot as
 > well because of this policy.

I don't agree. u-boot has always been the weirdo that didnt just use a
zImage. Its taken *years* for that to change, and its not like uImages
were /ever/ easier to work with. I'd say the very presence of
'make uImage' slowed that change to a near halt.

 >> Other than chainbooting /another/ bootloader, how do you propose
 >> people fix this issue? Not everyone has a co-operative vendor.
 >
 > Ask your vendor harder.  They would care even less if the kernel was
 > more accommodating.

They don't care anyway - vendors never have. They just ship some
cruddy bootloader and let the clients fix it all up after its run. There are
more than a few boards out there that boot a u-boot from another
u-boot. Theres at least one that runs through *three* u-boots before
getting to a kernel...

 >> And for those of us where this is not an option?
 >
 > This is always an option to you.  You have the patch already, it
 > doesn't necessarily have to live in mainline.

I mean't *changing u-boot* is often not an option. Sometimes, neither
is chainbooting (limited flash).

 >> Which is all lovely, but sometimes simply not appropriate.
 >
 > Please deal with it.  Going the other way isn't appropriate for
 > mainline either.

Being able to make one zImage for lots of devices is a Good Thing.

Being able to pair an image down for just one device is *also* a
Good Thing.

**This isn't either/or**  In the 'one device' case, having the .dtb
appended can be useful. Having it passed in seperately is actually
fairly pointless, merely adding to the bootloader complexity.

Also, completely missing, AFAICT, is the option to pass the address
of a .dtb preloaded in RAM on the kernel commandline - which would
at least mean that people with crap u-boots could copy a .dtb to RAM
  and then point the kernel at it. (this was actually the first thing I 
tried,
until I realised that there is no option (that I can find) for that.)

 > Absolutely.  But it is there now and that's the extent of what
 > mainline is providing in terms of accommodation.

I really don't see why. We're talking about a couple of lines of patch.
If you're going to allow appending at all, you might as well let people
specify the file to append...

The way it is now, building uImages with 'make uImage' is
*actually broken*, if you want an appended DT.

 >> Whats the point in make uImage if you cant use it?
 >
 > I advocated its removal for quite a long time now.  But it is still
 > there which is also a compromise.  This way, people with ancient
 > target which are not DT enabled aren't affected.

What about those of us with a DT target and a crap bootloader? Or
Those who want a one-device image?

DT wont magically make drivers available for some other device, no
matter how hard you describe them in the .dts file, so 'one device'
images are still going to be pretty useless in the case of someone
trying to boot some other board with them.

If zImage is the one true way, thats fine - and I actually would prefer
that, I think uImages are stupid.

But - since its not the only way, it'd be sensible if the 'other way'
actually worked, or was officially made an out of tree option (thus
making it work again because you can concat. the .dtb file prior to
making the uImage.)

Device tree.

[Nicolas Pitre]

On Thu, 19 Jul 2012, Ian Molton wrote:

> On 18/07/12 14:42, Nicolas Pitre wrote
> 
> TL;DR: Summary
> 
> * make uImage is *broken* with CONFIG_ARM_APPENDED_DTB

Why do you say so?

In my own opinion, make uImage is broken, period.  But that is not the 
topic here.

> * Trimmed down single-configuration kernels have merit. forcing
>   .dtb to be passed from the bootloader
>   - Increases bootloader complexity
>     - and we know bootloaders suck and can be hard (if not impossible)
>       to replace.
>   - buys you nothing.

Hence CONFIG_ARM_APPENDED_DTB.

> * Three other architectures support
>   'make <image>.<embedded_dtb>'

If this is a generically useful feature, then something generic should 
be done about it instead. Duplicating the maintenance cost is silly.  
At least commit e339364514 moved things in the right direction for the 
uImage flavours.

> * Old bootloaders cant always be replaced (ROM) or chainload (lack
>   of flash) a newer one.

Hence CONFIG_ARM_APPENDED_DTB.  And don't tell me that you have u-Boot 
in ROM, in which case uImage shouldn't matter.

> * No way to pass a .dtb address on the kernel commandline (where
>   the bootloader cant pass it in a register, but can load arbitrary data
>   into RAM, which most u-boot versions can.)

That could be a nice compromize as an alternative to 
CONFIG_ARM_ATAG_DTB_COMPAT.

> Conclusion:
> 
> There are three 'real' solutions, IMO.
> 1) Copy the other arches, and have make <image>.<embedded_dtb>
>   - dtb could be properly embedded, linked into the kernel image.
>   - makes for a consistent way of building images across more archs.
>   - allows for simpler bootloaders.

If you want a consistent way, make that generic and not duplicated per 
architecture.

> 2) Display a warning when building a uImage with
> CONFIG_ARM_APPENDED_DTB, because that simply wont work the way
> things are now.
>   - Doesn't really fix anything, but at least it helps people see why
>     its not working...

Agreed.

> 3) Add an option to specify the address of a .dtb file in RAM via
> the kernel commandline.
>  - removes the need for appending .dtb files to the kernel
>  - still requires the bootloader to grok .dtb

See above.

> >> Yes, because this tactic has worked just great historically...
> >
> > It certainly did.  Look at the latest u-Boot which 1) has support
> > for device tree on ARM, and 2) has support to boot a zImage
> > directly. And some people were able to modify their old u-Boot as
> > well because of this policy.
> 
> I don't agree. u-boot has always been the weirdo that didnt just use a
> zImage. Its taken *years* for that to change, and its not like uImages
> were /ever/ easier to work with. I'd say the very presence of
> 'make uImage' slowed that change to a near halt.

Cheers!  

The uImage format also has other obnoxious limitations such as the 
absolute load address encoded into it.  This prevents a kernel built to 
run on multiple devices with different RAM offsets to be used on all of 
them.  This might have changed recently, but the old u-Boot installation 
base remains.

> >> Other than chainbooting /another/ bootloader, how do you propose
> >> people fix this issue? Not everyone has a co-operative vendor.
> >
> > Ask your vendor harder.  They would care even less if the kernel was
> > more accommodating.
> 
> They don't care anyway - vendors never have. They just ship some
> cruddy bootloader and let the clients fix it all up after its run. There are
> more than a few boards out there that boot a u-boot from another
> u-boot. Theres at least one that runs through *three* u-boots before
> getting to a kernel...

Hopefully the latest one could be updated to a recent one?

> >> And for those of us where this is not an option?
> >
> > This is always an option to you.  You have the patch already, it
> > doesn't necessarily have to live in mainline.
> 
> I mean't *changing u-boot* is often not an option. Sometimes, neither
> is chainbooting (limited flash).

Limited flash rules out u-Boot, right?

> >> Which is all lovely, but sometimes simply not appropriate.
> >
> > Please deal with it.  Going the other way isn't appropriate for
> > mainline either.
> 
> Being able to make one zImage for lots of devices is a Good Thing.
> 
> Being able to pair an image down for just one device is *also* a
> Good Thing.
> 
> **This isn't either/or**  In the 'one device' case, having the .dtb
> appended can be useful. Having it passed in seperately is actually
> fairly pointless, merely adding to the bootloader complexity.

It is not pointless if you think about Linux distributions.  They want a 
single kernel binary that can run anywhere and that they can update as 
often they want, while the DTB should be tied to each different device, 
ideally produced by the device vendor and shipped with the device.  
That could even allow yet to be produced devices to boot existing 
distributions, just like on x86.

That may not be applicable to you if your u-Boot only accommodates 
uImage which are already fixed to a particular memory address and 
therefore can't accept a universal zImage.  But short of not having a 
single 'make <image>.<embedded_dtb' command, you can still do

	make zImage
	cat your_board.dtb >> arch/arm/boot/zImage
	make uImage

or make the last 2 commands into the kernel _installation_ procedure for 
your board, running mkimage directly instead of using 'make uImage'.

Because 'make uImage' is really impairing progress here.  The kernel is 
already physical address agnostic i.e. it can be loaded anywhere and 
it'll figure out at run time what the actual physical memory location 
is.  We are trying to get rid of such knowledge as fixed physical 
addresses in the kernel and right now the only thing that prevents that 
is mkimage's _need_ for one.

> Also, completely missing, AFAICT, is the option to pass the address
> of a .dtb preloaded in RAM on the kernel commandline - which would
> at least mean that people with crap u-boots could copy a .dtb to RAM
>  and then point the kernel at it. (this was actually the first thing I tried,
> until I realised that there is no option (that I can find) for that.)

If only u-Boot would have let you set that address into the r2 register 
before booting the kernel this would have worked just fine.

[...]
> If zImage is the one true way, thats fine - and I actually would prefer
> that, I think uImages are stupid.
> 
> But - since its not the only way, it'd be sensible if the 'other way'
> actually worked, or was officially made an out of tree option (thus
> making it work again because you can concat. the .dtb file prior to
> making the uImage.)

Isn't that what I just showed above?


Nicolas

Device tree.

[Mark Brown]

On Thu, Jul 19, 2012 at 05:32:09PM -0400, Nicolas Pitre wrote:
> On Thu, 19 Jul 2012, Ian Molton wrote:

> > * Old bootloaders cant always be replaced (ROM) or chainload (lack
> >   of flash) a newer one.

> Hence CONFIG_ARM_APPENDED_DTB.  And don't tell me that you have u-Boot 
> in ROM, in which case uImage shouldn't matter.

For most of the boards I have it doesn't matter that the bootloader is
in flash, there's no way I'm going to risk bricking the board by trying
to replace the bootloader as I've got no way to recover the board if the
bootloader fails.  There's also the fact that if the bootloader supplies
the DT it can't boot kernels that don't understand DT as the machine ID
is changed (which isn't enormously helpful).

> > If zImage is the one true way, thats fine - and I actually would prefer
> > that, I think uImages are stupid.

> > But - since its not the only way, it'd be sensible if the 'other way'
> > actually worked, or was officially made an out of tree option (thus
> > making it work again because you can concat. the .dtb file prior to
> > making the uImage.)

> Isn't that what I just showed above?

It's possible to work with it, but then it's not clear to me why we have
CONFIG_ARM_APPENDED_DTB at all since pretty much the same thing applies
to non-DT cases.