[PATCH] silo: move second to make room for larger kernel

[PATCH] silo: move second to make room for larger kernel

[Robert Reif]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

This patch changes the location that second is loaded to make room for 
larger kernels.

On sparc32 a kernel is loaded at 0x4000 and second is loaded
at 0x280000. That means that the largest kernel that can be loaded
is 0x27c000 (2605056) bytes.  Sparc32 kernels have been larger
than that for years and it has recently been almost impossible
to strip down a kernel small enough to actually load.

OBP initializes 3 megs of memory and second is loaded at 2.5
meg.  second is only 40k bytes so most of the last 1/2 meg is
wasted.  This patch moves second to 0x2e0000 which leaves
room for a 128k byte second.

This doesn't fix the sparc32 boot problems because you still
need to compile everything as modules and strip the executable
but it is a short term fix.

The long term fix is to make the sparc32 kernel relocatable
like sparc64.  The first step is to make silo load a large sparc32
kernel.  A patch has been submitted 2 years ago
http://marc.info/?l=linux-sparc&m=117952409730426&w=2
that fixes the silo side.  I have tested that patch and it does
fix the problem of decompressing a large kernel.  However
sparc32 kernel is not relocatable so silo tries to move the
kernel down to low memory (0x4000) but refuses because there
is no room for a large kernel.  I think that patch should go
into silo so the silo will be ready for relocatable sparc32
kernels.

Linux head_32.S has some issues with large kernels.  It
is capable of relocating itself from 0x4000 up to higher
memory but has a hard coded size limit of 0x300000. I
tried relocating a smaller image by changing the header
version to 0x300 which should support relocation and
silo was OK with that but the kernel boot failed with an
illegal instruction so the kernel is not OK with being
loaded at an arbitrary location yet. 

I'm looking into changing linux to be relocatable from
an arbitrary address but that requires that the 2 year
old large kernel patch be applied first.

Signed-off-by: Robert Reif <reif@earthlink.net>



[-- Attachment #2: silo.diff.txt --]
[-- Type: text/plain, Size: 397 bytes --]

diff --git a/Rules.make b/Rules.make
index 4e722f9..f36e2d4 100644
--- a/Rules.make
+++ b/Rules.make
@@ -11,8 +11,8 @@ NM=nm
 ELFTOAOUT=elftoaout
 BIN2H=../common/bin2h
 
-SMALL_RELOC=0x280000
-LARGE_RELOC=0x380000
+SMALL_RELOC=0x2E0000
+LARGE_RELOC=0x3E0000
 
 cc-option-yn = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
 		> /dev/null 2>&1; then echo "y"; else echo "n"; fi;)

Re: [PATCH] silo: move second to make room for larger kernel

[Robert Reif]

Robert Reif wrote:
> This patch changes the location that second is loaded to make room for 
> larger kernels.
I forgot to mention that this patch has been boot tested on a 
sparcstation 20 and an ultra 60.

Re: [PATCH] silo: move second to make room for larger kernel

[Robert Reif]

Robert Reif wrote:
> This patch changes the location that second is loaded to make room for 
> larger kernels.
>
> On sparc32 a kernel is loaded at 0x4000 and second is loaded
> at 0x280000. That means that the largest kernel that can be loaded
> is 0x27c000 (2605056) bytes.  Sparc32 kernels have been larger
> than that for years and it has recently been almost impossible
> to strip down a kernel small enough to actually load.
>
> OBP initializes 3 megs of memory and second is loaded at 2.5
> meg.  second is only 40k bytes so most of the last 1/2 meg is
> wasted.  This patch moves second to 0x2e0000 which leaves
> room for a 128k byte second.
>
> This doesn't fix the sparc32 boot problems because you still
> need to compile everything as modules and strip the executable
> but it is a short term fix.
>
> The long term fix is to make the sparc32 kernel relocatable
> like sparc64.  The first step is to make silo load a large sparc32
> kernel.  A patch has been submitted 2 years ago
> http://marc.info/?l=linux-sparc&m\x117952409730426&w=2
> that fixes the silo side.  I have tested that patch and it does
> fix the problem of decompressing a large kernel.  However
> sparc32 kernel is not relocatable so silo tries to move the
> kernel down to low memory (0x4000) but refuses because there
> is no room for a large kernel.  I think that patch should go
> into silo so the silo will be ready for relocatable sparc32
> kernels.
>
> Linux head_32.S has some issues with large kernels.  It
> is capable of relocating itself from 0x4000 up to higher
> memory but has a hard coded size limit of 0x300000. I
> tried relocating a smaller image by changing the header
> version to 0x300 which should support relocation and
> silo was OK with that but the kernel boot failed with an
> illegal instruction so the kernel is not OK with being
> loaded at an arbitrary location yet.
> I'm looking into changing linux to be relocatable from
> an arbitrary address but that requires that the 2 year
> old large kernel patch be applied first.
>
> Signed-off-by: Robert Reif <reif@earthlink.net>
>
>
I have been looking at head_32.S and things don't look
good.  The kernel expects to either be loaded at 0x4000
or already be loaded at KERNBASE by the boot loader.
If it needs to relocate itself, it just moves the first 3 meg
to high memory or modifies the page table so the currently
mapped memory shows up at KERNBASE.  This won't
help the large kernel problem.

Would it be possible to use silo to load the kernel at its
final destination like the sun bootloader aparently does?

This seems so simple that I can't believe it hasn't been
done before so there must be issues with this approach.

Can anyone please give me some feedback?

Re: [PATCH] silo: move second to make room for larger kernel

[Chris Newport]

On Sun, 14 Jun 2009, Robert Reif wrote:

> Would it be possible to use silo to load the kernel at its
> final destination like the sun bootloader aparently does?
>
> This seems so simple that I can't believe it hasn't been
> done before so there must be issues with this approach.
>
> Can anyone please give me some feedback?

How does the BSD bootloader work ?

Re: [PATCH] silo: move second to make room for larger kernel

[David Miller]

From: Chris Newport <crn@netunix.com>
Date: Mon, 15 Jun 2009 02:38:51 +0100 (BST)

> How does the BSD bootloader work ?

BSD uses an fcode bootblock.

Because only MIT/BSD licensed forth tokenizers exist, and also we only
have one 512 byte boot block available, such an implementation really
isn't an option for Linux.

Re: [PATCH] silo: move second to make room for larger kernel

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Sun, 14 Jun 2009 08:59:50 -0400

> Would it be possible to use silo to load the kernel at its
> final destination like the sun bootloader aparently does?
> 
> This seems so simple that I can't believe it hasn't been
> done before so there must be issues with this approach.
> 
> Can anyone please give me some feedback?

We just never implemented this way because there was never
a need for such complexity.  Originally the kernel was A.OUT
and we need to support relocation for the sake of network
booting anyways.

You will need to make the relocation case work for the sake
of net booting no matter what.  Otherwise large kernels will
work for SILO boots but not for networking boots, which
eliminates an installation scheme for a whole class of users.

Why not simply make the relocating code move more than 3MB
of mappings to the final location?  What prevents that from
working?

Re: [PATCH] silo: move second to make room for larger kernel

[David Miller]

Robert, I'm working on getting your work integrated into SILO
somehow and will look at the ugly relocation issues on sparc32
soon.

Re: [PATCH] silo: move second to make room for larger kernel

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Fri, 12 Jun 2009 09:21:24 -0400

> This patch changes the location that second is loaded to make room for
> larger kernels.
 ...
> Signed-off-by: Robert Reif <reif@earthlink.net>

I've taken over the SILO GIT tree and applied this patch.

	git://git.kernel.org/pub/scm/linux/kernel/git/davem/silo.git

Enjoy.

Re: [PATCH] silo: move second to make room for larger kernel

[David Miller]

From: Mark Fortescue <mark@mtfhpc.demon.co.uk>
Date: Wed, 17 Jun 2009 02:41:34 +0100 (BST)

> Making the relocate size bigger worked for sun4c with the some what
> limited capabilities of the SunOS 4.1 A.OUT loader last time I tried a
> new kernel. It is the only way I found of using a sun4c Linux kernels
> from about 2.6.16 to 2.6.23 (work got in the way so I have not done
> any testing of more recent kernels). I can't think of anything that
> will prevent it from working with more recent kernels.

Ok, if that works, the thing to do is:

1) Calculate "SUN4C_SEGMAP_ROUND_UP(&_end - KERNBASE)"

   Make this calculation a macro.

2) Use that instead of the 3MB constant in the sun4/sun4c remapping
   loops of head_32.S

I'd be happy to apply this if it can get at least a minimal smoke
test by someone.