Subject: Re: NetBSD/arm32 fails to boot with RISCOS 4
To: Dave Daniels <Davedan@arcade.demon.co.uk>
From: Mark Brinicombe <mark@causality.com>
List: port-arm32
Date: 08/09/1999 14:04:59
On 8 Aug 1999, Dave Daniels wrote:

> I have looked at the problem with BtRiscBSD further. I found an
> older version of BtRiscBSD on the 'Risc Disc volume 3', version
> 2.87. That exhibited the same problem and came with the source (I
> must have deleted the 2.88 source as I thought I would never need
> it). Anyway, I played around with the program 'bsdbooter' and
> managed to get around the dynamic area problem by changing
> 'KERNAREA' to -1 (so that RISCOS allocated an area number).

Originally there was a reason for the KERNAREA value though without
looking at the code (not to hand) I do not remember why. Getting RISCOS to
allocate it should not matter.

> Unfortunately I then hit the real showstopper.
>  
> The RISCOS 4 memory map has changed. 'BtRiscBSD' plays around
> with some memory at address 0x2c00000. This address is hard coded
> in the program.
In older versions of RISCOS the RISCOS kernel pagetables used to be
accessable at this address. The boot loader used to map the kernel into
the page table directly so that it was at the correct address when
entered.

> Under RISCOS 4 there is no longer anything
> accessible at that address (at least, not in user mode). I note
> from the RISCOS 3 PRMs that that address is marked as 'reserved
> for system use'. Now, looking at the file 'kernel.html' that Acorn
> put on the Clan web site just before Black Thursday, there is a
> section entitled '1.8 Logical memory map changes'. There are a
> couple of things of interest here:
> 
>   'Maximum RMA size is increased from 11M to 15M'
>  
>   'Some kernel workspace is better protected from user access'
The solution may be to switch to SVC mode for the writes to the page
tables if the code does not already do that. The alternative is to modify
the way the dynamic area is allocated (via a handler) so that specific
virtual addresses are used or to use a separate RISCOS call to modify the
page tables directly (if this can be done).
  
Cheers,
				Mark