[OpenBIOS] [morphos] MorphOS on QEMU

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Thu Mar 6 20:16:14 CET 2014

On 06/03/14 18:07, BALATON Zoltan wrote:

> Hello,
> On Thu, 6 Mar 2014, laire at t-online.de wrote:
>> The standard behavior for the PPC OF boot process is disabled memory
>> management when it starts
>> the boot image. The system take over is always a sensitive thing but
>> there is no reason for an OF
>> to use the powerpc exception vectors in that early phase for what
>> functions MorphOS is using.
> Thanks for your reply. I could prevent the crash due to writing to
> memory address 0x80 by moving the exception handling code of openbios to
> somewhere else but unfortunately openbios is using the DSI and ISI
> exceptions and it seems it cannot work without them. I have found this
> document:
> http://www.openfirmware.org/1275/bindings/ppc/release/ppc-2_1.html
> that discusses memory management issues between OF and clients on PPC
> but I don't see what would be the correct behaviour.
> I tried disabling these bits in openbios before staring the boot
> executable but that makes it freeze the first time it calls an openbios
> callback and I don't know how to change it to not rely on working memory
> management for client callbacks. However, if I leave these exceptions
> enabled and only disable them when the MorphOS boot tries to install its
> own handlers it seems to work all right and get past this point. So I
> think if MorphOS cleared the DSI and ISI bits before touching the
> vectors just in case, it would get further on QEMU while this should not
> matter on real hardware where these bits are supposedly not enabled anyway.

Hi all,

My reading of the link above is that it shouldn't really matter if 
real-mode? is set to true or false, although it just so happens that 
that the default is true on Apple's PPC implementation. Does MorphOS 
boot if real-mode? is set to true on real hardware?

On startup OpenBIOS maps the entire RAM 1:1 physical to virtual, so I 
would have thought that this shouldn't be an issue. All other OSs I've 
seen under OpenBIOS reads the translations property from the CPU in 
order to build up any existing mappings before installing their own 
memory handlers, so it's fairly standard practice and I wouldn't expect 
MorphOS to be any different.

Additional mappings can be requested via CIF as the loader requires, but 
of course the loader would assume that anything it hasn't explicitly 
requested hasn't been mapped so would avoid these regions.

Can you obtain the fault address at all? My feeling is that this is a 
symptom of something else having already gone wrong a while back, and 
the stack corruption/exception is another symptom of this.



More information about the OpenBIOS mailing list