Skip to contentSkip to conversation

sh: include empty zero page in zImage

PATCH In review Magnus Damm 3 participants 4 messages Dec 3, 2009 SuperH

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sh: include empty zero page in zImage

From: Magnus Damm <[email protected]>

Include the empty zero page data in the zImage.
Without this patch the empty zero page may be
uninitialized.

---

I suppose we should have a fallback option to allow boot loaders passing data in the zero page. Or perhaps doing it the other way around is better.

 arch/sh/boot/compressed/Makefile |    2 --
 arch/sh/boot/compressed/misc.c   |    2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
arch/sh/boot/compressed/Makefile +0 -2
@@ -48,8 +48,6 @@ $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.al
 $(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
 	$(call if_changed,lzma)
 
-OBJCOPYFLAGS += -R .empty_zero_page
-
 LDFLAGS_piggy.o := -r --format binary --oformat $(ld-bfd) -T
 
 $(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix-y) FORCE
arch/sh/boot/compressed/misc.c +1 -1
@@ -131,7 +131,7 @@ void decompress_kernel(void)
 #ifdef CONFIG_SUPERH64
 	output_addr = (CONFIG_MEMORY_START + 0x2000);
 #else
-	output_addr = __pa((unsigned long)&_text+PAGE_SIZE);
+	output_addr = __pa((unsigned long)&_text);
 #ifdef CONFIG_29BIT
 	output_addr |= P2SEG;
 #endif
#1 lore raw

Magnus

If you do this won't you overwrite any parameters from the boot loader?

Stuart

Quoted 44 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Include the empty zero page data in the zImage.
Without this patch the empty zero page may be
uninitialized.

---

I suppose we should have a fallback option to allow boot loaders passing data in the zero page. Or perhaps doing it the other way around is better.

 arch/sh/boot/compressed/Makefile |    2 --
 arch/sh/boot/compressed/misc.c   |    2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
arch/sh/boot/compressed/Makefile +0 -2
@@ -48,8 +48,6 @@ $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.al
 $(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
 	$(call if_changed,lzma)
 
-OBJCOPYFLAGS += -R .empty_zero_page
-
 LDFLAGS_piggy.o := -r --format binary --oformat $(ld-bfd) -T
 
 $(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix-y) FORCE
arch/sh/boot/compressed/misc.c +1 -2
@@ -131,7 +131,7 @@ void decompress_kernel(void)
 #ifdef CONFIG_SUPERH64
 	output_addr = (CONFIG_MEMORY_START + 0x2000);
 #else
-	output_addr = __pa((unsigned long)&_text+PAGE_SIZE);
+	output_addr = __pa((unsigned long)&_text);
 #ifdef CONFIG_29BIT
 	output_addr |= P2SEG;
 #endif
--

To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Magnus Damm

Hi Stuart,

Quoted 1 line · Stuart MENEFY

If you do this won't you overwrite any parameters from the boot loader?

True, so we probably want to do this in a different way.

I don't want to break anything of course, but I'm not sure if u-boot supports passing parameters to zImages. It's not a u-boot centric world though.

I remember adding command line passing code to kexec-tools for either vmlinux or zImage, but I doubt that both image types are properly supported in kexec today.

Any ideas? How are things for ST? I need to fix up romImage somehow at least. Maybe zImage should be left alone as-is and work should be put into fixing the boot loaders.

Cheers,

/ magnus

#3 lore raw
In reply to Magnus Damm
Quoted 11 lines · Magnus Damm

Hi Stuart,

Quoted 1 line · Stuart MENEFY

If you do this won't you overwrite any parameters from the boot loader?

True, so we probably want to do this in a different way.

I don't want to break anything of course, but I'm not sure if u-boot supports passing parameters to zImages. It's not a u-boot centric world though.

Quoted 8 lines

I remember adding command line passing code to kexec-tools for either vmlinux or zImage, but I doubt that both image types are properly supported in kexec today.

Any ideas? How are things for ST? I need to fix up romImage somehow at least. Maybe zImage should be left alone as-is and work should be put into fixing the boot loaders.

Yes, it is the boot loader that is broken, as it doesen't comply with the boot ABI. We will not be applying any patches to the kernel to work around boot loader laziness. The romImage case is a special one, similar to XIP, and that's something that the current argument passing scheme wasn't intended for. On the other hand, you can easily do what all of the other boot loaders do and wrap the zImage while inserting the argument page immediately following it.

I'm quite frankly amazed at the number of patches that have shown up to work around this "problem" in multiple ways. It's called an ABI for a reason folks, if you don't want to support it properly, don't be surprised when things blow up.