Device tree.

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

Le Tue, 17 Jul 2012 12:55:53 +0100,
Ian Molton <[email protected]> a ?crit :

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

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

Le Tue, 17 Jul 2012 13:13:03 +0100,
Ian Molton <[email protected]> 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.

Thomas

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

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

Le Tue, 17 Jul 2012 14:41:35 +0200,
Florian Fainelli <[email protected]> a ?crit :

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

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

Yick...

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

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

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

I suppose we can produce our own build-script

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

Ben

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

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

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

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.

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

Which is all lovely, but sometimes simply not appropriate.

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?

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.

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

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

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

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

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.

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

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

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.

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...

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

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.)

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.

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.)

Why do you say so?

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

Hence CONFIG_ARM_APPENDED_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.

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

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

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

Agreed.

See above.

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.

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

Limited flash rules out u-Boot, right?

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.

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.

[...]

Isn't that what I just showed above?

Nicolas

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).

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.

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.