From patchwork Wed Jun 17 11:41:29 2009
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: silo: move second to make room for larger kernel
From: Robert Reif
X-Patchwork-Id: 28776
X-Patchwork-Delegate: davem@davemloft.net
Message-Id: <4A38D669.1010506@earthlink.net>
To: Mark Fortescue
Cc: David Miller , sparclinux@vger.kernel.org,
silo@auxio.org
Date: Wed, 17 Jun 2009 07:41:29 -0400
Mark Fortescue 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.
>>>
>
> The relocating does not actually physically move the kernel code. It
> just re-arranges the virtual memory map.
>
I have managed to mmap some physical memory at the destination
virtual address and copy the kernel image there and get it to
start but this is as far as it gets:
PROMLIB: obio_ranges 5
Level 15 Interrupt
I could install a solaris boot loader and see if the kernel
really runs at the destination address to determine if the
problem is with my silo hack or the kernel but that's
too much work for now.
I really don't want to change head_32.S because that is
some scary code so I think I will just stick with my simple
silo patch that makes more room for the kernel and give
up on relocating the kernel for now.
Here it the patch again:
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;)