On 06/06/14 01:55, BALATON Zoltan wrote:
I'm trying to solve the last bigger outstanding problem for MorphOS to run with OpenBIOS. This is that it modifies exception vectors without first turning the MMU off (probably expecting it to be off as happens on real hardware). OpenBIOS on the other hand turns the MMU on and needs this for client interface calls to work so calling the client boot code with MMU off results in a hang. There is disabled code in the quiesce method to clear the MMU bits but this is not sufficient/correct because MorphOS continues to call client interface callbacks after calling quiesce. Thus I was trying to save MSR, turn MMU on then restore MSR on client callbacks with the patch below but it does not work and leads to writes to wrong addresses and a crash on restore. (Probably the stack location is wrong after the patch?) Can anyone tell why it's not working and what could be done instead?
I really don't think that this is the correct way to handle this at all. Firstly I believe that real-mode? is set to false by default on real hardware, e.g. from articles like http://www.dialectronics.com/Words/OF_Part_III.shtml.
Secondly, for context I quote from one of your earlier emails:
<quote> MorphOS does not set a callback but seems to call OF functions before starting to take over memory management and it probably only calls exit after that which may work according to the above document. During MMU take over what happens though is this: First MorphOS copies some code to 0x0000-0x1fff without first disabling the memory management interrupts. (Maybe it expects them to be off until enabled.) The code it copies is not correct yet as it has jumps pointing to somewhere near the end of ROM area. Then it fixes up these jumps with addresses pointing to its current location at its load address (it may change this back later again but I have not got there yet). Then it enables the MMU bits in the MSR. Surely enough on QEMU it hits a DSI exception just after it copied its vectors but before it fixed them up which leads to a jump to somewhere in ROM and eventually hits an invalid opcode again. This does not happen if I disable the MMU bits in MSR when the vectors are first copied and let MorphOS enable them later after it fixed the vectors up. I think this either again just works by chance on real hardware or the OF implementations there disable these bits when calling the boot loader and do not need working MMU for client functions. It could be verified by checking the value of MSR on real hardware but I have no access to any. In either case if MorphOS had not assumed that no MMU exception happens while the vectors are wrong but explicitely disabled MMU bits before touching the vectors it would work. The exception happening here during MMU take over is not caused by openbios but by accessing memory by the boot code but openbios needs working MMU for client functions earlier so it cannot disable these bits itself before calling the bootloader unless it could enable during callbacks. So I see no easy way to fix this within openbios. </quote>
It seems to me that if real-mode? is set to false on real hardware, then your hypothesis that MorphOS expects MMU interrupts to be disabled can't be true; as soon as your hit an MMU fault you have to service it. Now I can think of two possible things here:
1) Incorrect/not enough state saving on CIF entry/exit
Does MorphOS call CIF between updating the trap table and fixing it up? This was similar to a recent bug I had with SPARC64, in that I had to modify the CIF entry/exit to save more processor state to prevent traps. This is because *BSDs assume they could call CIF at a similar point before final takeover without realising that a window fill/spill trap could occur between these two points.
2) Trap table is copied from OpenFirmware directly
Maybe the MorphOS developers have found the address of the default trap table in a real OF ROM and copy those values into the real vectors as a starting point? Then they can just fix up the values into their executable as required while during the transition any "unfixed" traps would be handled by the PROM as before? Can you provide more details as to exactly which addresses are copied from, and whether this is done on a "per vector" basis or whether the entire 0x0000-0x1fff block is copied as a single chunk and from where? I think this may be the more likely scenario.
ATB,
Mark.