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 Date: Wed, 17 Jun 2009 01:41:29 -0000 From: Robert Reif X-Patchwork-Id: 28776 Message-Id: <4A38D669.1010506@earthlink.net> To: Mark Fortescue Cc: David Miller , sparclinux@vger.kernel.org, silo@auxio.org 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;)