Re-organize linker layouts

PATCH New Russell King - ARM Linux 4 participants 22 messages Jul 6, 2011 – Jul 19, 2011 Arm (32-bit)

lore

Share & tools

lore

Russell King - ARM Linux

author

2011-07-06 10:22 UTC #0 lore raw

cover Re-organize linker layouts

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.

Russell King - ARM Linux

author

2011-07-06 10:23 UTC #1 lore raw

PATCH 1/7 ARM: ensure tag tables are const

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

Signed-off-by Russell King <[email protected]>

---
 arch/arm/include/asm/setup.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/include/asm/setup.h +1 -1

index ee2ad8a..c3b5c79 100644
@@ -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

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:23 UTC #2 lore raw

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

In reply to 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 <[email protected]>

---
 arch/arm/boot/compressed/vmlinux.lds.in |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

arch/arm/boot/compressed/vmlinux.lds.in +8 -4

index ea80abe..4e72883 100644
@@ -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;

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:23 UTC #3 lore raw

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

In reply to Russell King - ARM Linux

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

Signed-off-by Russell King <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S |   47 +++++++++++++++++++---------------------
 1 files changed, 22 insertions(+), 25 deletions(-)

arch/arm/kernel/vmlinux.lds.S +22 ~~-25~~

index e5287f2..cb46a9b 100644
@@ -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
 }
 
 /*

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:24 UTC #4 lore raw

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

In reply to 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 <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S |   47 +++++++++++++++++++++++++---------------
 1 files changed, 29 insertions(+), 18 deletions(-)

arch/arm/kernel/vmlinux.lds.S +29 ~~-18~~

index cb46a9b..c8bb9b7 100644
@@ -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

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:24 UTC #5 lore raw

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

In reply to Russell King - ARM Linux

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

Signed-off-by Russell King <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

arch/arm/kernel/vmlinux.lds.S +0 -2

index c8bb9b7..fa812d0 100644
@@ -136,8 +136,6 @@ SECTIONS
 			*(.fixup)
 #endif
 			*(.gnu.warning)
-			*(.rodata)
-			*(.rodata.*)
 			*(.glue_7)
 			*(.glue_7t)
 		. = ALIGN(4);

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:24 UTC #6 lore raw

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

In reply to 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 <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S |   96 ++++++++++++++++++++--------------------
 arch/arm/mm/init.c            |    4 +-
 2 files changed, 50 insertions(+), 50 deletions(-)

arch/arm/kernel/vmlinux.lds.S +48 ~~-48~~

index fa812d0..18574b7 100644
@@ -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

arch/arm/mm/init.c +2 -2

index c19571c..b8e8912 100644
@@ -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));

Signature · 1 line

1.7.4.4

Russell King - ARM Linux

author

2011-07-06 10:25 UTC #7 lore raw

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

In reply to 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 <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/kernel/vmlinux.lds.S +2 -2

index 18574b7..bf977f8 100644
@@ -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 = .;

Signature · 1 line

1.7.4.4

Nicolas Pitre

2011-07-06 15:09 UTC #8 lore raw

cover Re-organize linker layouts

In reply to Russell King - ARM Linux

Quoted 12 lines · 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.

Quoted 8 lines

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 <[email protected]>

Nicolas

Stephen Boyd

2011-07-07 17:28 UTC #9 lore raw

cover Re-organize linker layouts

In reply to Russell King - ARM Linux

Quoted 12 lines · 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.

Quoted 8 lines

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 <[email protected]>

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

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.

Russell King - ARM Linux

author

2011-07-07 22:36 UTC #10 lore raw

cover Re-organize linker layouts

Quoted 19 lines · Stephen Boyd

Quoted 18 lines · 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

Quoted 8 lines

Quoted 2 lines
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 <[email protected]>
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...

Stephen Boyd

2011-07-08 00:55 UTC #11 lore raw

cover Re-organize linker layouts

Quoted 23 lines · Russell King - ARM Linux

Quoted 22 lines · Stephen Boyd
Quoted 20 lines · 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.

Quoted 8 lines

Quoted 5 lines
I gave this series a test with my poison initmem patch and all looks well
Tested-by Stephen Boyd <[email protected]>
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.

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.

Russell King - ARM Linux

author

2011-07-08 09:07 UTC #12 lore raw

cover Re-organize linker layouts

Quoted 6 lines · Stephen Boyd

Quoted 2 lines · Russell King - ARM Linux
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.

Quoted 3 lines

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.

Nicolas Pitre

2011-07-08 13:46 UTC #13 lore raw

cover Re-organize linker layouts

Quoted 4 lines · Russell King - ARM Linux

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

Russell King - ARM Linux

author

2011-07-08 16:03 UTC #14 lore raw

cover Re-organize linker layouts

Quoted 10 lines · Nicolas Pitre

Quoted 4 lines · Russell King - ARM Linux
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.

Stephen Boyd

2011-07-08 16:56 UTC #15 lore raw

cover Re-organize linker layouts

Quoted 12 lines · Russell King - ARM Linux

Quoted 10 lines · Nicolas Pitre
Quoted 4 lines · Russell King - ARM Linux
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.

Quoted 6 lines

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.

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.

Nicolas Pitre

2011-07-08 18:24 UTC #16 lore raw

cover Re-organize linker layouts

Quoted 20 lines · Stephen Boyd

Quoted 12 lines · Russell King - ARM Linux
Quoted 10 lines · Nicolas Pitre
Quoted 4 lines · Russell King - ARM Linux
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.
Quoted 6 lines
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.

Quoted 6 lines

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.

Quoted 4 lines

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

Stephen Boyd

2011-07-11 20:17 UTC #17 lore raw

cover Re-organize linker layouts

Quoted 7 lines · Nicolas Pitre

Quoted 4 lines · Stephen Boyd
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.

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.

Nicolas Pitre

2011-07-11 22:14 UTC #18 lore raw

cover Re-organize linker layouts

Quoted 6 lines · Stephen Boyd

Quoted 5 lines · Nicolas Pitre
Quoted 4 lines · Stephen Boyd
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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 4 lines

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

David Brown

2011-07-19 17:22 UTC #19 lore raw

cover Re-organize linker layouts

Quoted 4 lines · Nicolas Pitre

Quoted 3 lines
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?

Quoted 8 lines

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

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.

Nicolas Pitre

2011-07-19 18:02 UTC #20 lore raw

cover Re-organize linker layouts

Quoted 12 lines · David Brown

Quoted 10 lines · Nicolas Pitre
Quoted 3 lines
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.

Quoted 5 lines

Quoted 2 lines
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).

Quoted 3 lines

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

David Brown

2011-07-19 20:42 UTC #21 lore raw

cover Re-organize linker layouts

Quoted 5 lines · Nicolas Pitre

Quoted 3 lines
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

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.