On 06/03/14 18:07, BALATON Zoltan wrote:
Hello,
On Thu, 6 Mar 2014, laire@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.
ATB,
Mark.