o Relocatable bzImage support had got rid of CONFIG_PHYSICAL_START option
thinking that now this option is not required as people can build a
second kernel as relocatable and load it anywhere. So need of compiling
the kernel for a custom address was gone. But Magnus uses vmlinux images
for second kernel in Xen environment and he wants to continue to use
it.
o Restoring the CONFIG_PHYSICAL_START option for the time being. I think
down the line we can get rid of it.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
arch/i386/Kconfig | 41 +++++++++++++++++++++++++++++++++++++++++
include/asm-i386/boot.h | 3 ++-
2 files changed, 43 insertions(+), 1 deletion(-)
diff -puN arch/i386/Kconfig~i386-restore-CONFIG_PHYSICAL_START-option
arch/i386/Kconfig
---
linux-2.6.20-rc2-reloc/arch/i386/Kconfig~i386-restore-CONFIG_PHYSICAL_START-option
2006-12-27 16:22:30.000000000 +0530
+++ linux-2.6.20-rc2-reloc-root/arch/i386/Kconfig 2006-12-27
16:48:30.000000000 +0530
@@ -777,6 +777,47 @@ config CRASH_DUMP
PHYSICAL_START.
For more details see Documentation/kdump/kdump.txt
+config PHYSICAL_START
+ hex "Physical address where the kernel is loaded" if (EMBEDDED ||
CRASH_DUMP)
+ default "0x100000"
+ help
+ This gives the physical address where the kernel is loaded.
+
+ If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
+ bzImage will decompress itself to above physical address and
+ run from there. Otherwise, bzImage will run from the address where
+ it has been loaded by the boot loader and will ignore above physical
+ address.
+
+ In normal kdump cases one does not have to set/change this option
+ as now bzImage can be compiled as a completely relocatable image
+ (CONFIG_RELOCATABLE=y) and be used to load and run from a different
+ address. This option is mainly useful for the folks who don't want
+ to use a bzImage for capturing the crash dump and want to use a
+ vmlinux instead. vmlinux is not relocatable hence a kernel needs
+ to be specifically compiled to run from a specific memory area
+ (normally a reserved region) and this option comes handy.
+
+ So if you are using bzImage for capturing the crash dump, leave
+ the value here unchanged to 0x100000 and set CONFIG_RELOCATABLE=y.
+ Otherwise if you plan to use vmlinux for capturing the crash dump
+ change this value to start of the reserved region (Typically 16MB
+ 0x1000000). In other words, it can be set based on the "X" value as
+ specified in the "[EMAIL PROTECTED]" command line boot parameter
+ passed to the panic-ed kernel. Typically this parameter is set as
+ [EMAIL PROTECTED] Please take a look at
+ Documentation/kdump/kdump.txt for more details about crash dumps.
+
+ Usage of bzImage for capturing the crash dump is recommended as
+ one does not have to build two kernels. Same kernel can be used
+ as production kernel and capture kernel. Above option should have
+ gone away after relocatable bzImage support is introduced. But it
+ is present because there are users out there who continue to use
+ vmlinux for dump capture. This option should go away down the
+ line.
+
+ Don't change this unless you know what you are doing.
+
config RELOCATABLE
bool "Build a relocatable kernel(EXPERIMENTAL)"
depends on EXPERIMENTAL
diff -puN include/asm-i386/boot.h~i386-restore-CONFIG_PHYSICAL_START-option
include/asm-i386/boot.h
---
linux-2.6.20-rc2-reloc/include/asm-i386/boot.h~i386-restore-CONFIG_PHYSICAL_START-option
2006-12-27 16:22:30.000000000 +0530
+++ linux-2.6.20-rc2-reloc-root/include/asm-i386/boot.h 2006-12-27
16:22:30.000000000 +0530
@@ -13,7 +13,8 @@
#define ASK_VGA 0xfffd /* ask for it at bootup */
/* Physical address where kenrel should be loaded. */
-#define LOAD_PHYSICAL_ADDR ((0x100000 + CONFIG_PHYSICAL_ALIGN - 1) \
+#define LOAD_PHYSICAL_ADDR ((CONFIG_PHYSICAL_START \
+ + (CONFIG_PHYSICAL_ALIGN - 1)) \
& ~(CONFIG_PHYSICAL_ALIGN - 1))
#endif /* _LINUX_BOOT_H */
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
