ARM: add dtbImage.<dt> and dtbuImage.<dt> rules

This rules are useful for appended device tree conforming to the CONFIG_ARM_APPENDED_DTB kernel option.

The rule dtbImage.<dt> is actually just a:
cat zImage <dt>.dtb > dtbImage.<dt>

The dtbuImage.<dt> makes an uImage out of the dtbImage.<dt> file.

KernelVersion: v3.6-rc5

Signed-off-by Richard Genoud <[email protected]>

---
 arch/arm/Makefile      |   30 ++++++++++++++++--------------
 arch/arm/boot/Makefile |   11 +++++++++++
 scripts/Makefile.lib   |    6 ++++++
 3 files changed, 33 insertions(+), 14 deletions(-)

arch/arm/Makefile +16 -14

index 30eae87..c5f2673 100644
@@ -278,7 +278,7 @@ archprepare:
 # Convert bzImage to zImage
 bzImage: zImage
 
-zImage Image xipImage bootpImage uImage: vmlinux
+zImage Image xipImage bootpImage uImage dtbImage.% dtbuImage.% : vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
 
 zinstall uinstall install: vmlinux

@@ -300,17 +300,19 @@ i zi:;	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
 
 define archhelp
-  echo  '* zImage        - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
-  echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
-  echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
-  echo  '  uImage        - U-Boot wrapped zImage'
-  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
-  echo  '                  (supply initrd image via make variable INITRD=<path>)'
-  echo  '  dtbs          - Build device tree blobs for enabled boards'
-  echo  '  install       - Install uncompressed kernel'
-  echo  '  zinstall      - Install compressed kernel'
-  echo  '  uinstall      - Install U-Boot wrapped compressed kernel'
-  echo  '                  Install using (your) ~/bin/$(INSTALLKERNEL) or'
-  echo  '                  (distribution) /sbin/$(INSTALLKERNEL) or'
-  echo  '                  install to $$(INSTALL_PATH) and run lilo'
+  echo  '* zImage         - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
+  echo  '  Image          - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
+  echo  '* xipImage       - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
+  echo  '  uImage         - U-Boot wrapped zImage'
+  echo  '  bootpImage     - Combined zImage and initial RAM disk'
+  echo  '                   (supply initrd image via make variable INITRD=<path>)'
+  echo  '  dtbs           - Build device tree blobs for enabled boards'
+  echo  '  dtbImage.<dt>  - zImage with an appended device tree blob'
+  echo  '  dtbuImage.<dt> - uImage with an embedded device tree blob'
+  echo  '  install        - Install uncompressed kernel'
+  echo  '  zinstall       - Install compressed kernel'
+  echo  '  uinstall       - Install U-Boot wrapped compressed kernel'
+  echo  '                   Install using (your) ~/bin/$(INSTALLKERNEL) or'
+  echo  '                   (distribution) /sbin/$(INSTALLKERNEL) or'
+  echo  '                   install to $$(INSTALL_PATH) and run lilo'
 endef

arch/arm/boot/Makefile +11 -0

index c877087..35c01a8 100644
@@ -98,6 +98,17 @@ $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
 	$(call if_changed,objcopy)
 	@echo '  Kernel: $@ is ready'
 
+# dtbImage.% - a dtbImage is a zImage with an appended device tree blob
+$(obj)/dtbImage.%: $(obj)/zImage $(obj)/%.dtb FORCE
+	$(call if_changed,cat)
+	@echo '  Kernel: $@ is ready'
+
+# dtbuImage.% - a dtbuImage is a uImage with an embedded device tree blob
+$(obj)/dtbuImage.%: $(obj)/dtbImage.% FORCE
+	@$(check_for_multiple_loadaddr)
+	$(call if_changed,uimage)
+	@echo '  Image $@ is ready'
+
 PHONY += initrd FORCE
 initrd:
 	@test "$(INITRD_PHYS)" != "" || \

scripts/Makefile.lib +6 -0

index 0be6f11..8550466 100644
@@ -235,6 +235,12 @@ cmd_ld = $(LD) $(LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F)) \
 quiet_cmd_objcopy = OBJCOPY $@
 cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
 
+# Cat
+# ---------------------------------------------------------------------------
+
+quiet_cmd_cat = CAT     $@
+cmd_cat = (cat $(filter-out FORCE,$^) > $@) || (rm -f $@ ; false)
+
 # Gzip
 # ---------------------------------------------------------------------------
 

[add Grant Likely and Rob Herring in To: since this is maybe more OF related than ARM related]

This rules are useful for appended device tree conforming to the CONFIG_ARM_APPENDED_DTB kernel option.

The rule dtbImage.<dt> is actually just a:
cat zImage <dt>.dtb > dtbImage.<dt>

The dtbuImage.<dt> makes an uImage out of the dtbImage.<dt> file.

KernelVersion: v3.6-rc5

Signed-off-by Richard Genoud <[email protected]>

Tested-by Gregory CLEMENT <[email protected]>

Quoted 2 lines

Signed-off-by Richard Genoud <[email protected]>

Tested-by Gregory CLEMENT <[email protected]>

as discuss with Grant no this is a temporary solution so no Makefile Target

so nack

2012/9/27 Jean-Christophe PLAGNIOL-VILLARD <[email protected]>:

Quoted 5 lines

Quoted 2 lines

Signed-off-by Richard Genoud <[email protected]>

Tested-by Gregory CLEMENT <[email protected]>

as discuss with Grant no this is a temporary solution so no Makefile Target

so nack

hum, it doesn't seems to be temporary on powerpc.
cf 25431333813686654907ab987fb5de10c10a16db
and
ARCH=powerpc make help

So what's the problem on arm ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

We're in the position where we'd like to have FDT support just because it simplifies our code a whole lot;

yet we want to be able to run such a kernel on older u-boots (completely unaware of FTDs) as well.
I believe this must be a very common use case indeed.

So a dtbuImage.<dtb> would be very useful in this case.

If I understand it correctly, dtbImage.<dtb> is indeed just a cat of zImage+dtb, whereas dtbuImage.<dtb> is the uimage of such a dtbImage.<dtb>.

So it shouldn't be such a crazy idea to create a dtbuImage.<dtb> within Kbuild (as opposed to from an external wrapper for make).

Is there any reason why nothing like that was ever mainlined? Or maybe I'm just missing something?

Quoted 2 lines · Gerlando Falauto

So it shouldn't be such a crazy idea to create a dtbuImage.<dtb> within Kbuild (as opposed to from an external wrapper for make).

Yes :) The problem is that we are moving to multiplatform zImages. In that scenario, the uImage target isn't very helpful because it needs to be custom to each board. Additionally, appended-dtb was intended as a developer tool and isn't intended as a deployable item. It also defeats the purpose of multiplatform.

Modern platforms
should be using a DT compatible boot loader, which means you don't want to use the DTB appended to zImage method.

2013/9/24 Russell King - ARM Linux <[email protected]>:

Quoted 3 lines

Modern platforms
should be using a DT compatible boot loader, which means you don't want to use the DTB appended to zImage method.

Even small bootloaders like at91bootstrap can handle DT blob now (that was my main problem at the time I wrote this patch)
So I don't use it anymore. (but as a developer tool, this can be convenient).

Richard.

Quoted 9 lines · Jason Cooper

Quoted 2 lines · Gerlando Falauto

So it shouldn't be such a crazy idea to create a dtbuImage.<dtb> within Kbuild (as opposed to from an external wrapper for make).

Yes :) The problem is that we are moving to multiplatform zImages. In that scenario, the uImage target isn't very helpful because it needs to be custom to each board. Additionally, appended-dtb was intended as a developer tool and isn't intended as a deployable item. It also defeats the purpose of multiplatform.

And we've already taken the decision that we will not be augmenting kbuild with any more ubooot specific stuff, especially with anything that goes against the long term goal of having a single kernel image which is bootable across multiple platforms.

Having kbuild wrap the zImage + DTB up into a uImage goes directly against this goal, because it turns the produced kernel into something which is specific to a single target. It's much worse than what we had before we went to DT, because with this it can only be used on a _single_ target, whereas prior to DT we could boot a single kernel on a variety of compatible targets.

Moreover, the support for appending the DTB to the zImage is a stop-gap solution for the transition to a full DT based environment - don't expect it to be around into the long term future. Modern platforms should be using a DT compatible boot loader, which means you don't want to use the DTB appended to zImage method.

Quoted 23 lines · Russell King - ARM Linux

Quoted 9 lines · Jason Cooper

Quoted 2 lines · Gerlando Falauto

So it shouldn't be such a crazy idea to create a dtbuImage.<dtb> within Kbuild (as opposed to from an external wrapper for make).

Yes :) The problem is that we are moving to multiplatform zImages. In that scenario, the uImage target isn't very helpful because it needs to be custom to each board. Additionally, appended-dtb was intended as a developer tool and isn't intended as a deployable item. It also defeats the purpose of multiplatform.

And we've already taken the decision that we will not be augmenting kbuild with any more ubooot specific stuff, especially with anything that goes against the long term goal of having a single kernel image which is bootable across multiple platforms.

Having kbuild wrap the zImage + DTB up into a uImage goes directly against this goal, because it turns the produced kernel into something which is specific to a single target. It's much worse than what we had before we went to DT, because with this it can only be used on a _single_ target, whereas prior to DT we could boot a single kernel on a variety of compatible targets.

Quoted 6 lines

Moreover, the support for appending the DTB to the zImage is a stop-gap solution for the transition to a full DT based environment - don't expect it to be around into the long term future. Modern platforms should be using a DT compatible boot loader, which means you don't want to use the DTB appended to zImage method.

What is the long-term mechanism/methodology for creating a kernel that runs on a single system? So many drivers now have device-tree dependencies that it seems unlikely we'll be able to avoid using device tree. But if we don't care or don't want to support more than a single platform, what should we do (if appending DTB to the zImage will eventually go away). Will the requirement be that all future Linux bootloaders will be DT-aware?

I don't think appended DTB will go away. In fact, use of it is now being added to flash-kernel in debian/ubuntu. However, this is only done at OS install time on running on the h/w.

What is the long-term mechanism/methodology for creating a kernel that runs on a single system? So many drivers now have device-tree dependencies that it seems unlikely we'll be able to avoid using device tree. But if we don't care or don't want to support more than a single platform, what should we do (if appending DTB to the zImage will eventually go away). Will the requirement be that all future Linux bootloaders will be DT-aware?

Having kbuild wrap the zImage + DTB up into a uImage goes directly against this goal, because it turns the produced kernel into something which is specific to a single target. It's much worse than what we had before we went to DT, because with this it can only be used on a _single_ target, whereas prior to DT we could boot a single kernel on a variety of compatible targets.

Quoted 6 lines · Russell King - ARM Linux

Having kbuild wrap the zImage + DTB up into a uImage goes directly against this goal, because it turns the produced kernel into something which is specific to a single target. It's much worse than what we had before we went to DT, because with this it can only be used on a _single_ target, whereas prior to DT we could boot a single kernel on a variety of compatible targets.

What would you think of a patch allowing multiple DTB selected using ATAG number ?

Nicolas Pitre already suggested an impedance matcher that keeps this kind of hacky code out of the kernel, and allows users to do exactly

Quoted 2 lines · Jason Cooper

Nicolas Pitre already suggested an impedance matcher that keeps this kind of hacky code out of the kernel, and allows users to do exactly

I know that, my proposal was to bring this back into the kernel.

That "kind of hacky" ATAG thing was actually the only supported way to boot a platform not so long ago :)

In the end, people needing the impedance matcher will somehow integrate it in the kernel build system anyway.

Quoted 2 lines

That "kind of hacky" ATAG thing was actually the only supported way to boot a platform not so long ago :)

Strictly speaking, this was never supported in mainline.

The ultimate idea with the impedance matcher was to augment existing bootloaders with sort of a semi second stage bootloader that would be separate from zImage and installed permanently, and then only the zImage itself would be updateable. This way you'd get a DT capable environment without replacing the actual bootloader.

Quoted 4 lines · Nicolas Pitre

Quoted 2 lines

That "kind of hacky" ATAG thing was actually the only supported way to boot a platform not so long ago :)

Strictly speaking, this was never supported in mainline.

Quoted 5 lines

The ultimate idea with the impedance matcher was to augment existing bootloaders with sort of a semi second stage bootloader that would be separate from zImage and installed permanently, and then only the zImage itself would be updateable. This way you'd get a DT capable environment without replacing the actual bootloader.

That's true if you have access to the bootloader in some way (serial, flash env).

But for devices in the field for which upgrading the booloader is not an option, neither is changing anything else in the boot process (anything before linux starts). The risk of bricking the device is just too high.

But for devices in the field for which upgrading the booloader is not an option, neither is changing anything else in the boot process (anything before linux starts). The risk of bricking the device is just too high.

Gerlando,

We are strongly encouraging all vendors to upgrade their bootloaders to support field upgradeable dtbs. eg having the dtb on a separate partition of the flash (or whereever the bootloader environment is)

iirc, keymile is using an odd flavor of Kirkwood.

Have you tried kwboot over serial? It can be found in barebox and u-boot source repositories.

The above is the long-term goal, in the short term, please take a look at:

https://github.com/zonque/pxa-impedance-matcher

You can use this to boot a modern fdt kernel on a legacy bootloader, with one or more dtb's linked in. I tested it on the dreamplug, so it's mostly there for you.

The big outstanding TODO I have on it is to parse the atags and modify the selected dtb before passing off to the kernel. Patches welcome! :)

hth,

Quoted 3 lines · Jason Cooper

We are strongly encouraging all vendors to upgrade their bootloaders to support field upgradeable dtbs. eg having the dtb on a separate partition of the flash (or whereever the bootloader environment is)

This will most definitely be the case for future boards, but we sort of follow the unspoken guideline of not upgrading u-boot on field-deployed units. Arguable at least, but that's the way it is.

Quoted 1 line

Have you tried kwboot over serial? It can be found in barebox and u-boot source repositories.

Uhm, yes, I've used it a few times... but what are you suggesting? That u-boot can be upgraded? Yes, I believe that... ;-)

Quoted 9 lines

The above is the long-term goal, in the short term, please take a look at:

https://github.com/zonque/pxa-impedance-matcher

You can use this to boot a modern fdt kernel on a legacy bootloader, with one or more dtb's linked in. I tested it on the dreamplug, so it's mostly there for you.

Quoted 2 lines

The big outstanding TODO I have on it is to parse the atags and modify the selected dtb before passing off to the kernel. Patches welcome! :)

Thank you, I had a quick look at the README and it sounds great! But CONFIG_APPENDED_DTB already does the job of filling this gap for me...