The patch titled
i386: Implement CONFIG_PHYSICAL_ALIGN
has been removed from the -mm tree. Its filename is
i386-implement-config_physical_align.patch
This patch was dropped because it had testing failures
------------------------------------------------------
Subject: i386: Implement CONFIG_PHYSICAL_ALIGN
From: Vivek Goyal <vgoyal@xxxxxxxxxx>
o Now CONFIG_PHYSICAL_START is being replaced with CONFIG_PHYSICAL_ALIGN.
Hardcoding the kernel physical start value creates a problem in relocatable
kernel context due to boot loader limitations. For ex, if somebody
compiles a relocatable kernel to be run from address 4MB, but this kernel
will run from location 1MB as grub loads the kernel at physical address
1MB. Kernel thinks that I am a relocatable kernel and I should run from
the address I have been loaded at. So somebody wanting to run kernel
from 4MB alignment location (for improved performance regions) can't do
that.
o Hence, Eric proposed that probably CONFIG_PHYSICAL_ALIGN will make
more sense in relocatable kernel context. At run time kernel will move
itself to a physical addr location which meets user specified alignment
restrictions.
Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
Cc: Andi Kleen <ak@xxxxxx>
DESC
i386 boot: Add an ELF header to bzImage
EDESC
Increasingly the cobbled together boot protocol that is bzImage does not have
the flexibility to deal with booting in new situations.
Now that we no longer support the bootsector loader we have 512 bytes at the
very start of a bzImage that we can use for other things.
Placing an ELF header there allows us to retain a single binary for all of x86
while at the same time describing things that bzImage does not allow us to
describe.
The existing bugger off code for warning if we attempt to boot from the
bootsector is kept but the error message is made more terse so we have a
little more room to play with.
Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
Cc: Andi Kleen <ak@xxxxxx>
Acked-by: "H. Peter Anvin" <hpa@xxxxxxxxx>
DESC
i386 boot: Add an ELF header to bzImage (fix)
EDESC
On Wed, Oct 04, 2006 at 01:08:56AM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@xxxxxxxxxx> writes:
>
> > Increasingly the cobbled together boot protocol that
> > is bzImage does not have the flexibility to deal
> > with booting in new situations.
> >
> > Now that we no longer support the bootsector loader
> > we have 512 bytes at the very start of a bzImage that
> > we can use for other things.
> >
> > Placing an ELF header there allows us to retain
> > a single binary for all of x86 while at the same
> > time describing things that bzImage does not allow
> > us to describe.
> >
> > The existing bugger off code for warning if we attempt to
> > boot from the bootsector is kept but the error message is
> > made more terse so we have a little more room to play with.
>
> Vivek for this first round can we please take out the ELF
> note processing. Now that vmlinux has ELF notes of interest
> to the bootloader we really should be getting the ELF notes
> from there.
>
> So the generation of the ELF notes needs to move into the
> vmlinux and then we need to copy them to ELF header.
>
> If we just remove the ELF note munging code from this patch
> that should be a good first step in getting the ELF notes correct.
Please find attached the patch. I have got rid the ELF note code
from the patch.
Andrew, does this fix your boot issue with grub? What's the grub version
you are using?
Thanks
Vivek
Increasingly the cobbled together boot protocol that
is bzImage does not have the flexibility to deal
with booting in new situations.
Now that we no longer support the bootsector loader
we have 512 bytes at the very start of a bzImage that
we can use for other things.
Placing an ELF header there allows us to retain
a single binary for all of x86 while at the same
time describing things that bzImage does not allow
us to describe.
The existing bugger off code for warning if we attempt to
boot from the bootsector is kept but the error message is
made more terse so we have a little more room to play with.
Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
DESC
i386 boot: Add an ELF header to bzImage (udpate 2)
EDESC
Ok. I changed virtual address to LOAD_PHYSICAL_ADDR. Please find attached
the regenrated patch.
Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
DESC
i386 boot: Add an ELF header to bzImage (fix 2)
EDESC
Signed-off-by: Eric Biederman <ebiederm@xxxxxxxxxxxx>
DESC
i386-boot-add-an-elf-header-to-bzimage fix 3
EDESC
I have added cld in the regenerated patch below.
Also one more minor nit. stosb relies on being %es set properly. By the
time control reaches loader_ok, i could not find %es being set explicitly
hence I am assuming we are relying on bootloader to set it up for us.
Maybe we can be little more paranoid and setup the %es before stosb. I
have done this change too in the attached patch. Pleaese have a look.
I know little about assembly code.
In the lazy programmer school of fixes.
I haven't really tested this in any configuration.
But reading video.S it does use variable in the bootsector.
It does seem to initialize the variables before use.
But obviously something is missed.
By zeroing the uninteresting parts of the bootsector just after we
have determined we are loaded ok. We should ensure we are
always in a known state the entire time.
Andrew if I am right about the cause of your video not working
when you set an enhanced video mode this should fix your boot
problem.
Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
Cc: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
arch/i386/Kconfig | 33 +++++++++++++++--------------
arch/i386/boot/compressed/head.S | 26 ++++++++++++----------
arch/i386/boot/compressed/misc.c | 7 +++---
arch/i386/kernel/vmlinux.lds.S | 3 +-
include/asm-i386/boot.h | 6 ++++-
5 files changed, 43 insertions(+), 32 deletions(-)
diff -puN arch/i386/Kconfig~i386-implement-config_physical_align arch/i386/Kconfig
--- a/arch/i386/Kconfig~i386-implement-config_physical_align
+++ a/arch/i386/Kconfig
@@ -806,23 +806,26 @@ config RELOCATABLE
must live at a different physical address than the primary
kernel.
-config PHYSICAL_START
- hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
-
- default "0x1000000" if CRASH_DUMP
+config PHYSICAL_ALIGN
+ hex "Alignment value to which kernel should be aligned"
default "0x100000"
+ range 0x2000 0x400000
help
- This gives the physical address where the kernel is loaded. Normally
- for regular kernels this value is 0x100000 (1MB). But in the case
- of kexec on panic the fail safe kernel needs to run at a different
- address than the panic-ed kernel. This option is used to set the load
- address for kernels used to capture crash dump on being kexec'ed
- after panic. The default value for crash dump kernels is
- 0x1000000 (16MB). This can also be set based on the "X" value as
- specified in the "crashkernel=YM@XM" command line boot parameter
- passed to the panic-ed kernel. Typically this parameter is set as
- crashkernel=64M@16M. Please take a look at
- Documentation/kdump/kdump.txt for more details about crash dumps.
+ This value puts the alignment restrictions on physical address
+ where kernel is loaded and run from. Kernel is compiled for an
+ address which meets above alignment restriction.
+
+ If bootloader loads the kernel at a non-aligned address and
+ CONFIG_RELOCATABLE is set, kernel will move itself to nearest
+ address aligned to above value and run from there.
+
+ If bootloader loads the kernel at a non-aligned address and
+ CONFIG_RELOCATABLE is not set, kernel will ignore the run time
+ load address and decompress itself to the address it has been
+ compiled for and run from there. The address for which kernel is
+ compiled already meets above alignment restrictions. Hence the
+ end result is that kernel runs from a physical address meeting
+ above alignment restrictions.
Don't change this unless you know what you are doing.
diff -puN arch/i386/boot/compressed/head.S~i386-implement-config_physical_align arch/i386/boot/compressed/head.S
--- a/arch/i386/boot/compressed/head.S~i386-implement-config_physical_align
+++ a/arch/i386/boot/compressed/head.S
@@ -26,6 +26,7 @@
#include <linux/linkage.h>
#include <asm/segment.h>
#include <asm/page.h>
+#include <asm/boot.h>
.section ".text.head"
.globl startup_32
@@ -52,17 +53,17 @@ startup_32:
1: popl %ebp
subl $1b, %ebp
-/* Compute the delta between where we were compiled to run at
- * and where the code will actually run at.
+/* %ebp contains the address we are loaded at by the boot loader and %ebx
+ * contains the address where we should move the kernel image temporarily
+ * for safe in-place decompression.
*/
- /* Start with the delta to where the kernel will run at. If we are
- * a relocatable kernel this is the delta to our load address otherwise
- * this is the delta to CONFIG_PHYSICAL start.
- */
+
#ifdef CONFIG_RELOCATABLE
- movl %ebp, %ebx
+ movl %ebp, %ebx
+ addl $(CONFIG_PHYSICAL_ALIGN - 1), %ebx
+ andl $(~(CONFIG_PHYSICAL_ALIGN - 1)), %ebx
#else
- movl $(CONFIG_PHYSICAL_START - startup_32), %ebx
+ movl $LOAD_PHYSICAL_ADDR, %ebx
#endif
/* Replace the compressed data size with the uncompressed size */
@@ -94,9 +95,10 @@ startup_32:
/* Compute the kernel start address.
*/
#ifdef CONFIG_RELOCATABLE
- leal startup_32(%ebp), %ebp
+ addl $(CONFIG_PHYSICAL_ALIGN - 1), %ebp
+ andl $(~(CONFIG_PHYSICAL_ALIGN - 1)), %ebp
#else
- movl $CONFIG_PHYSICAL_START, %ebp
+ movl $LOAD_PHYSICAL_ADDR, %ebp
#endif
/*
@@ -150,8 +152,8 @@ relocated:
* and where it was actually loaded.
*/
movl %ebp, %ebx
- subl $CONFIG_PHYSICAL_START, %ebx
-
+ subl $LOAD_PHYSICAL_ADDR, %ebx
+ jz 2f /* Nothing to be done if loaded at compiled addr. */
/*
* Process relocations.
*/
diff -puN arch/i386/boot/compressed/misc.c~i386-implement-config_physical_align arch/i386/boot/compressed/misc.c
--- a/arch/i386/boot/compressed/misc.c~i386-implement-config_physical_align
+++ a/arch/i386/boot/compressed/misc.c
@@ -14,6 +14,7 @@
#include <linux/screen_info.h>
#include <asm/io.h>
#include <asm/page.h>
+#include <asm/boot.h>
/* WARNING!!
* This code is compiled with -fPIC and it is relocated dynamically
@@ -360,12 +361,12 @@ asmlinkage void decompress_kernel(void *
insize = input_len;
inptr = 0;
- if (((u32)output - CONFIG_PHYSICAL_START) & 0x3fffff)
- error("Destination address not 4M aligned");
+ if ((u32)output & (CONFIG_PHYSICAL_ALIGN -1))
+ error("Destination address not CONFIG_PHYSICAL_ALIGN aligned");
if (end > ((-__PAGE_OFFSET-(512 <<20)-1) & 0x7fffffff))
error("Destination address too large");
#ifndef CONFIG_RELOCATABLE
- if ((u32)output != CONFIG_PHYSICAL_START)
+ if ((u32)output != LOAD_PHYSICAL_ADDR)
error("Wrong destination address");
#endif
diff -puN arch/i386/kernel/vmlinux.lds.S~i386-implement-config_physical_align arch/i386/kernel/vmlinux.lds.S
--- a/arch/i386/kernel/vmlinux.lds.S~i386-implement-config_physical_align
+++ a/arch/i386/kernel/vmlinux.lds.S
@@ -8,6 +8,7 @@
#include <asm/thread_info.h>
#include <asm/page.h>
#include <asm/cache.h>
+#include <asm/boot.h>
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
@@ -21,7 +22,7 @@ PHDRS {
}
SECTIONS
{
- . = LOAD_OFFSET + CONFIG_PHYSICAL_START;
+ . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
phys_startup_32 = startup_32 - LOAD_OFFSET;
/* read-only */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
diff -puN include/asm-i386/boot.h~i386-implement-config_physical_align include/asm-i386/boot.h
--- a/include/asm-i386/boot.h~i386-implement-config_physical_align
+++ a/include/asm-i386/boot.h
@@ -12,4 +12,8 @@
#define EXTENDED_VGA 0xfffe /* 80x50 mode */
#define ASK_VGA 0xfffd /* ask for it at bootup */
-#endif
+/* Physical address where kenrel should be loaded. */
+#define LOAD_PHYSICAL_ADDR ((0x100000 + CONFIG_PHYSICAL_ALIGN - 1) \
+ & ~(CONFIG_PHYSICAL_ALIGN - 1))
+
+#endif /* _LINUX_BOOT_H */
_
Patches currently in -mm which might be from vgoyal@xxxxxxxxxx are
x86_64-overlapping-program-headers-in-physical-addr-space-fix.patch
i386-implement-config_physical_align.patch
i386-boot-add-an-elf-header-to-bzimage.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
