| Message ID | 1348733441-11626-1-git-send-email-richard.genoud@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10:10 Thu 27 Sep , Richard Genoud wrote: > [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 <richard.genoud@gmail.com> > Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> as discuss with Grant no this is a temporary solution so no Makefile Target so nack Best Regards, J.
2012/9/27 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>: >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> > 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 ?
Hi everyone, apologies for picking up a topic that's more than 360 days old... 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? Thanks! Gerlando On 09/27/2012 11:08 AM, Richard Genoud wrote: > 2012/9/27 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>: >>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >>> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> >> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Gerlando, On Tue, Sep 24, 2013 at 12:55:19PM +0200, Gerlando Falauto wrote: > We're in the position where we'd like to have FDT support just > because it simplifies our code a whole lot; Great! > 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. Yes, very much so. With the understanding that this is an artifact of the transition, hopefully not a permanent state. ;-) > So a dtbuImage.<dtb> would be very useful in this case. well... > 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>. Yes. > 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. > Is there any reason why nothing like that was ever mainlined? > Or maybe I'm just missing something? 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, Jason.
On Tue, Sep 24, 2013 at 08:01:52AM -0400, Jason Cooper wrote: > On Tue, Sep 24, 2013 at 12:55:19PM +0200, Gerlando Falauto wrote: > > 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.
2013/9/24 Russell King - ARM Linux <linux@arm.linux.org.uk>: > 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.
Hi Jason, On 09/24/2013 02:01 PM, Jason Cooper wrote: > 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) 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. > iirc, keymile is using an odd flavor of Kirkwood. Correct, it's a kirkwood + a switch on the same die. > 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... ;-) > 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! :) 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... > > hth, It sure did. I really appreciate it. Thanks!!! Gerlando
Hi guys, On 09/24/2013 02:34 PM, Richard Genoud wrote: > 2013/9/24 Russell King - ARM Linux <linux@arm.linux.org.uk>: >> 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. > Thanks a lot for your replies. I now understand your point, your reasons and, most importantly, where we're headed and what to expect in the future. Thanks a lot! Gerlando
On Tue, Sep 24, 2013 at 05:14:26PM +0200, Gerlando Falauto wrote: > On 09/24/2013 02:01 PM, Jason Cooper wrote: > >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. Understandable. > >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... ;-) I'm suggesting that I primarily talk to hobbyists and tinkerers, and occasionally forget there are people that have jtag access :-P > >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! :) > > 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... Right, it's intended as a replacement for APPENDED_DTB since it can handle multiple dtbs (so you can do one multiplatform zImage), and you can hack around custom vendor atags. eg ethernet mac addresses, Thomas' CP15 register base address hack, etc. All that goodness without polluting the kernel source. :) thx, Jason.
On Tue, Sep 24, 2013 at 5:19 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Sep 24, 2013 at 08:01:52AM -0400, Jason Cooper wrote: >> On Tue, Sep 24, 2013 at 12:55:19PM +0200, Gerlando Falauto wrote: >> > 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. > 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? -- Tim Bird Senior Software Engineer, Sony Mobile Architecture Group Chair, CE Workgroup, Linux Foundation
On Tue, 2013-09-24 at 13:19 +0100, Russell King - ARM Linux wrote: Hi Russell, > > 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 ? I don't believe telling people to upgrade bootloaders in the field is a reasonable thing to ask. We can make fun of vendors for leaving devices with outdated kernel versions, but this is making life harder for the one who played by the rules.
On Mon, Sep 30, 2013 at 10:21:23PM +0200, Maxime Bizon wrote: > On Tue, 2013-09-24 at 13:19 +0100, Russell King - ARM Linux wrote: > > 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 that. Daniel Mack took him up on the suggestion and implemented it [1]. I contributed some patches to make it work generically. Please take a look. Currently, the only outstanding blocker is to convert atags to fdt. Patches welcome as I'm currently occupied with other things. ;-) hth, Jason. [1] https://github.com/zonque/pxa-impedance-matcher
On Mon, 2013-09-30 at 16:42 -0400, Jason Cooper wrote: > 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.
On Mon, Sep 30, 2013 at 1:14 PM, Tim Bird <tbird20d@gmail.com> wrote: > On Tue, Sep 24, 2013 at 5:19 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Tue, Sep 24, 2013 at 08:01:52AM -0400, Jason Cooper wrote: >>> On Tue, Sep 24, 2013 at 12:55:19PM +0200, Gerlando Falauto wrote: >>> > 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. >> > > 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. The problem goes beyond just having a DT aware bootloader. You also need the bootloader to ship with the DTB. This isn't happening yet, so the distros are having to install their own DTB. Since there is not a standard way to install a dtb and tell the bootloader where it is, the appended dtb is the quick solution. Rob
On Mon, 30 Sep 2013, Tim Bird wrote: > 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? The ability to append a DTB to zImage is not going away tomorrow, although I encourage you to use another solution if possible. What can be done on a simple single platform setup is to load the DTB from flash into RAM just like another blob along with the ramdisk image and the zImage itself. Then you just have to branch into zImage with the address of the DTB in RAM into r2. Most bootloaders are able to load arbitrary binaries into memory, and most bootloaders (except for U-Boot) are able to set arbitrary values into r0-r3 before branching to some location in memory. Nicolas
On Mon, 30 Sep 2013, Maxime Bizon wrote: > > On Mon, 2013-09-30 at 16:42 -0400, Jason Cooper wrote: > > > 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. And obviously I disagree with such a proposal. > 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. > In the end, people needing the impedance matcher will somehow integrate > it in the kernel build system anyway. As long as it remains their own cost to maintain then nobody will object, which means "not 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. Nicolas
On Mon, 30 Sep 2013, Rob Herring wrote: > 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. Excellent! That is exactly the use case this feature was designed for. Otherwise we would simply have linked the DTB into the kernel image directly. Appending a DTB to zImage should be done at kernel installation time, not at build time. The nuance might not mean a lot for some environment, but for a distro this is clearly separate operations. Nicolas
On Monday 30 Sep 2013 à 23:14:49 (-0400), Nicolas Pitre wrote: > > 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. I meant mach-type, which was ofc documented http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm/Booting?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > 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. Now of course we have the capability to support these devices ourselves, I just find it harsh that having "designed" that boot process in 2010, we are told 3 years later that it is obsolete and won't be able to boot a recent kernel (we support two machines with one kernel image, appended DTB cannot handle that). If I were redesigning that product now, would I use a DT aware bootloader ? you'd tell me "yes go for it", but hey, you broke my build, can I trust you ? :)
On Tue, Oct 01, 2013 at 12:41:15PM +0200, Maxime Bizon wrote: > On Monday 30 Sep 2013 à 23:14:49 (-0400), Nicolas Pitre wrote: > > > > 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. I was referring to the non-approved atags many vendors arbitrarily added to their bootloaders and kernels. Ethernet mac addresses, etc. It's not proper to go cluttering the kernel with every hair-brained, one-off tag a board vendor came up with to ship a product. > > 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. This is the exact scenario we are solving with the impedance matcher. It's a wrapper around a kernel and a series of dtbs. To the bootloader, it looks _exactly_ like the kernel, but it translates the info passed to it into terms newer kernels can understand. No need for a separate binary. hth, Jason.
On Tue, Oct 01, 2013 at 12:41:15PM +0200, Maxime Bizon wrote: > 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. Well, how does the kernel get on to these devices in the field? Is it burned into the flash using some laser type device, or does it involve running some kind of a script? If it's running a script, then that script can be modified. The script can take the generic zImage, and it can identify what the target hardware is, and it can pick the appropriate DT image to append to the kernel and then create whatever format your target uboot wants (whether that be the new format or the uImage format.) I'm not sure why people think this is soo difficult. I've had my build/ boot system doing that since OMAP4 went DT only. I'm now using it on the Cubox-i Carrier-1 board. I'm doing it manually there - concatenating the kernel and DTB and then using mkimage. If you really must have all the DT blobs as part of the kernel and select one at boot time, that's precisely where having the kind of solution Nicolas is suggesting comes in. We can't keep augmenting the kernel build system with every different magic way to generate the final platform image - it's got to the point where there are just _far_ too many different options and to keep adding more and more is getting really stupid. Remember too that the plan is to drop the DT files from the kernel tarball and maintain them in a separate _external_ tree to the kernel. This means that any "solution" we merge today which allows you to build a "final platform image" out of a DT file plus the zImage will only need to be removed again when that happens. It's far better not to encourage these lazy methods which will only end up causing us kernel developers more pain in the future.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 30eae87..c5f2673 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -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 diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index c877087..35c01a8 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -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)" != "" || \ diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 0be6f11..8550466 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -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 # ---------------------------------------------------------------------------