[Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Alexander Graf]

The 970 doesn't set exception prefix values by default. According to
the ISA it just jumps to real mode with nip=vector.

Because of that the current hreset_vector is rendered invalid. Before,
it would go to excp_prefix (ROM base) + 0x100 (reset vector) and get
into the firmware.

But with the corrected excp_prefix, we now have to jump to the real
entry point, which is at 0xFFFFFFFC.

I can't imagine how any OS that does memory management itself could have
possibly worked with the code as it was.

Signed-off-by: Alexander Graf <alex@csgraf.de>
---
 target-ppc/translate_init.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 889708f..e20b1c9 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3052,9 +3052,9 @@ static void init_excp_970 (CPUPPCState *env)
     env->excp_vectors[POWERPC_EXCP_MAINT]    = 0x00001600;
     env->excp_vectors[POWERPC_EXCP_VPUA]     = 0x00001700;
     env->excp_vectors[POWERPC_EXCP_THERM]    = 0x00001800;
-    env->excp_prefix   = 0x00000000FFF00000ULL;
+    env->excp_prefix   = 0x0000000000000000ULL;
     /* Hardware reset vector */
-    env->hreset_vector = 0x0000000000000100ULL;
+    env->hreset_vector = 0x00000000FFFFFFFCULL;
 #endif
 }
 #endif
-- 
1.5.3.1

Re: [Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Blue Swirl]

On 2/28/09, Alexander Graf <agraf@suse.de> wrote:
> The 970 doesn't set exception prefix values by default. According to
>  the ISA it just jumps to real mode with nip=vector.
>
>  Because of that the current hreset_vector is rendered invalid. Before,
>  it would go to excp_prefix (ROM base) + 0x100 (reset vector) and get
>  into the firmware.
>
>  But with the corrected excp_prefix, we now have to jump to the real
>  entry point, which is at 0xFFFFFFFC.

I don't think this is correct. 970FX uses HIOR to specify the
exception vector base, please see "IBM PowerPC 970FX RISC
Microprocessor", page 273.

>From OpenBIOS viewpoint both vectors are OK.

>  I can't imagine how any OS that does memory management itself could have
>  possibly worked with the code as it was.

Maybe Qemu uses the 604 exception prefix somewhere.

Re: [Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Alexander Graf]

On 28.02.2009, at 16:21, Blue Swirl wrote:

> On 2/28/09, Alexander Graf <agraf@suse.de> wrote:
>> The 970 doesn't set exception prefix values by default. According to
>> the ISA it just jumps to real mode with nip=vector.
>>
>> Because of that the current hreset_vector is rendered invalid.  
>> Before,
>> it would go to excp_prefix (ROM base) + 0x100 (reset vector) and get
>> into the firmware.
>>
>> But with the corrected excp_prefix, we now have to jump to the real
>> entry point, which is at 0xFFFFFFFC.
>
> I don't think this is correct. 970FX uses HIOR to specify the
> exception vector base, please see "IBM PowerPC 970FX RISC
> Microprocessor", page 273.

That's only valid for LPAR, right? So it's basically a hypervisor  
register which we don't even touch, which means it's basically always 0.

Alex

> From OpenBIOS viewpoint both vectors are OK.
>
>> I can't imagine how any OS that does memory management itself could  
>> have
>> possibly worked with the code as it was.
>
> Maybe Qemu uses the 604 exception prefix somewhere.

Re: [Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Alexander Graf]

On 28.02.2009, at 16:21, Blue Swirl wrote:

> On 2/28/09, Alexander Graf <agraf@suse.de> wrote:
>> The 970 doesn't set exception prefix values by default. According to
>> the ISA it just jumps to real mode with nip=vector.
>>
>> Because of that the current hreset_vector is rendered invalid.  
>> Before,
>> it would go to excp_prefix (ROM base) + 0x100 (reset vector) and get
>> into the firmware.
>>
>> But with the corrected excp_prefix, we now have to jump to the real
>> entry point, which is at 0xFFFFFFFC.
>
> I don't think this is correct. 970FX uses HIOR to specify the
> exception vector base, please see "IBM PowerPC 970FX RISC
> Microprocessor", page 273.

Oh I think I know what you're saying:

The Hardware Interrupt Offset register, HIOR should be scanned (the  
HIOR is on the mode ring) to the
system’s starting address during initialization. Subsequently HIOR  
should be set to zero.

That basically means, HIOR is 0xfff00000 on bootup, but magically  
becomes 0 at - eh - a random point in time? Or should the firmware set  
it? How is this implemented on a G5 that doesn't know LPAR features,  
like Apple's G5?

Alex

Re: [Qemu-devel] [PATCH] PPC: Use correct values for 970 interrupts and hreset

[Blue Swirl]

On 2/28/09, Alexander Graf <alex@csgraf.de> wrote:
>
>  On 28.02.2009, at 16:21, Blue Swirl wrote:
>
>
> > On 2/28/09, Alexander Graf <agraf@suse.de> wrote:
> >
> > > The 970 doesn't set exception prefix values by default. According to
> > > the ISA it just jumps to real mode with nip=vector.
> > >
> > > Because of that the current hreset_vector is rendered invalid. Before,
> > > it would go to excp_prefix (ROM base) + 0x100 (reset vector) and get
> > > into the firmware.
> > >
> > > But with the corrected excp_prefix, we now have to jump to the real
> > > entry point, which is at 0xFFFFFFFC.
> > >
> >
> > I don't think this is correct. 970FX uses HIOR to specify the
> > exception vector base, please see "IBM PowerPC 970FX RISC
> > Microprocessor", page 273.
> >
>
>  Oh I think I know what you're saying:
>
>  The Hardware Interrupt Offset register, HIOR should be scanned (the HIOR is
> on the mode ring) to the
>  system’s starting address during initialization. Subsequently HIOR should
> be set to zero.
>
>  That basically means, HIOR is 0xfff00000 on bootup, but magically becomes 0
> at - eh - a random point in time? Or should the firmware set it? How is this
> implemented on a G5 that doesn't know LPAR features, like Apple's G5?

Firmware should clear it. Maybe their BIOS sets all unknown SPRs to 0?