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;)
