Re: [OpenBIOS] [Qemu-ppc] MorphOS 4.x on QEMU

[BALATON Zoltan]

On Tue, 4 Mar 2014, Mark Cave-Ayland wrote:
> Yeah, it's quite tricky without source :/
>
> One trick I managed with the Solaris kernel was to copy the binary (an ELF 
> executable) from the ISO and then load up QEMU with the gdbstub, e.g. with -s 
> -S and use a cross-gdb against the ELF image.
>
> Because the image still had symbols I could extract them using objdump and 
> then set breakpoints at different symbol names to see how far I was getting; 
> plus if I got stuck in a loop then I could often get a clue by using "bt" in 
> gdb to get the call stack and use the symbol names to guess what was 
> happening.

This is what I was doing too but it had no symbols so gdb does not help 
too much and I can only follow addresses and string offsets which makes it 
more difficult. Looking at it some more I believe these memory management 
exceptions are not supposed to happen at all and MorphOS does not expect 
them to happen. It only enables the MSR_DR and MSR_IR bits after it has 
set up the handlers and before that it only enables MSR_ME and MSR_FP at 
the start. I think it does not expect the firmware to enable or use these 
memory management exceptions. Can someone with access to a PPC Mac verify 
what bits of the MSR are enabled when the boot executable is started? If 
these exceptions don't happen on a Mac until enabled then it would explain 
why it can write to 0x80 without problems and why it does not crash during 
installing exception vectors.

I've tried to turn off these bits in call_elf before the executable is 
called but this causes problems in client callbacks which hang with this 
change. Then I also tried to additionally reenable the bits in 
of_client_callback like this:

Index: arch/ppc/qemu/start.S
===================================================================
--- arch/ppc/qemu/start.S	(revision 1271)
+++ arch/ppc/qemu/start.S	(working copy)
@@ -521,13 +521,13 @@
    LOAD_REG_IMMEDIATE(r5, of_client_callback)	// r5 = callback
    li	r6,0			// r6 = address of client program 
arguments (unused)
    li	r7,0			// r7 = length of client program 
arguments (unused)
-	li	r0,MSR_FP | MSR_ME | MSR_DR | MSR_IR
+	li	r0,MSR_FP | MSR_ME
    MTMSRD(r0)
    blrl

#ifdef CONFIG_PPC64
      /* Restore SF bit */
-    LOAD_REG_IMMEDIATE(r0, MSR_SF | MSR_FP | MSR_ME | MSR_DR | MSR_IR)
+    LOAD_REG_IMMEDIATE(r0, MSR_SF | MSR_FP | MSR_ME)
      MTMSRD(r0)
  #endif
    LOAD_REG_IMMEDIATE(r8, saved_stack)		// restore stack 
pointer
@@ -541,10 +541,10 @@

#ifdef __powerpc64__
  #define STKOFF STACKFRAME_MINSIZE
-#define SAVE_SPACE 320
+#define SAVE_SPACE 328
  #else
  #define STKOFF 8
-#define SAVE_SPACE 144
+#define SAVE_SPACE 148
  #endif
  GLOBL(of_client_callback):

@@ -614,6 +614,12 @@
      PPC_STL r30, (STKOFF + 31 * ULONG_SIZE)(r1)
      PPC_STL r31, (STKOFF + 32 * ULONG_SIZE)(r1)

+	/* temporarily enable memory management */
+    mfmsr r2
+    PPC_STL r2,  (STKOFF +  33 * ULONG_SIZE)(r1)
+    ori  r2,r2,MSR_DR | MSR_IR
+    MTMSRD(r2)
+
  #ifdef CONFIG_PPC64
      LOAD_REG_IMMEDIATE(r2, of_client_interface)
      ld  r2, 8(r2)
@@ -652,6 +658,8 @@

/* restore ctr, cr and xer */

+    PPC_LL  r2,  (STKOFF +  33 * ULONG_SIZE)(r1)
+	MTMSRD(r2)
      PPC_LL  r2,  (STKOFF +  3 * ULONG_SIZE)(r1)
    mtctr	r2
      PPC_LL  r2,  (STKOFF +  4 * ULONG_SIZE)(r1)

but this causes a fatal error during return from the callback:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x60000000

NIP 60000000   LR 60000000 CTR 00000000 XER 00000000
MSR 00000000 HID0 00000000  HF 00000000 idx 1
TB 00000000 1676840346 DECR 2618127007
GPR00 0000000000000000 0000000060000000 0000000000000000 0000000000000000
GPR04 000000004bfffffc 0000000000000000 0000000000000000 0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 00000000
  SRR0 fff0dac4  SRR1 00003030    PVR 000c0209 VRSAVE 00000000
SPRG0 07e00000 SPRG1 ffffff6c  SPRG2 22000042  SPRG3 00000000
SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
  SDR1 07e00000

which is strange but I'm not that sure about my PPC assembly.
> Probably the easiest way though is to try and engage with the MorphOS people 
> on their mailing list and see if someone is willing to give you pointers 
> based on execution addresses (or function names if objdump works) as to what 
> could be the problem.

I'll try to contact them and see what they say.

Regards,
BALATON Zoltan