zImage improvements with DTB append and ATAG compatibility
cover zImage improvements with DTB append and ATAG compatibility
This is the latest incarnation of my patch series allowing a DTB to be appended to zImage, including the ATAG conversion wrapper and other minor cleanups.
This can also be pulled from:
git://git.linaro.org/people/nico/linux zImage_DTB_append
This works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
Nicolas
PATCH 1/6 ARM: zImage: ensure it is always a multiple of 64 bits in size
From: Nicolas Pitre <[email protected]>
This is needed for proper alignment when the DTB appending feature is used.
--- arch/arm/boot/compressed/vmlinux.lds.in | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/boot/compressed/vmlinux.lds.in +4 -0
@@ -51,6 +51,10 @@ SECTIONS _got_start = .; .got : { *(.got) } _got_end = .; + + /* ensure the zImage file size is always a multiple of 64 bits */ + /* (without a dummy byte, ld just ignores the empty section) */ + .pad : { BYTE(0); . = ALIGN(8); } _edata = .; . = BSS_START;
Signature · 1 line
1.7.7-rc0
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
In reply to Nicolas PitreFrom: Nicolas Pitre <[email protected]>
This patch provides the ability to boot using a device tree that is appended to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
--- arch/arm/Kconfig | 8 ++++ arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 3 deletions(-)
arch/arm/Kconfig +8 -0
@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI endchoice +config ARM_APPENDED_DTB + bool "Use appended device tree blob to zImage" + depends on OF && !ZBOOT_ROM + help + With this option, the boot code will look for a device tree binary + (dtb) appended to zImage + (e.g. cat zImage <filename>.dtb > zImage_w_dtb). + config CMDLINE string "Default kernel command string" default ""
arch/arm/boot/compressed/head.S +67 -3
99 lines not on this page · raw message
Signature · 1 line
1.7.7-rc0
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
Quoted 59 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
This patch provides the ability to boot using a device tree that is appended to the raw binary zImage (e.g. cat zImage <filename>.dtb >
zImage_w_dtb).Signed-off-by John Bonesio <[email protected]>[nico: adjusted to latest zImage changes plus additional cleanups]Signed-off-by Nicolas Pitre <[email protected]>Acked-by Grant Likely <[email protected]>Acked-by Tony Lindgren <[email protected]>--- arch/arm/Kconfig | 8 ++++ arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 3 deletions(-)arch/arm/Kconfig +8
-0@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI endchoice +config ARM_APPENDED_DTB + bool "Use appended device tree blob to zImage" + depends on OF && !ZBOOT_ROM + help + With this option, the boot code will look for a device tree binary + (dtb) appended to zImage + (e.g. cat zImage <filename>.dtb > zImage_w_dtb). + config CMDLINE string "Default kernel command string" default ""arch/arm/boot/compressed/head.S +17
-0@@ -216,6 +216,59 @@ restart: adr r0, LC0 mov r10, r6 #endif + mov r5, #0 @ init dtb size to 0 +#ifdef CONFIG_ARM_APPENDED_DTB +/* + * r0 = delta + * r2 = BSS start + * r3 = BSS end + * r4 = final kernel address + * r5 = appended dtb size (still unknown) + * r6 = _edata + * r7 = architecture ID + * r8 = atags/device tree pointer + * r9 = size of decompressed image + * r10 = end of this image, including bss/stack/malloc space if non XIP + * r11 = GOT start + * r12 = GOT end + * sp = stack pointer + *
arch/arm/boot/compressed/head.S restart: adr r0, LC0 · line 245
Quoted 10 lines
arch/arm/boot/compressed/head.S +10
-0+ * if there are device trees (dtb) appended to zImage, advance r10 so that the + * dtb data will get relocated along with the kernel if necessary. + */ + + ldr lr, [r6, #0] +#ifndef __ARMEB__ + ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian +#else + ldr r1, =0xd00dfeed +#endif
Do we worry that garbage in memory after the zImage might match this magic number?
For example, if an ordinary userspace program allocates a huge number of pages and fills them with bogus device tree headers, is there a chance that the those headers could remain in memory across a reboot?
In principle this could lead to a security hole on platforms where the boot images don't append a device tree, by allowing an attacker to override the bootargs etc.
I don't know whether this is exploitable in practice, but it's worth thinking about (apologies if it's already been discussed)
A possible workaround is to put a relative pointer or a flag at the start of the zImage, which we can poke with a non-zero value when the device tree is appended.
This makes appending the device tree non-trivial, but it's still pretty simple to do; something like:
$ echo 'boo' | dd bs=4 count=1 seek=4 conv=notrunc of=zImage $ cat dtb >>zImage
(Where I assume that the affected word in the zImage is initially not 'boo').
Cheers
---Dave
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
Quoted 74 lines · Dave Martin
Quoted 59 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
This patch provides the ability to boot using a device tree that is appended to the raw binary zImage (e.g. cat zImage <filename>.dtb >
zImage_w_dtb).Signed-off-by John Bonesio <[email protected]>[nico: adjusted to latest zImage changes plus additional cleanups]Signed-off-by Nicolas Pitre <[email protected]>Acked-by Grant Likely <[email protected]>Acked-by Tony Lindgren <[email protected]>--- arch/arm/Kconfig | 8 ++++ arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 3 deletions(-)arch/arm/Kconfig +8
-0@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI endchoice +config ARM_APPENDED_DTB + bool "Use appended device tree blob to zImage" + depends on OF && !ZBOOT_ROM + help + With this option, the boot code will look for a device tree binary + (dtb) appended to zImage + (e.g. cat zImage <filename>.dtb > zImage_w_dtb). + config CMDLINE string "Default kernel command string" default ""arch/arm/boot/compressed/head.S +17
-0@@ -216,6 +216,59 @@ restart: adr r0, LC0 mov r10, r6 #endif + mov r5, #0 @ init dtb size to 0 +#ifdef CONFIG_ARM_APPENDED_DTB +/* + * r0 = delta + * r2 = BSS start + * r3 = BSS end + * r4 = final kernel address + * r5 = appended dtb size (still unknown) + * r6 = _edata + * r7 = architecture ID + * r8 = atags/device tree pointer + * r9 = size of decompressed image + * r10 = end of this image, including bss/stack/malloc space if non XIP + * r11 = GOT start + * r12 = GOT end + * sp = stack pointer + *arch/arm/boot/compressed/head.S restart: adr r0, LC0 · line 245
Quoted 10 lines
arch/arm/boot/compressed/head.S +10
-0+ * if there are device trees (dtb) appended to zImage, advance r10 so that the + * dtb data will get relocated along with the kernel if necessary. + */ + + ldr lr, [r6, #0] +#ifndef __ARMEB__ + ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian +#else + ldr r1, =0xd00dfeed +#endifDo we worry that garbage in memory after the zImage might match this magic number?
Quoted 3 lines
For example, if an ordinary userspace program allocates a huge number of pages and fills them with bogus device tree headers, is there a chance that the those headers could remain in memory across a reboot?
In theory this _could_ be possible. However I don't expect this feature to be enabled if you are not going to actually use it, especially in a production setup. If you are not appending a DTB to your kernel then there is simply no point keeping this config option set (normally you should use this option only because you have no other choices).
Nicolas
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
Quoted 80 lines · Nicolas Pitre
Quoted 74 lines · Dave Martin
Quoted 59 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
This patch provides the ability to boot using a device tree that is appended to the raw binary zImage (e.g. cat zImage <filename>.dtb >
zImage_w_dtb).Signed-off-by John Bonesio <[email protected]>[nico: adjusted to latest zImage changes plus additional cleanups]Signed-off-by Nicolas Pitre <[email protected]>Acked-by Grant Likely <[email protected]>Acked-by Tony Lindgren <[email protected]>--- arch/arm/Kconfig | 8 ++++ arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 3 deletions(-)arch/arm/Kconfig +8
-0@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI endchoice +config ARM_APPENDED_DTB + bool "Use appended device tree blob to zImage" + depends on OF && !ZBOOT_ROM + help + With this option, the boot code will look for a device tree binary + (dtb) appended to zImage + (e.g. cat zImage <filename>.dtb > zImage_w_dtb). + config CMDLINE string "Default kernel command string" default ""arch/arm/boot/compressed/head.S +17
-0@@ -216,6 +216,59 @@ restart: adr r0, LC0 mov r10, r6 #endif + mov r5, #0 @ init dtb size to 0 +#ifdef CONFIG_ARM_APPENDED_DTB +/* + * r0 = delta + * r2 = BSS start + * r3 = BSS end + * r4 = final kernel address + * r5 = appended dtb size (still unknown) + * r6 = _edata + * r7 = architecture ID + * r8 = atags/device tree pointer + * r9 = size of decompressed image + * r10 = end of this image, including bss/stack/malloc space if non XIP + * r11 = GOT start + * r12 = GOT end + * sp = stack pointer + *arch/arm/boot/compressed/head.S restart: adr r0, LC0 · line 245
Quoted 10 lines
arch/arm/boot/compressed/head.S +10
-0+ * if there are device trees (dtb) appended to zImage, advance r10 so that the + * dtb data will get relocated along with the kernel if necessary. + */ + + ldr lr, [r6, #0] +#ifndef __ARMEB__ + ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian +#else + ldr r1, =0xd00dfeed +#endifDo we worry that garbage in memory after the zImage might match this magic number?
Quoted 3 lines
For example, if an ordinary userspace program allocates a huge number of pages and fills them with bogus device tree headers, is there a chance that the those headers could remain in memory across a reboot?
Quoted 5 lines
In theory this _could_ be possible. However I don't expect this feature to be enabled if you are not going to actually use it, especially in a production setup. If you are not appending a DTB to your kernel then there is simply no point keeping this config option set (normally you should use this option only because you have no other choices).
That seems reasonable.
Should we document this recommendation, in the Kconfig help or Documentation/?
On the other hand, if there's any chance this might need to be fixed later, it could make sense to fix it now, particularly given that the fix is simple (based on the assumption that whatever is documented, people can and will sometimes do the wrong thing when deploying a platform...)
Anyway, I don't have a strong feeling on this myself.
Cheers
---Dave
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
Quoted 87 lines · Dave Martin
Quoted 80 lines · Nicolas Pitre
Quoted 74 lines · Dave Martin
Quoted 59 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
This patch provides the ability to boot using a device tree that is appended to the raw binary zImage (e.g. cat zImage <filename>.dtb >
zImage_w_dtb).Signed-off-by John Bonesio <[email protected]>[nico: adjusted to latest zImage changes plus additional cleanups]Signed-off-by Nicolas Pitre <[email protected]>Acked-by Grant Likely <[email protected]>Acked-by Tony Lindgren <[email protected]>--- arch/arm/Kconfig | 8 ++++ arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 3 deletions(-)arch/arm/Kconfig +8
-0@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI endchoice +config ARM_APPENDED_DTB + bool "Use appended device tree blob to zImage" + depends on OF && !ZBOOT_ROM + help + With this option, the boot code will look for a device tree binary + (dtb) appended to zImage + (e.g. cat zImage <filename>.dtb > zImage_w_dtb). + config CMDLINE string "Default kernel command string" default ""arch/arm/boot/compressed/head.S +17
-0@@ -216,6 +216,59 @@ restart: adr r0, LC0 mov r10, r6 #endif + mov r5, #0 @ init dtb size to 0 +#ifdef CONFIG_ARM_APPENDED_DTB +/* + * r0 = delta + * r2 = BSS start + * r3 = BSS end + * r4 = final kernel address + * r5 = appended dtb size (still unknown) + * r6 = _edata + * r7 = architecture ID + * r8 = atags/device tree pointer + * r9 = size of decompressed image + * r10 = end of this image, including bss/stack/malloc space if non XIP + * r11 = GOT start + * r12 = GOT end + * sp = stack pointer + *arch/arm/boot/compressed/head.S restart: adr r0, LC0 · line 245
Quoted 10 lines
arch/arm/boot/compressed/head.S +10
-0+ * if there are device trees (dtb) appended to zImage, advance r10 so that the + * dtb data will get relocated along with the kernel if necessary. + */ + + ldr lr, [r6, #0] +#ifndef __ARMEB__ + ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian +#else + ldr r1, =0xd00dfeed +#endifDo we worry that garbage in memory after the zImage might match this magic number?
Quoted 3 lines
For example, if an ordinary userspace program allocates a huge number of pages and fills them with bogus device tree headers, is there a chance that the those headers could remain in memory across a reboot?
Quoted 5 lines
In theory this _could_ be possible. However I don't expect this feature to be enabled if you are not going to actually use it, especially in a production setup. If you are not appending a DTB to your kernel then there is simply no point keeping this config option set (normally you should use this option only because you have no other choices).
Quoted 4 lines
That seems reasonable.
Should we document this recommendation, in the
Kconfighelp orDocumentation/?
I'll add some scary wording to the help text, and make it depend on EXPERIMENTAL as well. I prefer not to impose some expectations on the zImage layout for this even if not in use, like being stuck with an offset that we'll always have to guard against corruption due to people blindly scripting the zImage poking you suggested even when it is not needed.
People will find ways to screw it up if they really want to anyway. So I'd lean towards keeping this simple and not create any legacy around this hopefully temporary accommodation feature.
Nicolas
PATCH 2/6 ARM: zImage: Allow the appending of a device tree binary
Quoted 5 lines · Nicolas Pitre
Quoted 3 lines · Dave Martin
Quoted 2 lines · Nicolas Pitre
On Wed, 14 Sep 2011, Dave Martin wrote:
[...]
Quoted 25 lines
Quoted 13 lines
Quoted 7 lines
Quoted 6 lines
Do we worry that garbage in memory after the zImage might match this magic number?
For example, if an ordinary userspace program allocates a huge number of pages and fills them with bogus device tree headers, is there a chance that the those headers could remain in memory across a reboot?
Quoted 5 lines
In theory this _could_ be possible. However I don't expect this feature to be enabled if you are not going to actually use it, especially in a production setup. If you are not appending a DTB to your kernel then there is simply no point keeping this config option set (normally you should use this option only because you have no other choices).
Quoted 4 lines
That seems reasonable.
Should we document this recommendation, in the
Kconfighelp orDocumentation/?I'll add some scary wording to the help text, and make it depend on EXPERIMENTAL as well. I prefer not to impose some expectations on the zImage layout for this even if not in use, like being stuck with an offset that we'll always have to guard against corruption due to people blindly scripting the zImage poking you suggested even when it is not needed.
Quoted 3 lines
People will find ways to screw it up if they really want to anyway. So I'd lean towards keeping this simple and not create any legacy around this hopefully temporary accommodation feature.
Yeah, sure -- I think documentating it is enough for now.
And I agree we don't really want to reinvent the rdev nastiness for zImages...
Cheers
---Dave
PATCH 3/6 ARM: zImage: make sure appended DTB doesn't get overwritten by kernel .bss
In reply to Nicolas PitreFrom: Nicolas Pitre <[email protected]>
The appended DTB gets relocated with the decompressor code to get out of the way of the decompressed kernel. However the kernel's .bss section may be larger than the relocated code and data, and then the DTB gets overwritten. Let's make sure the relocation takes care of moving zImage far enough so no such conflict with .bss occurs.
Thanks to Tony Lindgren <[email protected]> for figuring out this issue.
While at it, let's clean up the code a bit so that the wont_overwrite symbol is used while determining if a conflict exists, making the above change more precise as well as eliminating some ARM/THUMB alternates.
--- arch/arm/boot/compressed/Makefile | 3 +++ arch/arm/boot/compressed/head.S | 19 +++++++++++++++---- 2 files changed, 18 insertions(+), 4 deletions(-)
arch/arm/boot/compressed/Makefile +3 -0
@@ -104,6 +104,9 @@ endif ccflags-y := -fpic -fno-builtin asflags-y := -Wa,-march=all +# Supply kernel BSS size to the decompressor via a linker symbol. +KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}') +LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ) # Supply ZRELADDR to the decompressor via a linker symbol. ifneq ($(CONFIG_AUTO_ZRELADDR),y) LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
arch/arm/boot/compressed/head.S +15 -4
@@ -248,6 +248,18 @@ restart: adr r0, LC0 mov r8, r6 @ use the appended device tree + /* + * Make sure that the DTB doesn't end up in the final + * kernel's .bss area. To do so, we adjust the decompressed + * kernel size to compensate if that .bss size is larger + * than the relocated code. + */ + ldr r5, =_kernel_bss_size + adr r1, wont_overwrite + sub r1, r6, r1 + subs r1, r5, r1 + addhi r9, r9, r1 + /* Get the dtb's size */ ldr r5, [r6, #4] #ifndef __ARMEB__
@@ -276,15 +288,14 @@ dtb_check_done: * r10 = end of this image, including bss/stack/malloc space if non XIP * We basically want: * r4 - 16k page directory >= r10 -> OK - * r4 + image length <= current position (pc) -> OK + * r4 + image length <= address of wont_overwrite -> OK */ add r10, r10, #16384 cmp r4, r10 bhs wont_overwrite add r10, r4, r9 - ARM( cmp r10, pc ) - THUMB( mov lr, pc ) - THUMB( cmp r10, lr ) + adr r9, wont_overwrite + cmp r10, r9 bls wont_overwrite /*
Signature · 1 line
1.7.7-rc0
PATCH 4/6 ARM: zImage: gather some string functions into string.c
In reply to Nicolas PitreFrom: Nicolas Pitre <[email protected]>
This is a small subset of string functions needed by commits to come. Except for memcpy() which is unchanged from its original location, their implementation is meant to be small, and -Os is enforced to prevent gcc from doing pointless loop unrolling.
--- arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/misc.c | 42 +------------ arch/arm/boot/compressed/string.c | 127 +++++++++++++++++++++++++++++++++++++ 3 files changed, 132 insertions(+), 41 deletions(-) create mode 100644 arch/arm/boot/compressed/string.c
arch/arm/boot/compressed/Makefile +4 -0
@@ -26,6 +26,10 @@ HEAD = head.o OBJS += misc.o decompress.o FONTC = $(srctree)/drivers/video/console/font_acorn_8x8.c +# string library code (-Os is enforced to keep it much smaller) +OBJS += string.o +CFLAGS_string.o := -Os + # # Architecture dependencies #
arch/arm/boot/compressed/misc.c +1 -41
56 lines not on this page · raw message
arch/arm/boot/compressed/string.c new file +127 -0
127 lines not on this page · raw message
Signature · 1 line
1.7.7-rc0
PATCH 4/6 ARM: zImage: gather some string functions into string.c
Quoted 78 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
This is a small subset of string functions needed by commits to come. Except for
memcpy()which is unchanged from its original location, their implementation is meant to be small, and -Os is enforced to prevent gcc from doing pointless loop unrolling.Signed-off-by Nicolas Pitre <[email protected]>--- arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/misc.c | 42 +------------ arch/arm/boot/compressed/string.c | 127 +++++++++++++++++++++++++++++++++++++ 3 files changed, 132 insertions(+), 41 deletions(-) create mode 100644 arch/arm/boot/compressed/string.carch/arm/boot/compressed/Makefile +4
-0@@ -26,6 +26,10 @@ HEAD = head.o OBJS += misc.o decompress.o FONTC = $(srctree)/drivers/video/console/font_acorn_8x8.c +# string library code (-Os is enforced to keep it much smaller) +OBJS += string.o +CFLAGS_string.o := -Os + # # Architecture dependencies #arch/arm/boot/compressed/misc.c +1
-30@@ -18,14 +18,9 @@unsigned int __machine_arch_type; -#define _LINUX_STRING_H_ -#include <linux/compiler.h> /* for inline */ -#include <linux/types.h> /* for size_t */ -#include <linux/stddef.h> /* for NULL */ +#include <linux/types.h> #include <linux/linkage.h> -#include <asm/string.h> -static void putstr (const char *ptr);extern void error (char *x);@@ -101,41 +96,6 @@ static void putstr(const char *ptr)flush (); } - -void *memcpy(void *__dest, __const void *__src, size_t __n) -{ -int i =0 ; -unsigned char *d = (unsigned char *)__dest, *s = (unsigned char *)__src; - -for (i = __n >>3 ; i >0 ; i--) { - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - } - -if (__n &1 <<2 ) { - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - *d++ = *s++; - } -
arch/arm/boot/compressed/misc.c static void putstr(const char *ptr) · line 137
Quoted 10 lines
arch/arm/boot/compressed/misc.c +0
-10-if (__n &1 <<1 ) { - *d++ = *s++; - *d++ = *s++; - } - -if (__n &1 ) - *d++ = *s++; - -return __dest; -}
Have you seen this?
http://en.wikipedia.org/wiki/Duff%27s_device
Once I finished vomiting, this actually struck be as rather neat.
If I've understood right, it seems a good fit for the manual unrolling you do here.
Cheers
---Dave
PATCH 4/6 ARM: zImage: gather some string functions into string.c
Quoted 2 lines · Dave Martin
Have you seen this?
http://en.wikipedia.org/wiki/Duff%27s_device
Yeah... I did stumble across something similar in the gcc test suite.
Quoted 4 lines
Once I finished vomiting, this actually struck be as rather neat.
If I've understood right, it seems a good fit for the manual unrolling you do here.
Maybe. However this patch is about moving code, not "improving" it. ;-)
Nicolas
PATCH 4/6 ARM: zImage: gather some string functions into string.c
Quoted 5 lines · Nicolas Pitre
Quoted 2 lines · Dave Martin
Have you seen this?
http://en.wikipedia.org/wiki/Duff%27s_device
Quoted 8 lines
Yeah... I did stumble across something similar in the gcc test suite.
Quoted 4 lines
Once I finished vomiting, this actually struck be as rather neat.
If I've understood right, it seems a good fit for the manual unrolling you do here.
Maybe. However this patch is about moving code, not "improving" it. ;-)
Fair enough -- it was really just a side-comment rather than an issue with the patch.
---Dave
PATCH 4/6 ARM: zImage: gather some string functions into string.c
Quoted 10 lines · Dave Martin
Quoted 9 lines · Nicolas Pitre
Quoted 2 lines · Dave Martin
Have you seen this?
http://en.wikipedia.org/wiki/Duff%27s_deviceYeah... I did stumble across something similar in the gcc test suite.
Quoted 2 lines
Once I finished vomiting, this actually struck be as rather neat.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
If I've understood right, it seems a good fit for the manual unrolling you do here.
Maybe. However this patch is about moving code, not "improving" it. ;-)
Fair enough -- it was really just a side-comment rather than an issue with the patch.
Might be worth investigating separately though.
Nicolas
PATCH 5/6 ARM: zImage: allow supplementing appended DTB with traditional ATAG data
In reply to Nicolas PitreFrom: Nicolas Pitre <[email protected]>
Some old bootloaders can't be updated to a device tree capable one, yet they provide ATAGs with memory configuration, the ramdisk address, the kernel cmdline string, etc. To allow a device tree enabled kernel to be used with such bootloaders, it is necessary to convert those ATAGs into FDT properties and fold them into the DTB appended to zImage.
Currently the following ATAGs are converted:
ATAG_CMDLINE
ATAG_MEM
ATAG_INITRD2
If the corresponding information already exists in the appended DTB, it is replaced, otherwise the required node is created to hold it.
The code looks for ATAGs at the location pointed by the value of r2 upon entry into the zImage code. If no ATAGs are found there, an attempt at finding ATAGs at the typical 0x100 offset from start of RAM is made. Otherwise the DTB is left unchanged.
Thisstarted from an older patch from John Bonesio <[email protected]>, with contributions from David Brown <[email protected]>.
--- arch/arm/Kconfig | 11 ++++ arch/arm/boot/compressed/.gitignore | 9 +++ arch/arm/boot/compressed/Makefile | 21 ++++++- arch/arm/boot/compressed/atags_to_fdt.c | 97 +++++++++++++++++++++++++++++++ arch/arm/boot/compressed/head.S | 32 ++++++++++ arch/arm/boot/compressed/libfdt_env.h | 15 +++++ 6 files changed, 183 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/compressed/atags_to_fdt.c create mode 100644 arch/arm/boot/compressed/libfdt_env.h
arch/arm/Kconfig +11 -0
@@ -1789,6 +1789,17 @@ config ARM_APPENDED_DTB (dtb) appended to zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb). +config ARM_ATAG_DTB_COMPAT + bool "Supplement the appended DTB with traditional ATAG information" + depends on ARM_APPENDED_DTB + help + Some old bootloaders can't be updated to a DTB capable one, yet + they provide ATAGs with memory configuration, the ramdisk address, + the kernel cmdline string, etc. To allow a device tree enabled + kernel to be used with such bootloaders, this option allows + zImage to extract the information from the ATAG list and store it + at run time into the appended DTB. + config CMDLINE string "Default kernel command string" default ""
arch/arm/boot/compressed/.gitignore +9 -0
@@ -5,3 +5,12 @@ piggy.lzo piggy.lzma vmlinux vmlinux.lds + +# borrowed libfdt files +fdt.c +fdt.h +fdt_ro.c +fdt_rw.c +fdt_wip.c +libfdt.h +libfdt_internal.h
arch/arm/boot/compressed/Makefile +19 -2
@@ -93,19 +93,36 @@ suffix_$(CONFIG_KERNEL_GZIP) = gzip suffix_$(CONFIG_KERNEL_LZO) = lzo suffix_$(CONFIG_KERNEL_LZMA) = lzma +# Borrowed libfdt files for the ATAG compatibility mode + +libfdt := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c +libfdt_hdrs := fdt.h libfdt.h libfdt_internal.h + +libfdt_objs := $(addsuffix .o, $(basename $(libfdt))) + +$(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/% + $(call cmd,shipped) + +$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \ + $(addprefix $(obj)/,$(libfdt_hdrs)) + +ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y) +OBJS += $(libfdt_objs) atags_to_fdt.o +endif + targets := vmlinux vmlinux.lds \ piggy.$(suffix_y) piggy.$(suffix_y).o \ font.o font.c head.o misc.o $(OBJS) # Make sure files are removed during clean -extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S +extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs) ifeq ($(CONFIG_FUNCTION_TRACER),y) ORIG_CFLAGS := $(KBUILD_CFLAGS) KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS)) endif -ccflags-y := -fpic -fno-builtin +ccflags-y := -fpic -fno-builtin -I$(obj) asflags-y := -Wa,-march=all # Supply kernel BSS size to the decompressor via a linker symbol.
arch/arm/boot/compressed/atags_to_fdt.c new file +97 -0
97 lines not on this page · raw message
arch/arm/boot/compressed/head.S +32 -0
@@ -246,6 +246,38 @@ restart: adr r0, LC0 cmp lr, r1 bne dtb_check_done @ not found +#ifdef CONFIG_ARM_ATAG_DTB_COMPAT + /* + * OK... Let's do some funky business here. + * If we do have a DTB appended to zImage, and we do have + * an ATAG list around, we want the later to be translated + * and folded into the former here. To be on the safe side, + * let's temporarily move the stack away into the malloc + * area. No GOT fixup has occurred yet, but none of the + * code we're about to call uses any global variable. + */ + add sp, sp, #0x10000 + stmfd sp!, {r0-r3, ip, lr} + mov r0, r8 + mov r1, r6 + sub r2, sp, r6 + bl atags_to_fdt + + /* + * If returned value is 1, there is no ATAG at the location + * pointed by r8. Try the typical 0x100 offset from start + * of RAM and hope for the best. + */ + cmp r0, #1 + sub r0, r4, #(TEXT_OFFSET - 0x100) + mov r1, r6 + sub r2, sp, r6 + blne atags_to_fdt + + ldmfd sp!, {r0-r3, ip, lr} + sub sp, sp, #0x10000 +#endif + mov r8, r6 @ use the appended device tree /*
arch/arm/boot/compressed/libfdt_env.h new file +15 -0
@@ -0,0 +1,15 @@ +#ifndef _ARM_LIBFDT_ENV_H +#define _ARM_LIBFDT_ENV_H + +#include <linux/types.h> +#include <linux/string.h> +#include <asm/byteorder.h> + +#define fdt16_to_cpu (x) be16_to_cpu(x) +#define cpu_to_fdt16 (x) cpu_to_be16(x) +#define fdt32_to_cpu (x) be32_to_cpu(x) +#define cpu_to_fdt32 (x) cpu_to_be32(x) +#define fdt64_to_cpu (x) be64_to_cpu(x) +#define cpu_to_fdt64 (x) cpu_to_be64(x) + +#endif
Signature · 1 line
1.7.7-rc0
PATCH 6/6 ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
In reply to Nicolas PitreFrom: Nicolas Pitre <[email protected]>
The rule to copy this file doesn't have to be forced. However lib1funcs.[So] have to be listed amongst the targets.
This prevents zImage from being recreated needlessly.
--- arch/arm/boot/compressed/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/compressed/Makefile +2 -2
@@ -112,7 +112,7 @@ endif targets := vmlinux vmlinux.lds \ piggy.$(suffix_y) piggy.$(suffix_y).o \ - font.o font.c head.o misc.o $(OBJS) + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS) # Make sure files are removed during clean extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
@@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T # For __aeabi_uidivmod lib1funcs = $(obj)/lib1funcs.o -$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S $(call cmd,shipped) # We need to prevent any GOTOFF relocs being used with references
Signature · 1 line
1.7.7-rc0
PATCH 6/6 ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
Quoted 26 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
The rule to copy this file doesn't have to be forced. However lib1funcs.[So] have to be listed amongst the targets.
This prevents zImage from being recreated needlessly.
Signed-off-by Nicolas Pitre <[email protected]>--- arch/arm/boot/compressed/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)arch/arm/boot/compressed/Makefile +1
-1@@ -112,7 +112,7 @@ endif targets := vmlinux vmlinux.lds \ piggy.$(suffix_y) piggy.$(suffix_y).o \ - font.o font.c head.o misc.o $(OBJS) + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS) # Make sure files are removed during clean extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
arch/arm/boot/compressed/Makefile LDFLAGS_vmlinux += -T · line 153
Quoted 8 lines
arch/arm/boot/compressed/Makefile +1
-1@@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T # For __aeabi_uidivmod lib1funcs = $(obj)/lib1funcs.o -$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S $(call cmd,shipped) # We need to prevent any GOTOFF relocs being used with references
I already posted a very similar patch and put it into Russell's patch tracker. Can't you just use that instead?
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7016/1
http://lists.arm.linux.org.uk/lurker/message/20110812.190002.18f88875.en.html
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH 6/6 ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
Quoted 30 lines · Stephen Boyd
Quoted 29 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
The rule to copy this file doesn't have to be forced. However lib1funcs.[So] have to be listed amongst the targets.
This prevents zImage from being recreated needlessly.
Signed-off-by Nicolas Pitre <[email protected]>--- arch/arm/boot/compressed/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)arch/arm/boot/compressed/Makefile +1
-1@@ -112,7 +112,7 @@ endif targets := vmlinux vmlinux.lds \ piggy.$(suffix_y) piggy.$(suffix_y).o \ - font.o font.c head.o misc.o $(OBJS) + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS) # Make sure files are removed during clean extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)@@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T # For __aeabi_uidivmod lib1funcs = $(obj)/lib1funcs.o
Quoted 8 lines
arch/arm/boot/compressed/Makefile LDFLAGS_vmlinux += -T · line 153
Quoted 5 lines
arch/arm/boot/compressed/Makefile +1
-1-$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S $(call cmd,shipped) # We need to prevent any GOTOFF relocs being used with referencesI already posted a very similar patch and put it into Russell's patch tracker. Can't you just use that instead?
I remember this was discussed, but I forgot that you actually did send a patch. Either version is fine with me.
Hmmm. My version has been merged in RMK's devel-stable branch already though.
Nicolas
PATCH 6/6 ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
In reply to Stephen BoydQuoted 30 lines · Stephen Boyd
Quoted 29 lines · Nicolas Pitre
From: Nicolas Pitre <[email protected]>
The rule to copy this file doesn't have to be forced. However lib1funcs.[So] have to be listed amongst the targets.
This prevents zImage from being recreated needlessly.
Signed-off-by Nicolas Pitre <[email protected]>--- arch/arm/boot/compressed/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)arch/arm/boot/compressed/Makefile +1
-1@@ -112,7 +112,7 @@ endif targets := vmlinux vmlinux.lds \ piggy.$(suffix_y) piggy.$(suffix_y).o \ - font.o font.c head.o misc.o $(OBJS) + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS) # Make sure files are removed during clean extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)@@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T # For __aeabi_uidivmod lib1funcs = $(obj)/lib1funcs.o
Quoted 8 lines
arch/arm/boot/compressed/Makefile LDFLAGS_vmlinux += -T · line 153
Quoted 5 lines
arch/arm/boot/compressed/Makefile +1
-1-$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S $(call cmd,shipped) # We need to prevent any GOTOFF relocs being used with referencesI already posted a very similar patch and put it into Russell's patch tracker. Can't you just use that instead?
You did, but then there followed quite a lengthy discussion about it so I avoided applying it. The discussion didn't seem to really reach any conclusion wrt the patch so I didn't know what to do about it.
PATCH 6/6 ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
Quoted 7 lines · Russell King - ARM Linux
Quoted 3 lines · Stephen Boyd
I already posted a very similar patch and put it into Russell's patch tracker. Can't you just use that instead?
You did, but then there followed quite a lengthy discussion about it so I avoided applying it. The discussion didn't seem to really reach any conclusion wrt the patch so I didn't know what to do about it.
I was under the impression that the kbuild stuff would come later and so it was safe to apply the patch now (apparently it was because that happened here).
I guess next time I'll push harder.
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
cover zImage improvements with DTB append and ATAG compatibility
In reply to Nicolas PitreQuoted 11 lines · Nicolas Pitre
This is the latest incarnation of my patch series allowing a DTB to be appended to zImage, including the ATAG conversion wrapper and other minor cleanups.
This can also be pulled from:
git://git.linaro.org/people/nico/linuxzImage_DTB_appendThis works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
Signature · 2 lines
Regards, Shawn
cover zImage improvements with DTB append and ATAG compatibility
In reply to Nicolas PitreQuoted 10 lines · Nicolas Pitre
This is the latest incarnation of my patch series allowing a DTB to be appended to zImage, including the ATAG conversion wrapper and other minor cleanups.
This can also be pulled from:
git://git.linaro.org/people/nico/linuxzImage_DTB_appendThis works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
For the series:
Tested in Thumb-2 with my almost-ready vexpress DT patches, including the ATAG merging support.
Cheers
---Dave
cover zImage improvements with DTB append and ATAG compatibility
In reply to Nicolas PitreQuoted 10 lines · Nicolas Pitre
This is the latest incarnation of my patch series allowing a DTB to be appended to zImage, including the ATAG conversion wrapper and other minor cleanups.
This can also be pulled from:
? ? ? ?git://git.linaro.org/people/nico/linux
zImage_DTB_appendThis works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
Works fine for Exynos4 device tree support.
Quoted 12 lines
Nicolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
cover zImage improvements with DTB append and ATAG compatibility
In reply to Nicolas PitreQuoted 10 lines · Nicolas Pitre
This is the latest incarnation of my patch series allowing a DTB to be appended to zImage, including the ATAG conversion wrapper and other minor cleanups.
This can also be pulled from:
git://git.linaro.org/people/nico/linuxzImage_DTB_appendThis works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
on MSM8660:
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.