Patchwork [2/2] target-ppc: fix interrupt vectors for MPC603 and e300

login
register
mail settings
Submitter Thomas Monjalon
Date April 21, 2010, 9:21 a.m.
Message ID <1271841716-11582-3-git-send-email-thomas_ml@monjalon.net>
Download mbox | patch
Permalink /patch/50646/
State New
Headers show

Comments

Thomas Monjalon - April 21, 2010, 9:21 a.m.
From: Thomas Monjalon <thomas@monjalon.net>

The vectors are listed
    - in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
      of the e300 datasheet [e300CORERM] and
    - in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
      of the MPC603 datasheet.

As e300 inherits from MPC603, init_excp_e300() calls init_excp_603().

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 target-ppc/translate_init.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)
Alexander Graf - April 21, 2010, 10:14 a.m.
On 21.04.2010, at 11:21, Thomas Monjalon wrote:

> From: Thomas Monjalon <thomas@monjalon.net>
> 
> The vectors are listed
>    - in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
>      of the e300 datasheet [e300CORERM] and
>    - in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
>      of the MPC603 datasheet.
> 
> As e300 inherits from MPC603, init_excp_e300() calls init_excp_603().
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> target-ppc/translate_init.c |   13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 9e42831..f3e266d 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
>     env->excp_vectors[POWERPC_EXCP_SMI]      = 0x00001400;
>     env->hreset_excp_prefix = 0x00000000UL;
>     /* Hardware reset vector */
> -    env->hreset_vector = 0xFFFFFFFCUL;
> +    env->hreset_vector = 0x00000100UL;

Are you 100% sure this is correct? IIRC the reset vector is dictated by the CPU initialization sequence, so there's no hardwired value here really.


Btw - what do you use to test your patches?


Alex
Thomas Monjalon - April 21, 2010, 12:07 p.m.
Alexander Graf wrote:
> > --- a/target-ppc/translate_init.c
> > +++ b/target-ppc/translate_init.c
> > @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
> >     env->excp_vectors[POWERPC_EXCP_SMI]      = 0x00001400;
> >     env->hreset_excp_prefix = 0x00000000UL;
> >     /* Hardware reset vector */
> > -    env->hreset_vector = 0xFFFFFFFCUL;
> > +    env->hreset_vector = 0x00000100UL;
>
> Are you 100% sure this is correct? IIRC the reset vector is dictated by the
> CPU initialization sequence, so there's no hardwired value here really.

It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3.
Clearly, the vector offset is 0x100 and the exception prefix can be 0 or 
0xFFF00000, depending of the MSR[IP] bit.

So, yes, I'm sure the value of hreset_vector must be 0x100.
But hreset_excp_prefix can change. It could be another patch.

About the prefix initialization, the datasheet says it is "determined by 
MSR[IP]". and is "determined by the state of the msrip signal". But I don't 
understand what is the msrip signal and how MSR[IP] is changed (is it related 
to msrip ?). Do you have an explanation for this part ?

> Btw - what do you use to test your patches?

I'm slowly writing support for the WindRiver board SBC8349E.
For the moment, I send patches for things I'm sure.

Thanks for the review
Alexander Graf - April 21, 2010, 12:36 p.m.
Thomas Monjalon wrote:
> Alexander Graf wrote:
>   
>>> --- a/target-ppc/translate_init.c
>>> +++ b/target-ppc/translate_init.c
>>> @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
>>>     env->excp_vectors[POWERPC_EXCP_SMI]      = 0x00001400;
>>>     env->hreset_excp_prefix = 0x00000000UL;
>>>     /* Hardware reset vector */
>>> -    env->hreset_vector = 0xFFFFFFFCUL;
>>> +    env->hreset_vector = 0x00000100UL;
>>>       
>> Are you 100% sure this is correct? IIRC the reset vector is dictated by the
>> CPU initialization sequence, so there's no hardwired value here really.
>>     
>
> It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3.
> Clearly, the vector offset is 0x100 and the exception prefix can be 0 or 
> 0xFFF00000, depending of the MSR[IP] bit.
>
> So, yes, I'm sure the value of hreset_vector must be 0x100.
> But hreset_excp_prefix can change. It could be another patch.
>   

Interesting. That's different from 970.

> About the prefix initialization, the datasheet says it is "determined by 
> MSR[IP]". and is "determined by the state of the msrip signal". But I don't 
> understand what is the msrip signal and how MSR[IP] is changed (is it related 
> to msrip ?). Do you have an explanation for this part ?
>   

I guess we should ask somebody more knowledgeable here. Segher?

>   
>> Btw - what do you use to test your patches?
>>     
>
> I'm slowly writing support for the WindRiver board SBC8349E.
> For the moment, I send patches for things I'm sure.
>   

Nice. What kind of firmware does that use?


Alex
Thomas Monjalon - April 21, 2010, 1:13 p.m.
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > I'm slowly writing support for the WindRiver board SBC8349E.
> > For the moment, I send patches for things I'm sure.
>
> Nice. What kind of firmware does that use?

Hmm... I don't know. I don't have such a board.
I'm testing by running a wrapped Linux in Qemu. 

But I'm interested by the answer...
Hollis Blanchard - April 22, 2010, 7:40 p.m.
On Wed, Apr 21, 2010 at 5:36 AM, Alexander Graf <agraf@suse.de> wrote:
> Thomas Monjalon wrote:
>> Alexander Graf wrote:
>>
>>>> --- a/target-ppc/translate_init.c
>>>> +++ b/target-ppc/translate_init.c
>>>> @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
>>>>     env->excp_vectors[POWERPC_EXCP_SMI]      = 0x00001400;
>>>>     env->hreset_excp_prefix = 0x00000000UL;
>>>>     /* Hardware reset vector */
>>>> -    env->hreset_vector = 0xFFFFFFFCUL;
>>>> +    env->hreset_vector = 0x00000100UL;
>>>>
>>> Are you 100% sure this is correct? IIRC the reset vector is dictated by the
>>> CPU initialization sequence, so there's no hardwired value here really.
>>>
>>
>> It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3.
>> Clearly, the vector offset is 0x100 and the exception prefix can be 0 or
>> 0xFFF00000, depending of the MSR[IP] bit.
>>
>> So, yes, I'm sure the value of hreset_vector must be 0x100.
>> But hreset_excp_prefix can change. It could be another patch.
>>
>
> Interesting. That's different from 970.

Only Book E processors come out of reset with a PC of 0xfffffffc.
"Classic" PowerPC comes out with PC 0xfff00100 (the FFF part specified
by MSR[IP]).

970 may be a bad example in that it can't actually bring itself up --
it requires an external controller to configure it at power-up. So
whatever the external controller programs into the PC is where it
starts. I don't see any mention of an initial PC value in the 970 user
manuals.

Qemu ignores these details and pretends that all PowerPC start at
0xffffffc. As long as you have qemu-specific firmware that expects
this behavior, you're ok...

-Hollis
Segher Boessenkool - April 26, 2010, 3:02 p.m.
>> It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3.
>> Clearly, the vector offset is 0x100 and the exception prefix can  
>> be 0 or
>> 0xFFF00000, depending of the MSR[IP] bit.
>>
>> So, yes, I'm sure the value of hreset_vector must be 0x100.
>> But hreset_excp_prefix can change. It could be another patch.
>
> Interesting. That's different from 970.

On 970, you can have the same effect (well, more general) by
changing HIOR.

>> About the prefix initialization, the datasheet says it is  
>> "determined by
>> MSR[IP]". and is "determined by the state of the msrip signal".  
>> But I don't
>> understand what is the msrip signal and how MSR[IP] is changed (is  
>> it related
>> to msrip ?). Do you have an explanation for this part ?

Your code can change MSR[IP]; there is also a strapping pin that is
sampled on HRESET (and copied to MSR[IP]).


Segher
Segher Boessenkool - April 26, 2010, 3:35 p.m.
> 970 may be a bad example in that it can't actually bring itself up --
> it requires an external controller to configure it at power-up. So
> whatever the external controller programs into the PC is where it
> starts.

970 always starts at HIOR|0x00100.

> I don't see any mention of an initial PC value in the 970 user
> manuals.

For way more detail than you ever wanted to know of the 970 POR
process, see for example the "970MP Power On Reset" application
note.  The relevant thing here is that the POR state machine
instruction that starts the CPU core is SRESET -- and that is
described in the UM just fine.


Segher
Blue Swirl - April 26, 2010, 5:11 p.m.
On 4/26/10, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >
> > > It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3.
> > > Clearly, the vector offset is 0x100 and the exception prefix can be 0 or
> > > 0xFFF00000, depending of the MSR[IP] bit.
> > >
> > > So, yes, I'm sure the value of hreset_vector must be 0x100.
> > > But hreset_excp_prefix can change. It could be another patch.
> > >
> >
> > Interesting. That's different from 970.
> >
>
>  On 970, you can have the same effect (well, more general) by
>  changing HIOR.
>
>
> >
> > > About the prefix initialization, the datasheet says it is "determined by
> > > MSR[IP]". and is "determined by the state of the msrip signal". But I
> don't
> > > understand what is the msrip signal and how MSR[IP] is changed (is it
> related
> > > to msrip ?). Do you have an explanation for this part ?
> > >
> >
>
>  Your code can change MSR[IP]; there is also a strapping pin that is
>  sampled on HRESET (and copied to MSR[IP]).

Wouldn't this mean that when the reset is issued by hardware, MSR[IP]
is always 1 (to boot from ROM) but with software reset it can take
software defined values?

I think now QEMU ignores MSR[IP].
Segher Boessenkool - May 2, 2010, 2:19 p.m.
>>  Your code can change MSR[IP]; there is also a strapping pin that is
>>  sampled on HRESET (and copied to MSR[IP]).
>
> Wouldn't this mean that when the reset is issued by hardware, MSR[IP]
> is always 1 (to boot from ROM) but with software reset it can take
> software defined values?

Yes, that is what it means.

> I think now QEMU ignores MSR[IP].

Fix it :-)


Segher
K D - May 2, 2010, 3:03 p.m.
Hi

I'm trying to run kvm/qemu on a linux host built from scratch ie., no x windows, no window manager etc. bare minimum libraries etc. when i try to spawn a VM with "-curses", I see "VGA Blank Mode" and nothing else. i'm attached to serial console for this host. what could be the issue?

thanks

Patch

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 9e42831..f3e266d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -2853,7 +2853,16 @@  static void init_excp_603 (CPUPPCState *env)
     env->excp_vectors[POWERPC_EXCP_SMI]      = 0x00001400;
     env->hreset_excp_prefix = 0x00000000UL;
     /* Hardware reset vector */
-    env->hreset_vector = 0xFFFFFFFCUL;
+    env->hreset_vector = 0x00000100UL;
+#endif
+}
+
+static void init_excp_e300 (CPUPPCState *env)
+{
+    init_excp_603(env);
+#if !defined(CONFIG_USER_ONLY)
+    env->excp_vectors[POWERPC_EXCP_CRITICAL] = 0x00000A00;
+    env->excp_vectors[POWERPC_EXCP_PERFM]    = 0x00000F00;
 #endif
 }
 
@@ -4175,7 +4184,7 @@  static void init_proc_e300 (CPUPPCState *env)
     gen_low_BATs(env);
     gen_high_BATs(env);
     gen_6xx_7xx_soft_tlb(env, 64, 2);
-    init_excp_603(env);
+    init_excp_e300(env);
     env->dcache_line_size = 32;
     env->icache_line_size = 32;
     /* Allocate hardware IRQ controller */