Request for testers for an updated bootloader

Chris Gilbert <[email protected]> Sun, 03 Feb 2008 02:57:55 +0000
Newsgroups gmane.os.netbsd.ports.acorn32
Message-ID <[email protected]>
Hi,

I was wondering if people could try out some updates to the acorn32 
bootloader on different hardware?  I've had to alter how we copy the 
kernel into the correct place so that it works on an A7000+ (with 
Risc-OS 3.71)  However I don't have any other hardware to test it on.

I've uploaded the sparkive (sparkive includes an install kernel), a 
generic kernel, a boot32,ffa and the patch to:
ftp://ftp.netbsd.org/pub/NetBSD/arch/acorn32/chris

Note that the new bootloader also changes the colour of the border at 
different stages of running (as visual clue as to where it's at) Border 
colours mean:
Red - we're running without the MMU turned on (IE 1-1 physical mapping)  
Note that the border will stay red a while as we're copying the kernel 
over at this point.
Green - we've finished copying the kernel over (you may not see this)
Blue - we're running on the bootstrap L1 table, and just about to call 
the kernel.

Note anyone without VRAM will see the screen scribbled over as the 
kernel is copied into place.  I believe that RISC-OS sets up the VIDC to 
use the memory for the screen as the same location we're copying the 
kernel to.

Any reports of it's functionality (or lack of) would be appreciated :)

Currently I'm using the above code to install the A7000+ (at a steady 
120KiB/s from NFS)  Not bad for a 48Mhz 24MB machine.

Thanks,
Chris

Code changes are:
* compact the relocation table down, so that sequential copies are 
merged into one large copy.  This shrinks the number of relocation 
entries from ~806 to 12-15 entries (depending on memory fragmentation) 
for a 2.5MB kernel.
* leave the relocation table where it is until we jump into ASM.  Then 
in ASM copy the table after the relocation code we run.  The reason for 
this is that for some reason using the physical address of the 
relocation table always failed, I'm not sure why, but it did.  It would 
then cause the system to go into a loop.  Anyway now the table is a few 
hundred bytes it fits onto the same page that actually does the copy of 
the kernel into the base of memory.
* Add screen border color change to indicate progress
* Before disabling the MMU etc flush out the cache and write buffers as 
appropriate.