Subject: Re: Unsuccessful attempt on 1.2 beta scratch-installation
To: None <port-arm32@NetBSD.ORG>
From: Mark Brinicombe <amb@physig4.ph.kcl.ac.uk>
List: port-arm32
Date: 08/13/1996 20:42:36
>> When I tried to boot RiscBSD the first time, I had unsaved files
>> and StrongED asked me if I wanted to quit. That I did, and RISC OS
>> booted up normally, but RiscBSD did not boot.
>
> Hmm, this is probably because the bootloader plays Russian roulette with =
> the
> RiscOS memory map so very occasionally it comes unstuck. This will get fi=
> xed
> when we get time to rewrite the bootstrap process (maybe this weekend if =
> you're
> really lucky...).

If anyone wants a better understanding of how RiscBSD is wellied into operation
have a look at the bootloader source and the initarm() in machdep.c

Basically the RiscBSD kernel need to be located in the bottom of physical RAM
for full ignition. Things start with RiscOS loading the kernel into memory
resulting in it being randomly spread out through physical pages.
At this point things gte messy.
I borrow the top of physical memory hardwire it into the RiscOS page tables at
the same address as the kernel appears under RiscBSD (0xf0000000) and
copy my disjointed kernel into a physically continuous block thats now wired
there.
At this point I then start running this RiscBSD by jumping to the start of this
code.
The next stage is to replace the RiscOS page tables with temporary ones that
RiscBSD creates. This maps VRAM VIDC, IOMD, physical memory 1:1 with virtual
addresses and double maps the top of physical memory so we don;t lose the code
we are running. Then RiscBSD copies the kernel from the top of physical memory
to the bottom and starts the secondry bootstrap. This replaces the temporary
page tables with the real ones and junks the mapping of the top of physical
memory.
By this point we are well into booting RiscBSD.

As far as problems under occuring under RiscOS the 'Russian Roulette' bit is
this borrowing of the top of physical memory. The ideal situation would be to
use the bottom of physical memory as this is the ultimate destination but this
is in use.

There are two solutions
1. Complete rewrite the way the kernel team would like it (separating out the
bootstrap code from the kernel)
2. Work out how, using dynamic areas, a physically continuous block of memory
either at the top or bottom of memory can be obtained.

1. Is a major bit of work
2. Is a more likely option ... Anyone know how you request specific physical
pages from RiscOS ?

Cheers,
				Mark



-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716