How to load 2.6.22 kernel (image too large to fit ...)

How to load 2.6.22 kernel (image too large to fit ...)

[Krzysztof Helt]

Hi,

I have tried to load the latest 2.6.22-rc1 and failed miserably.
I got 2.6MB kernel after modularization and famous "strip -R.
note -R .commend" trick. Nevertheless, it is still too big.

I upgrades SILO to 1.4.13 and still no luck.

Any hints? Are there any silo patches to allow bigger kernels.

Regards,
Krzysztof

----------------------------------------------------
Esej Michela Houellebecqa o Samotniku z Providence 
"H.P Lovecraft. Przeciw ¶wiatu, przeciw ¿yciu" ju¿ w ksiegarniach!
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd105.html&sid\x1146

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Jan Engelhardt]

On May 18 2007 07:50, Krzysztof Helt wrote:
>
>Hi,
>
>I have tried to load the latest 2.6.22-rc1 and failed miserably.
>I got 2.6MB kernel after modularization and famous "strip -R.
>note -R .commend" trick. Nevertheless, it is still too big.

08:05 sun:/boot # l
-rwxr-xr-x  1 root root 3655632 Mar 26 16:53 vmlinuz-2.6.20-1.2986.al3.3smp

No problems booting that on a E250. SILO is 1.4.13 too.

>I upgrades SILO to 1.4.13 and still no luck.
>Any hints? Are there any silo patches to allow bigger kernels.

`make bzImage` to build a kernel (rather than make zImage),
but I suppose you already have that :-/


	Jan
-- 

Re: How to load 2.6.22 kernel (image too large to fit ...)

[David Miller]

From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
Date: Fri, 18 May 2007 07:50:31 +0200

> I have tried to load the latest 2.6.22-rc1 and failed miserably.
> I got 2.6MB kernel after modularization and famous "strip -R.
> note -R .commend" trick. Nevertheless, it is still too big.
> 
> I upgrades SILO to 1.4.13 and still no luck.
> 
> Any hints? Are there any silo patches to allow bigger kernels.

Sparc64 can handle up to ~10.5MB kernels, so I guess you are
on sparc32?

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Krzysztof Helt]

Dnia 18-05-2007 o godz. 8:43 David Miller napisa³(a):
> From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
> Date: Fri, 18 May 2007 07:50:31 +0200
> 
> > I have tried to load the latest 2.6.22-rc1 and failed miserably.
> > I got 2.6MB kernel after modularization and famous "strip -R.
> > note -R .commend" trick. Nevertheless, it is still too big.
> > 
> > I upgrades SILO to 1.4.13 and still no luck.
> > 
> > Any hints? Are there any silo patches to allow bigger kernels.
> 
> Sparc64 can handle up to ~10.5MB kernels, so I guess you are
> on sparc32?

Exactly, I tried on sparc32 (SS20). Is it solvable in any way
except hacking the silo? I don't know how hack it yet.

Regards,
Krzysztof

----------------------------------------------------
Esej Michela Houellebecqa o Samotniku z Providence 
"H.P Lovecraft. Przeciw ¶wiatu, przeciw ¿yciu" ju¿ w ksiegarniach!
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd105.html&sid\x1146

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Tom "spot" Callaway]

On Fri, 2007-05-18 at 11:14 +0200, Krzysztof Helt wrote:
> Dnia 18-05-2007 o godz. 8:43 David Miller napisał(a):
> > From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
> > Date: Fri, 18 May 2007 07:50:31 +0200
> > 
> > > I have tried to load the latest 2.6.22-rc1 and failed miserably.
> > > I got 2.6MB kernel after modularization and famous "strip -R.
> > > note -R .commend" trick. Nevertheless, it is still too big.
> > > 
> > > I upgrades SILO to 1.4.13 and still no luck.
> > > 
> > > Any hints? Are there any silo patches to allow bigger kernels.
> > 
> > Sparc64 can handle up to ~10.5MB kernels, so I guess you are
> > on sparc32?
> 
> Exactly, I tried on sparc32 (SS20). Is it solvable in any way
> except hacking the silo? I don't know how hack it yet.

Turn off things in your kernel? Modularize things where possible?

~spot

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Krzysztof Helt]

Hi again,

I overcame the problem with too big kernel with the attached patch, but 
I run into another problem. Now, the silo says:

"Your kernel cannot fit into the memory destination. This
can be resolved by recompiling the kernel with more devices
built as modules, or upgrading your kernel to one that
supports being loaded to higher memory areas (currently
2.6.3+ or 2.4.26+)."

Does it mean, that 2.6.22-rc1 for sparc32 cannot be relocated?

Regards,
Krzysztof

PS. The patch maps 8MB or 4MB of memory for kernel like for the sparc64 
kernel.

------------------------------------------------------------------------

diff -urp silo-1.4.13/second/main.c silo-1.4.13.new/second/main.c
--- silo-1.4.13/second/main.c	2006-06-01 19:24:53.000000000 +0200
+++ silo-1.4.13.new/second/main.c	2007-05-18 23:04:51.000000000 +0200
@@ -1272,6 +1273,7 @@ try_again:
 		       "built as modules, or upgrading your kernel to one that\n"
 		       "supports being loaded to higher memory areas (currently\n"
 		       "2.6.3+ or 2.4.26+).\n");
+		image_memory_release();
 		goto try_again;
 	    }
 
diff -urp silo-1.4.13/second/memory.c silo-1.4.13.new/second/memory.c
--- silo-1.4.13/second/memory.c	2006-06-01 19:24:53.000000000 +0200
+++ silo-1.4.13.new/second/memory.c	2007-05-18 23:02:04.000000000 +0200
@@ -271,6 +271,131 @@ not_found:
     return (char *)0;
 }
 
+static unsigned long long sun4m_image_virt, sun4m_image_len, sun4m_image_phys;
+static unsigned long long sun4m_initrd_virt, sun4m_initrd_len;
+unsigned long long sun4m_initrd_phys;
+
+static char *sun4m_memory_find (unsigned int len, int is_kernel)
+{
+	int n, node, i;
+	unsigned int virt = (is_kernel ? IMAGE_VIRT_ADDR : INITRD_VIRT_ADDR);
+	unsigned long phys = 0, phys_base;
+	unsigned long virt2 = 0;
+	unsigned int iter, num_regs;
+
+	/* Grrr, have to traverse the prom device tree ;( */
+	node = prom_getchild (prom_root_node);
+	node = prom_searchsiblings (node, "memory");
+	num_regs = prom_getproperty (node, "available",
+				     (char *) prom_reg_memlist,
+				     sizeof (prom_reg_memlist));
+	n = (num_regs / sizeof (struct linux_prom_registers));
+
+	phys = 0;
+	phys_base = ~(unsigned long)0;
+	for (iter = 0; iter < num_regs; iter++) {
+	    prom_phys_avail[iter].start_adr +		prom_reg_memlist[iter].phys_addr;
+	    prom_phys_avail[iter].num_bytes +		(unsigned long) prom_reg_memlist[iter].reg_size;
+	    prom_phys_avail[iter].theres_more +		&prom_phys_avail[iter + 1];
+	}
+	for (i = 0; i < n; i++) {
+		if ((unsigned long)prom_phys_avail[i].start_adr < phys_base)
+			phys_base = (unsigned long)prom_phys_avail[i].start_adr;
+	}
+
+	for (i = 0; i < n; i++) {
+		/* Do not mess with first 4 Megs of memory */
+		if ((unsigned long)prom_phys_avail[i].start_adr = phys_base) {
+			if (prom_phys_avail[i].num_bytes <= 0x400000)
+				continue;
+			prom_phys_avail[i].start_adr += 0x400000;
+			prom_phys_avail[i].num_bytes -= 0x400000;
+		}
+
+		/* Make sure initrd doesn't overwrite kernel */
+		if (!is_kernel && (unsigned long)prom_phys_avail[i].start_adr = sun4m_image_phys) {
+			if (prom_phys_avail[i].num_bytes <= sun4m_image_len)
+				continue;
+			prom_phys_avail[i].start_adr += sun4m_image_len;
+			prom_phys_avail[i].num_bytes -= sun4m_image_len;
+		}
+
+		/* Make sure initrd phys isn't greater than 28-bits. We
+		 * can only pass unsigned int to the kernel for this
+		 * location. */
+		if (!is_kernel && (unsigned long)prom_phys_avail[i].start_adr >= 0x01000000UL)
+			continue;
+
+		if (prom_phys_avail[i].num_bytes >= len) {
+			phys = (unsigned long)prom_phys_avail[i].start_adr;
+			break;
+		}
+	}
+
+
+	if (!phys) {
+		printf("Could not find any available memory\n");
+		return (char *)0;
+	}
+
+	virt2 = (unsigned long)(*(romvec->pv_v2devops).v2_dumb_mmap)
+			((char*)virt, 0, phys, len);
+	if (!virt2) {
+		printf("Could not map memory\n");
+		return (char *)0;
+	}
+	if (virt2 != virt) {
+		printf("Could not map memory at requested address\n");
+		(*(romvec->pv_v2devops.v2_dumb_munmap))((char*)virt, len);
+		return (char *)0;
+	}
+
+	if (is_kernel) {
+		sun4m_image_len = len;
+		sun4m_image_virt = virt2;
+		sun4m_image_phys = phys;
+		phys += 0x4000UL;
+		virt += 0x4000;
+	} else {
+		sun4m_initrd_len = len;
+		sun4m_initrd_virt = virt2;
+		initrd_phys = phys;
+		/* Not sure what the old kernel crap is for, but it
+		 * expects the passed initrd physical to be relative to
+		 * the phys memory base. We'll keep compatible with older
+		 * kernels to avoid any problems. */
+		sun4m_initrd_phys = phys - phys_base;
+	}
+	return (char *)virt2;
+}
+
+static void sun4m_memory_release(int is_kernel)
+{
+	unsigned long virt, len;
+
+	if (is_kernel) {
+		virt = sun4m_image_virt;
+		len = sun4m_image_len;
+	} else {
+		virt = sun4m_initrd_virt;
+		len = sun4m_initrd_len;
+	}
+
+	if (!len)
+		return;
+
+
+	(*(romvec->pv_v2devops.v2_dumb_munmap))((char*)virt, len);
+
+	if (is_kernel)
+		sun4m_image_len = 0;
+	else
+		sun4m_initrd_len = 0;
+}
+
 static unsigned long long sun4u_image_virt, sun4u_image_len, sun4u_image_phys;
 static unsigned long long sun4u_initrd_virt, sun4u_initrd_len;
 unsigned long long sun4u_initrd_phys;
@@ -393,7 +518,9 @@ static void sun4u_memory_release(int is_
 
 char *image_memory_find (unsigned int len)
 {
-	/* This only works for sparc64 */
+	if (architecture = sun4m || architecture = sun4d)
+		return sun4m_memory_find(len, 1);
+
 	if (architecture != sun4u)
 		return (char *)0;
 
@@ -402,6 +529,9 @@ char *image_memory_find (unsigned int le
 
 void image_memory_release(void)
 {
+	if (architecture = sun4m || architecture = sun4d)
+		sun4m_memory_release(1);
+
 	if (architecture != sun4u)
 		return;
 

Re: How to load 2.6.22 kernel (image too large to fit ...)

[David Miller]

From: Krzysztof Helt <krzysztof.h1@wp.pl>
Date: Sat, 19 May 2007 23:44:53 +0200

> I overcame the problem with too big kernel with the attached patch, but 
> I run into another problem. Now, the silo says:

You haven't told us why you simply cannot make the kernel
smaller by building more things as modules, why kill yourself
with all of these SILO and kernel hacks when you can solve
your problem more easily?

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Ben Collins]

On Sat, 2007-05-19 at 23:44 +0200, Krzysztof Helt wrote:
> Hi again,
> 
> I overcame the problem with too big kernel with the attached patch, but 
> I run into another problem. Now, the silo says:
> 
> "Your kernel cannot fit into the memory destination. This
> can be resolved by recompiling the kernel with more devices
> built as modules, or upgrading your kernel to one that
> supports being loaded to higher memory areas (currently
> 2.6.3+ or 2.4.26+)."
> 
> Does it mean, that 2.6.22-rc1 for sparc32 cannot be relocated?

The patch isn't complete. SILO checks to make sure that the kernel can
be relocated. You probably also need to patch up sparc kernel to allow
itself to be loaded at an alternate location. Whole lot of work.

Honestly, just compile it with less stuff. I don't have a sparc32 to
test anything on, so I'm of no help.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Krzysztof Helt]

Ben Collins wrote:
> On Sat, 2007-05-19 at 23:44 +0200, Krzysztof Helt wrote:
>> Hi again,
>>
>> I overcame the problem with too big kernel with the attached patch, but 
>> I run into another problem. Now, the silo says:
>>
>> "Your kernel cannot fit into the memory destination. This
>> can be resolved by recompiling the kernel with more devices
>> built as modules, or upgrading your kernel to one that
>> supports being loaded to higher memory areas (currently
>> 2.6.3+ or 2.4.26+)."
>>
>> Does it mean, that 2.6.22-rc1 for sparc32 cannot be relocated?
> 
> The patch isn't complete. SILO checks to make sure that the kernel can
> be relocated. You probably also need to patch up sparc kernel to allow
> itself to be loaded at an alternate location. Whole lot of work.
> 

The silo patch seems complete. It is now kernel hHdrS version, which 
says it is not relocatable.
If the kernel fits 2.5MB size, the patch does not hurts (just allocate 
memory and copy kernel back to 2.5MB area).

> Honestly, just compile it with less stuff. I don't have a sparc32 to
> test anything on, so I'm of no help.
> 
I thought I modularized everything but I rechecked my options and I left 
nfs compiled into the kernel statically.
Now, it fits for UP kernel.

Thank you for your time,
Krzysztof

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Meelis Roos]

DM> You haven't told us why you simply cannot make the kernel
DM> smaller by building more things as modules, why kill yourself
DM> with all of these SILO and kernel hacks when you can solve
DM> your problem more easily?

Well, it's quite hard nowadays since the base 2.6 kernel has grown quite
a lot in features that are not modular. I managed to slim my sparc32
kernel down last year but it was quite a pain. Initrd/initramfs becomes
almost a must and I seem to remember that I had to also disable some new
2.6 features to make it fit.

Granted, there are more burning problems with the sparc32 port than
enhancing the boot protocol but it is a real problem IMHO.

-- 
Meelis Roos

Re: How to load 2.6.22 kernel (image too large to fit ...)

[Ben Collins]

On Sun, 2007-05-20 at 06:54 +0200, Krzysztof Helt wrote:
> Ben Collins wrote:
> > On Sat, 2007-05-19 at 23:44 +0200, Krzysztof Helt wrote:
> >> Hi again,
> >>
> >> I overcame the problem with too big kernel with the attached patch, but 
> >> I run into another problem. Now, the silo says:
> >>
> >> "Your kernel cannot fit into the memory destination. This
> >> can be resolved by recompiling the kernel with more devices
> >> built as modules, or upgrading your kernel to one that
> >> supports being loaded to higher memory areas (currently
> >> 2.6.3+ or 2.4.26+)."
> >>
> >> Does it mean, that 2.6.22-rc1 for sparc32 cannot be relocated?
> > 
> > The patch isn't complete. SILO checks to make sure that the kernel can
> > be relocated. You probably also need to patch up sparc kernel to allow
> > itself to be loaded at an alternate location. Whole lot of work.
> > 
> 
> The silo patch seems complete. It is now kernel hHdrS version, which 
> says it is not relocatable.
> If the kernel fits 2.5MB size, the patch does not hurts (just allocate 
> memory and copy kernel back to 2.5MB area).

Sure, SILO side is complete, but the kernel side is a little more
difficult. It's not just HdrS that needs fixing, the kernel needs to
actually support being loaded to arbitrary locations in memory.

I'd be happy for someone to do this work, though.

-- 
Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/