[PATCH 0/7] Re-organize linker layouts

[PATCH 0/7] Re-organize linker layouts

[Russell King - ARM Linux]

The following series of patches are targetted at two issues:

1. Fixing large initramfs causing PC24 relocations to become out of
   range.  This fixes both modules and link-time errors.

2. Making the vmlinux easier to pinpoint the various section-built
   data structures and inspect them later.

For the main kernel, this allows the size of various sections to be
determined via objdump -h.  This also aids objdump -d and -s usage
when asking it to target a particular section.

For the decompressor, it means that it is now trivially possible to copy
out the compressed kernel vmlinux image by:

  arm-linux-objcopy -O binary -j .piggydata arch/arm/boot/compressed/vmlinux \
	piggy.gz

and thereby obtain the binary kernel image (the Image file) which was
originally used.

[PATCH 1/7] ARM: ensure tag tables are const

[Russell King - ARM Linux]

Nothing should ever modify a tag table entry, so mark these const.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/setup.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index ee2ad8a..c3b5c79 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -187,7 +187,7 @@ struct tagtable {
 
 #define __tag __used __attribute__((__section__(".taglist.init")))
 #define __tagtable(tag, fn) \
-static struct tagtable __tagtable_##fn __tag = { tag, fn }
+static const struct tagtable __tagtable_##fn __tag = { tag, fn }
 
 /*
  * Memory map description
-- 
1.7.4.4

[PATCH 2/7] ARM: decompressor: use better output sections

[Russell King - ARM Linux]

Place read-only data in a .rodata output section, and the compressed
piggy data in .piggydata.  Place the .got.plt section before the .got
section as is standard ELF practise.

This allows the piggydata to be more easily extracted from the
compressed vmlinux file for verification purposes.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/compressed/vmlinux.lds.in |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.in b/arch/arm/boot/compressed/vmlinux.lds.in
index ea80abe..4e72883 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.in
+++ b/arch/arm/boot/compressed/vmlinux.lds.in
@@ -33,20 +33,24 @@ SECTIONS
     *(.text.*)
     *(.fixup)
     *(.gnu.warning)
+    *(.glue_7t)
+    *(.glue_7)
+  }
+  .rodata : {
     *(.rodata)
     *(.rodata.*)
-    *(.glue_7)
-    *(.glue_7t)
+  }
+  .piggydata : {
     *(.piggydata)
-    . = ALIGN(4);
   }
 
+  . = ALIGN(4);
   _etext = .;
 
+  .got.plt		: { *(.got.plt) }
   _got_start = .;
   .got			: { *(.got) }
   _got_end = .;
-  .got.plt		: { *(.got.plt) }
   _edata = .;
 
   . = BSS_START;
-- 
1.7.4.4

[PATCH 3/7] ARM: vmlinux.lds: move discarded sections to beginning

[Russell King - ARM Linux]

Rather than scattering the discarded sections throughout the linker
file, move them to the start.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/vmlinux.lds.S |   47 +++++++++++++++++++---------------------
 1 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index e5287f2..cb46a9b 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -38,6 +38,28 @@ jiffies = jiffies_64 + 4;
 
 SECTIONS
 {
+	/*
+	 * unwind exit sections must be discarded before the rest of the
+	 * unwind sections get included.
+	 */
+	/DISCARD/ : {
+		*(.ARM.exidx.exit.text)
+		*(.ARM.extab.exit.text)
+		ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
+		ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
+#ifndef CONFIG_HOTPLUG
+		*(.ARM.exidx.devexit.text)
+		*(.ARM.extab.devexit.text)
+#endif
+#ifndef CONFIG_MMU
+		*(.fixup)
+		*(__ex_table)
+#endif
+#ifndef CONFIG_SMP_ON_UP
+		*(.alt.smp.init)
+#endif
+	}
+
 #ifdef CONFIG_XIP_KERNEL
 	. = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
 #else
@@ -89,25 +111,6 @@ SECTIONS
 	__init_end = .;
 #endif
 
-	/*
-	 * unwind exit sections must be discarded before the rest of the
-	 * unwind sections get included.
-	 */
-	/DISCARD/ : {
-		*(.ARM.exidx.exit.text)
-		*(.ARM.extab.exit.text)
-		ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
-		ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
-#ifndef CONFIG_HOTPLUG
-		*(.ARM.exidx.devexit.text)
-		*(.ARM.extab.devexit.text)
-#endif
-#ifndef CONFIG_MMU
-		*(.fixup)
-		*(__ex_table)
-#endif
-	}
-
 	.text : {			/* Real text segment		*/
 		_text = .;		/* Text and read-only data	*/
 			__exception_text_start = .;
@@ -270,12 +273,6 @@ SECTIONS
 
 	/* Default discards */
 	DISCARDS
-
-#ifndef CONFIG_SMP_ON_UP
-	/DISCARD/ : {
-		*(.alt.smp.init)
-	}
-#endif
 }
 
 /*
-- 
1.7.4.4

[PATCH 4/7] ARM: vmlinux.lds: rearrange .init output section

[Russell King - ARM Linux]

Keep the various linker tables as separate output sections rather
than combining them together into one big .init section.  This
makes the 'vmlinux' easier to see what is placed where.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/vmlinux.lds.S |   47 +++++++++++++++++++++++++---------------
 1 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index cb46a9b..c8bb9b7 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -65,48 +65,59 @@ SECTIONS
 #else
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #endif
-
-	.init : {			/* Init code and data		*/
+	.head.text : {
 		_stext = .;
-		_sinittext = .;
-			HEAD_TEXT
-			INIT_TEXT
-			ARM_EXIT_KEEP(EXIT_TEXT)
-		_einittext = .;
+		HEAD_TEXT
+	}
+	INIT_TEXT_SECTION(8)
+	.exit.text : {
+		ARM_EXIT_KEEP(EXIT_TEXT)
+	}
+	.init.proc.info : {
 		ARM_CPU_DISCARD(PROC_INFO)
+	}
+	.init.arch.info : {
 		__arch_info_begin = .;
-			*(.arch.info.init)
+		*(.arch.info.init)
 		__arch_info_end = .;
+	}
+	.init.tagtable : {
 		__tagtable_begin = .;
-			*(.taglist.init)
+		*(.taglist.init)
 		__tagtable_end = .;
+	}
 #ifdef CONFIG_SMP_ON_UP
+	.init.smpalt : {
 		__smpalt_begin = .;
-			*(.alt.smp.init)
+		*(.alt.smp.init)
 		__smpalt_end = .;
+	}
 #endif
-
+	.init.pv_table : {
 		__pv_table_begin = .;
-			*(.pv_table)
+		*(.pv_table)
 		__pv_table_end = .;
-
+	}
+	.init.data : {
+#ifndef CONFIG_XIP_KERNEL
+		INIT_DATA
+#endif
 		INIT_SETUP(16)
-
 		INIT_CALLS
 		CON_INITCALL
 		SECURITY_INITCALL
 		INIT_RAM_FS
-
+	}
 #ifndef CONFIG_XIP_KERNEL
-		__init_begin = _stext;
-		INIT_DATA
+	.exit.data : {
 		ARM_EXIT_KEEP(EXIT_DATA)
-#endif
 	}
+#endif
 
 	PERCPU_SECTION(32)
 
 #ifndef CONFIG_XIP_KERNEL
+	__init_begin = _stext;
 	. = ALIGN(PAGE_SIZE);
 	__init_end = .;
 #endif
-- 
1.7.4.4

[PATCH 5/7] ARM: vmlinux.lds: remove .rodata/.rodata1 from main .text segment

[Russell King - ARM Linux]

RODATA() already handles these sections, so allow it to take care
of them for us.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/vmlinux.lds.S |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index c8bb9b7..fa812d0 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -136,8 +136,6 @@ SECTIONS
 			*(.fixup)
 #endif
 			*(.gnu.warning)
-			*(.rodata)
-			*(.rodata.*)
 			*(.glue_7)
 			*(.glue_7t)
 		. = ALIGN(4);
-- 
1.7.4.4

[PATCH 6/7] ARM: vmlinux.lds: move init sections between text and data sections

[Russell King - ARM Linux]

Place the init sections between the text and data sections.  This
means all code is grouped together at the beginning of the kernel
image, and all data is at the end of the image.  This avoids problems
with the 24-bit branch instruction relocations becoming invalid with
large initramfs images.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/vmlinux.lds.S |   96 ++++++++++++++++++++--------------------
 arch/arm/mm/init.c            |    4 +-
 2 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index fa812d0..18574b7 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -69,6 +69,53 @@ SECTIONS
 		_stext = .;
 		HEAD_TEXT
 	}
+	.text : {			/* Real text segment		*/
+		_text = .;		/* Text and read-only data	*/
+			__exception_text_start = .;
+			*(.exception.text)
+			__exception_text_end = .;
+			IRQENTRY_TEXT
+			TEXT_TEXT
+			SCHED_TEXT
+			LOCK_TEXT
+			KPROBES_TEXT
+#ifdef CONFIG_MMU
+			*(.fixup)
+#endif
+			*(.gnu.warning)
+			*(.glue_7)
+			*(.glue_7t)
+		. = ALIGN(4);
+		*(.got)			/* Global offset table		*/
+			ARM_CPU_KEEP(PROC_INFO)
+	}
+
+	RO_DATA(PAGE_SIZE)
+
+#ifdef CONFIG_ARM_UNWIND
+	/*
+	 * Stack unwinding tables
+	 */
+	. = ALIGN(8);
+	.ARM.unwind_idx : {
+		__start_unwind_idx = .;
+		*(.ARM.exidx*)
+		__stop_unwind_idx = .;
+	}
+	.ARM.unwind_tab : {
+		__start_unwind_tab = .;
+		*(.ARM.extab*)
+		__stop_unwind_tab = .;
+	}
+#endif
+
+	_etext = .;			/* End of text and rodata section */
+
+#ifndef CONFIG_XIP_KERNEL
+	. = ALIGN(PAGE_SIZE);
+	__init_begin = .;
+#endif
+
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
 		ARM_EXIT_KEEP(EXIT_TEXT)
@@ -116,58 +163,11 @@ SECTIONS
 
 	PERCPU_SECTION(32)
 
-#ifndef CONFIG_XIP_KERNEL
-	__init_begin = _stext;
-	. = ALIGN(PAGE_SIZE);
-	__init_end = .;
-#endif
-
-	.text : {			/* Real text segment		*/
-		_text = .;		/* Text and read-only data	*/
-			__exception_text_start = .;
-			*(.exception.text)
-			__exception_text_end = .;
-			IRQENTRY_TEXT
-			TEXT_TEXT
-			SCHED_TEXT
-			LOCK_TEXT
-			KPROBES_TEXT
-#ifdef CONFIG_MMU
-			*(.fixup)
-#endif
-			*(.gnu.warning)
-			*(.glue_7)
-			*(.glue_7t)
-		. = ALIGN(4);
-		*(.got)			/* Global offset table		*/
-			ARM_CPU_KEEP(PROC_INFO)
-	}
-
-	RO_DATA(PAGE_SIZE)
-
-#ifdef CONFIG_ARM_UNWIND
-	/*
-	 * Stack unwinding tables
-	 */
-	. = ALIGN(8);
-	.ARM.unwind_idx : {
-		__start_unwind_idx = .;
-		*(.ARM.exidx*)
-		__stop_unwind_idx = .;
-	}
-	.ARM.unwind_tab : {
-		__start_unwind_tab = .;
-		*(.ARM.extab*)
-		__stop_unwind_tab = .;
-	}
-#endif
-
-	_etext = .;			/* End of text and rodata section */
-
 #ifdef CONFIG_XIP_KERNEL
 	__data_loc = ALIGN(4);		/* location in binary */
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #else
+	__init_end = .;
 	. = ALIGN(THREAD_SIZE);
 	__data_loc = .;
 #endif
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c19571c..b8e8912 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -639,8 +639,8 @@ void __init mem_init(void)
 			"    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
 #endif
 			"    modules : 0x%08lx - 0x%08lx   (%4ld MB)\n"
-			"      .init : 0x%p" " - 0x%p" "   (%4d kB)\n"
 			"      .text : 0x%p" " - 0x%p" "   (%4d kB)\n"
+			"      .init : 0x%p" " - 0x%p" "   (%4d kB)\n"
 			"      .data : 0x%p" " - 0x%p" "   (%4d kB)\n"
 			"       .bss : 0x%p" " - 0x%p" "   (%4d kB)\n",
 
@@ -662,8 +662,8 @@ void __init mem_init(void)
 #endif
 			MLM(MODULES_VADDR, MODULES_END),
 
-			MLK_ROUNDUP(__init_begin, __init_end),
 			MLK_ROUNDUP(_text, _etext),
+			MLK_ROUNDUP(__init_begin, __init_end),
 			MLK_ROUNDUP(_sdata, _edata),
 			MLK_ROUNDUP(__bss_start, __bss_stop));
 
-- 
1.7.4.4

[PATCH 7/7] ARM: vmlinux.lds: use _text and _stext the same way as x86

[Russell King - ARM Linux]

x86 uses _text to mark the start of the kernel image including the
head text, and _stext to mark the start of the .text section.  Change
our vmlinux.lds to conform.  An audit of the places which use _stext
and _text in arch/arm indicates no users of either symbol are impacted
by this change.  It does mean a slight change to /proc/iomem output.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/vmlinux.lds.S |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 18574b7..bf977f8 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -66,11 +66,11 @@ SECTIONS
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #endif
 	.head.text : {
-		_stext = .;
+		_text = .;
 		HEAD_TEXT
 	}
 	.text : {			/* Real text segment		*/
-		_text = .;		/* Text and read-only data	*/
+		_stext = .;		/* Text and read-only data	*/
 			__exception_text_start = .;
 			*(.exception.text)
 			__exception_text_end = .;
-- 
1.7.4.4

[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Wed, 6 Jul 2011, Russell King - ARM Linux wrote:

> The following series of patches are targetted at two issues:
> 
> 1. Fixing large initramfs causing PC24 relocations to become out of
>    range.  This fixes both modules and link-time errors.
> 
> 2. Making the vmlinux easier to pinpoint the various section-built
>    data structures and inspect them later.
> 
> For the main kernel, this allows the size of various sections to be
> determined via objdump -h.  This also aids objdump -d and -s usage
> when asking it to target a particular section.
> 
> For the decompressor, it means that it is now trivially possible to copy
> out the compressed kernel vmlinux image by:
> 
>   arm-linux-objcopy -O binary -j .piggydata arch/arm/boot/compressed/vmlinux \
> 	piggy.gz
> 
> and thereby obtain the binary kernel image (the Image file) which was
> originally used.

Looks good.  For the whole series:

Acked-by: nicolas Pitre <nicolas.pitre@linaro.org>


Nicolas

[PATCH 0/7] Re-organize linker layouts

[Stephen Boyd]

On 07/06/2011 03:22 AM, Russell King - ARM Linux wrote:
> The following series of patches are targetted at two issues:
>
> 1. Fixing large initramfs causing PC24 relocations to become out of
>    range.  This fixes both modules and link-time errors.
>
> 2. Making the vmlinux easier to pinpoint the various section-built
>    data structures and inspect them later.
>
> For the main kernel, this allows the size of various sections to be
> determined via objdump -h.  This also aids objdump -d and -s usage
> when asking it to target a particular section.
>
> For the decompressor, it means that it is now trivially possible to copy
> out the compressed kernel vmlinux image by:
>
>   arm-linux-objcopy -O binary -j .piggydata arch/arm/boot/compressed/vmlinux \
> 	piggy.gz
>
> and thereby obtain the binary kernel image (the Image file) which was
> originally used.

I gave this series a test with my poison initmem patch and all looks well

Tested-by: Stephen Boyd <sboyd@codeaurora.org>

except for patch 2 as I didn't use a zImage.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 0/7] Re-organize linker layouts

[Russell King - ARM Linux]

On Thu, Jul 07, 2011 at 10:28:22AM -0700, Stephen Boyd wrote:
> On 07/06/2011 03:22 AM, Russell King - ARM Linux wrote:
> > The following series of patches are targetted at two issues:
> >
> > 1. Fixing large initramfs causing PC24 relocations to become out of
> >    range.  This fixes both modules and link-time errors.
> >
> > 2. Making the vmlinux easier to pinpoint the various section-built
> >    data structures and inspect them later.
> >
> > For the main kernel, this allows the size of various sections to be
> > determined via objdump -h.  This also aids objdump -d and -s usage
> > when asking it to target a particular section.
> >
> > For the decompressor, it means that it is now trivially possible to copy
> > out the compressed kernel vmlinux image by:
> >
> >   arm-linux-objcopy -O binary -j .piggydata arch/arm/boot/compressed/vmlinux \
> > 	piggy.gz
> >
> > and thereby obtain the binary kernel image (the Image file) which was
> > originally used.
> 
> I gave this series a test with my poison initmem patch and all looks well
> 
> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> 
> except for patch 2 as I didn't use a zImage.

Oh, what did you use instead?  I thought no one used the Image files
anymore...

[PATCH 0/7] Re-organize linker layouts

[Stephen Boyd]

On 07/07/2011 03:36 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 07, 2011 at 10:28:22AM -0700, Stephen Boyd wrote:
>> On 07/06/2011 03:22 AM, Russell King - ARM Linux wrote:
>>> The following series of patches are targetted at two issues:
>>>
>>> 1. Fixing large initramfs causing PC24 relocations to become out of
>>>    range.  This fixes both modules and link-time errors.
>>>
>>> 2. Making the vmlinux easier to pinpoint the various section-built
>>>    data structures and inspect them later.
>>>
>>> For the main kernel, this allows the size of various sections to be
>>> determined via objdump -h.  This also aids objdump -d and -s usage
>>> when asking it to target a particular section.
>>>
>>> For the decompressor, it means that it is now trivially possible to copy
>>> out the compressed kernel vmlinux image by:
>>>
>>>   arm-linux-objcopy -O binary -j .piggydata arch/arm/boot/compressed/vmlinux \
>>> 	piggy.gz
>>>
>>> and thereby obtain the binary kernel image (the Image file) which was
>>> originally used.
>>
>> I gave this series a test with my poison initmem patch and all looks well
>>
>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>>
>> except for patch 2 as I didn't use a zImage.
>
> Oh, what did you use instead?  I thought no one used the Image files
> anymore...

I used an Image. Android bootloaders are perfectly fine booting those.
Plus, the zreladdr for every MSM post 7x00a isn't upstream.

Which reminds me, the zreladdr for every MSM besides 7x00a and 8x50 is
0xX0208000 which doesn't play nicely with AUTO_ZRELADDR. I wish we could
fix that.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 0/7] Re-organize linker layouts

[Russell King - ARM Linux]

On Thu, Jul 07, 2011 at 05:55:51PM -0700, Stephen Boyd wrote:
> On 07/07/2011 03:36 PM, Russell King - ARM Linux wrote:
> > Oh, what did you use instead?  I thought no one used the Image files
> > anymore...
> 
> I used an Image. Android bootloaders are perfectly fine booting those.
> Plus, the zreladdr for every MSM post 7x00a isn't upstream.

Ah, ok.  Thanks for letting me know and thanks for the tested-by.

> Which reminds me, the zreladdr for every MSM besides 7x00a and 8x50 is
> 0xX0208000 which doesn't play nicely with AUTO_ZRELADDR. I wish we could
> fix that.

And there's probably platforms which need it the existing way...

There's also platforms where the zImage is loaded at some predetermined
offset into RAM to give the decompressor room to directly place the
kernel in its final location too, which will be buggered by
AUTO_ZRELADDR.

[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:

> There's also platforms where the zImage is loaded at some predetermined
> offset into RAM to give the decompressor room to directly place the
> kernel in its final location too, which will be buggered by
> AUTO_ZRELADDR.

How so?  Loading that zImage at the same predetermined offset will still 
have the same desired effect.  As long as the offset is within 128MB of 
the start of RAM.


Nicolas

[PATCH 0/7] Re-organize linker layouts

[Russell King - ARM Linux]

On Fri, Jul 08, 2011 at 09:46:42AM -0400, Nicolas Pitre wrote:
> On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:
> 
> > There's also platforms where the zImage is loaded at some predetermined
> > offset into RAM to give the decompressor room to directly place the
> > kernel in its final location too, which will be buggered by
> > AUTO_ZRELADDR.
> 
> How so?  Loading that zImage at the same predetermined offset will still 
> have the same desired effect.  As long as the offset is within 128MB of 
> the start of RAM.

You just said it...

Given that it's 128MB, Stephen shouldn't have a problem with loading the
zImage at 0xN0208000, but he said it doesn't work.  I think there's some
work to be done there to figure out if Stephen really has a problem, and
what that problem is.

[PATCH 0/7] Re-organize linker layouts

[Stephen Boyd]

On 7/8/2011 9:03 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 08, 2011 at 09:46:42AM -0400, Nicolas Pitre wrote:
>> On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:
>>
>>> There's also platforms where the zImage is loaded at some predetermined
>>> offset into RAM to give the decompressor room to directly place the
>>> kernel in its final location too, which will be buggered by
>>> AUTO_ZRELADDR.
>>
>> How so?  Loading that zImage at the same predetermined offset will still 
>> have the same desired effect.  As long as the offset is within 128MB of 
>> the start of RAM.
>
> You just said it...
>
> Given that it's 128MB, Stephen shouldn't have a problem with loading the
> zImage at 0xN0208000, but he said it doesn't work.  I think there's some
> work to be done there to figure out if Stephen really has a problem, and
> what that problem is.

My problem is due to how the zreladdr is calculated. Our ram starts at
0xN0200000 and loading the zImage at 0xN0208000 works fine, but then
when zreladdr is calculated it essentially aligns PC to 128MB and then
my kernel is loaded at 0xN0008000. I've lost the 2. It looks like other
machines are in a similar situation (or their zImage is loaded somewhere
beyond 128MB and it never works).

Why can't this work via atags (or DT for that matter)? atags have always
said where ram starts and we should be able to write some code that
parses the atags/DT and figures out the final resting place of the
decompressed image.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Fri, 8 Jul 2011, Stephen Boyd wrote:

> On 7/8/2011 9:03 AM, Russell King - ARM Linux wrote:
> > On Fri, Jul 08, 2011 at 09:46:42AM -0400, Nicolas Pitre wrote:
> >> On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:
> >>
> >>> There's also platforms where the zImage is loaded at some predetermined
> >>> offset into RAM to give the decompressor room to directly place the
> >>> kernel in its final location too, which will be buggered by
> >>> AUTO_ZRELADDR.
> >>
> >> How so?  Loading that zImage at the same predetermined offset will still 
> >> have the same desired effect.  As long as the offset is within 128MB of 
> >> the start of RAM.
> >
> > You just said it...
> >
> > Given that it's 128MB, Stephen shouldn't have a problem with loading the
> > zImage at 0xN0208000, but he said it doesn't work.  I think there's some
> > work to be done there to figure out if Stephen really has a problem, and
> > what that problem is.
> 
> My problem is due to how the zreladdr is calculated. Our ram starts at
> 0xN0200000 and loading the zImage at 0xN0208000 works fine, but then
> when zreladdr is calculated it essentially aligns PC to 128MB and then
> my kernel is loaded at 0xN0008000. I've lost the 2. It looks like other
> machines are in a similar situation (or their zImage is loaded somewhere
> beyond 128MB and it never works).

No, it works.  It is just that everyone else has their RAM always 
aligned to something much greater than 2 MB.  In fact, the 128 MB value 
was selected because it was the smallest aligment of RAM placement found 
amongst all the machines in the tree at the time.

> Why can't this work via atags (or DT for that matter)? atags have always
> said where ram starts and we should be able to write some code that
> parses the atags/DT and figures out the final resting place of the
> decompressed image.

Possibly.  But that would be an MSM special case.


Nicolas

[PATCH 0/7] Re-organize linker layouts

[Stephen Boyd]

On 7/8/2011 11:24 AM, Nicolas Pitre wrote:
> On Fri, 8 Jul 2011, Stephen Boyd wrote:
>> Why can't this work via atags (or DT for that matter)? atags have always
>> said where ram starts and we should be able to write some code that
>> parses the atags/DT and figures out the final resting place of the
>> decompressed image.
> Possibly.  But that would be an MSM special case.
>

Hmm. I thought ST-Erricson folks had something similar.

Anyway, maybe we've been going about this the wrong way. Couldn't we
just make TEXT_OFFSET be 0x00208000 and then make sure to remove the
first 2MB of memory in a machine->reserve() routine if we're MSM?

Something like PHYS_OFFSET=0xN0000000 and TEXT_OFFSET=0x00208000 so that
our text ends up at the right place (0xN0208000) and AUTO_ZRELADDR will
be happy. This seems to work as long as I fixup the atags to say memory
starts at 0xN000000 instead of 0xN0200000.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Mon, 11 Jul 2011, Stephen Boyd wrote:

> On 7/8/2011 11:24 AM, Nicolas Pitre wrote:
> > On Fri, 8 Jul 2011, Stephen Boyd wrote:
> >> Why can't this work via atags (or DT for that matter)? atags have always
> >> said where ram starts and we should be able to write some code that
> >> parses the atags/DT and figures out the final resting place of the
> >> decompressed image.
> > Possibly.  But that would be an MSM special case.
> >
> 
> Hmm. I thought ST-Erricson folks had something similar.
> 
> Anyway, maybe we've been going about this the wrong way. Couldn't we
> just make TEXT_OFFSET be 0x00208000 and then make sure to remove the
> first 2MB of memory in a machine->reserve() routine if we're MSM?

I think that would certainly be a worthwhile thing to do.  This would 
even make ARM_PATCH_PHYS_VIRT more efficient as you won't have to enable 
ARM_PATCH_PHYS_VIRT_16BIT anymore.  And even without 
ARM_PATCH_PHYS_VIRT, the compiled code for virt_to_phys() and 
phys_to_virt() would be more efficient.

Whether or not we would like to still keep the ARM_PATCH_PHYS_VIRT_16BIT 
code around is a separate question.

> Something like PHYS_OFFSET=0xN0000000 and TEXT_OFFSET=0x00208000 so that
> our text ends up at the right place (0xN0208000) and AUTO_ZRELADDR will
> be happy. This seems to work as long as I fixup the atags to say memory
> starts at 0xN000000 instead of 0xN0200000.

As long as you are fixing it up in the kernel not in the bootloader, 
given that it is the kernel who is cheating.  The mdesc->fixup callback 
is perfect for that.


Nicolas

[PATCH 0/7] Re-organize linker layouts

[David Brown]

On Mon, Jul 11, 2011 at 06:14:38PM -0400, Nicolas Pitre wrote:

> > Anyway, maybe we've been going about this the wrong way. Couldn't we
> > just make TEXT_OFFSET be 0x00208000 and then make sure to remove the
> > first 2MB of memory in a machine->reserve() routine if we're MSM?
> 
> I think that would certainly be a worthwhile thing to do.  This would 
> even make ARM_PATCH_PHYS_VIRT more efficient as you won't have to enable 
> ARM_PATCH_PHYS_VIRT_16BIT anymore.  And even without 
> ARM_PATCH_PHYS_VIRT, the compiled code for virt_to_phys() and 
> phys_to_virt() would be more efficient.
> 
> Whether or not we would like to still keep the ARM_PATCH_PHYS_VIRT_16BIT 
> code around is a separate question.

Wouldn't it still be needed if people want to build an ARM kernel that
works on both MSM targets and non-MSM targets?

What about loading the kernel at the next 128MB boundary,
and coming up with a way to use the 126MB before the kernel for
allocation.  That might end up being more invasive, though.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Tue, 19 Jul 2011, David Brown wrote:

> On Mon, Jul 11, 2011 at 06:14:38PM -0400, Nicolas Pitre wrote:
> 
> > > Anyway, maybe we've been going about this the wrong way. Couldn't we
> > > just make TEXT_OFFSET be 0x00208000 and then make sure to remove the
> > > first 2MB of memory in a machine->reserve() routine if we're MSM?
> > 
> > I think that would certainly be a worthwhile thing to do.  This would 
> > even make ARM_PATCH_PHYS_VIRT more efficient as you won't have to enable 
> > ARM_PATCH_PHYS_VIRT_16BIT anymore.  And even without 
> > ARM_PATCH_PHYS_VIRT, the compiled code for virt_to_phys() and 
> > phys_to_virt() would be more efficient.
> > 
> > Whether or not we would like to still keep the ARM_PATCH_PHYS_VIRT_16BIT 
> > code around is a separate question.
> 
> Wouldn't it still be needed if people want to build an ARM kernel that
> works on both MSM targets and non-MSM targets?

No.  Only MSM requires this right now, and if this requirement is lifted 
then it won't be needed by anyone else.  The other targets are most 
likely not going to care much about the TEXT_OFFSET value used, as long 
as this doesn't conflict with things like ramdisk placement (but if 
someone wishes to have a single kernel configured for multiple targets, 
then that person should be able to move the ramdisk location if needed).

> What about loading the kernel at the next 128MB boundary,
> and coming up with a way to use the 126MB before the kernel for
> allocation.  That might end up being more invasive, though.

Indeed. And many targets don't even have that amount of memory.


Nicolas

[PATCH 0/7] Re-organize linker layouts

[David Brown]

On Tue, Jul 19, 2011 at 02:02:27PM -0400, Nicolas Pitre wrote:

> > What about loading the kernel at the next 128MB boundary,
> > and coming up with a way to use the 126MB before the kernel for
> > allocation.  That might end up being more invasive, though.
> 
> Indeed. And many targets don't even have that amount of memory.

I wasn't thinking that anything other than MSM would change.  The
kernel would be at a 128MB+0x8000 boundary.  Non-MSM targets would
stay the same, and MSM targets would have the kernel 128MB further in
memory, and reclaim that memory later.

Probably not the best way to do it, and it sounds like Stephen Boyd
has some better ideas, anyway.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.