VMSPLIT.patch problems?

[Troy Davis]

Hello-
   I am using the VMSPLIT.patch (see below) to split the memory space 
into 2G/2G versus the normal 3G/1G.  I am currently trying to boot using 
an initrd image in a diskless configuration (non-network) using Grub 0.96:

root (hd0,0)
uppermem 720896
kernel /boot/bzImage-2.6.15.4.PIV.vmsplit.smp.flash.rt root=/dev/ram0 
mem=704M rw
initrd /boot/initrd.gz

   The machine has 1G of memory, of which the top portion is set aside 
at boot for framegrabber DMA.  A flash device contains the kernel image 
along with the initrd.gz image (/dev/hda1 ext2fs).  The problem I am 
having is the kernel does not appear to be recognizing the initrd image 
(kernel is getting to the end of boot stating unable to find init).  I 
have tried root=/dev/ram, also with and without a linuxrc script in the 
initrd's root, with and without init= (pointed to /sbin/init, 
/linuxrc).   My question is: is the VMSPLIT.patch below mucking up the 
location being passed to the kernel by grub for the initrd image?

Best Regards,
Troy

diff -u --recursive --new-file --exclude='.*' 
linux-2.6.15/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-2.6.15/arch/i386/Kconfig      2006-01-02 22:21:10.000000000 -0500
+++ linux/arch/i386/Kconfig     2006-01-10 12:02:40.000000000 -0500
@@ -448,6 +448,43 @@

 endchoice

+choice
+       depends on EXPERIMENTAL && !X86_PAE
+       prompt "Memory split"
+       default VMSPLIT_3G
+       help
+         Select the desired split between kernel and user memory.
+
+         If the address range available to the kernel is less than the
+         physical memory installed, the remaining memory will be available
+         as "high memory". Accessing high memory is a little more costly
+         than low memory, as it needs to be mapped into the kernel first.
+         Note that increasing the kernel address space limits the range
+         available to user programs, making the address space there
+         tighter.  Selecting anything other than the default 3G/1G split
+         will also likely make your kernel incompatible with binary-only
+         kernel modules.
+
+         If you are not absolutely sure what you are doing, leave this
+         option alone!
+
+       config VMSPLIT_3G
+               bool "3G/1G user/kernel split"
+       config VMSPLIT_3G_OPT
+               bool "3G/1G user/kernel split (for full 1G low memory)"
+       config VMSPLIT_2G
+               bool "2G/2G user/kernel split"
+       config VMSPLIT_1G
+               bool "1G/3G user/kernel split"
+endchoice
+
+config PAGE_OFFSET
+       hex
+       default 0xB0000000 if VMSPLIT_3G_OPT
+       default 0x78000000 if VMSPLIT_2G
+       default 0x40000000 if VMSPLIT_1G
+       default 0xC0000000
+
 config HIGHMEM
       bool
       depends on HIGHMEM64G || HIGHMEM4G
diff -u --recursive --new-file --exclude='.*' 
linux-2.6.15/include/asm-i386/page.h linux/include/asm-i386/page.h
--- linux-2.6.15/include/asm-i386/page.h        2006-01-02 
22:21:10.000000000 -0500
+++ linux/include/asm-i386/page.h       2006-01-10 12:04:56.000000000 -0500
@@ -110,10 +110,10 @@
 #endif /* __ASSEMBLY__ */

 #ifdef __ASSEMBLY__
-#define __PAGE_OFFSET          (0xC0000000)
+#define __PAGE_OFFSET          CONFIG_PAGE_OFFSET
 #define __PHYSICAL_START      CONFIG_PHYSICAL_START
 #else
-#define __PAGE_OFFSET          (0xC0000000UL)
+#define __PAGE_OFFSET          ((unsigned long)CONFIG_PAGE_OFFSET)
 #define __PHYSICAL_START      ((unsigned long)CONFIG_PHYSICAL_START)
 #endif
 #define __KERNEL_START                (__PAGE_OFFSET + __PHYSICAL_START)