[Qemu-devel] [PATCH 0/2] some fixes for PPC e300

[Qemu-devel] [PATCH 0/2] some fixes for PPC e300

[Thomas Monjalon]

From: Thomas Monjalon <thomas@monjalon.net>

I'm working on e300.
It's still not working but these patches are some little steps in the right direction.

My references:
ancestry:         http://www.freescale.com/files/32bit/doc/data_sheet/MPC603.pdf
core:             http://www.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf
microcontroller:  http://www.freescale.com/files/32bit/doc/ref_manual/MPC8349EAEC.pdf

-- 
Thomas

---

Thomas Monjalon (2):
  target-ppc: fix processor versions (PVR) for e300
  target-ppc: fix interrupt vectors for MPC603 and e300

 target-ppc/translate_init.c |   26 ++++++++++++++++++--------
 1 files changed, 18 insertions(+), 8 deletions(-)

[Qemu-devel] [PATCH 1/2] target-ppc: fix processor versions (PVR) for e300

[Thomas Monjalon]

From: Thomas Monjalon <thomas@monjalon.net>

Reflect values from the table "Assigned PVR values" in [e300CORERM].

Values for MPC603 and G2 processors could need check/changes also.

The reference document (e300CORERM) which is used is:
"e300 Power Architecture Core Family Reference Manual", Revision 4, 12/2007.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 target-ppc/translate_init.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index e8eadf4..9e42831 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6720,17 +6720,18 @@ enum {
     /* e300 family */
     /* e300 cores */
 #define CPU_POWERPC_e300             CPU_POWERPC_e300c3
-    CPU_POWERPC_e300c1             = 0x00830010,
-    CPU_POWERPC_e300c2             = 0x00840010,
-    CPU_POWERPC_e300c3             = 0x00850010,
-    CPU_POWERPC_e300c4             = 0x00860010,
+    CPU_POWERPC_e300c1             = 0x80830010,
+    CPU_POWERPC_e300c2             = 0x80840010,
+    CPU_POWERPC_e300c3             = 0x80850010,
+    CPU_POWERPC_e300c4_MPC5121e    = 0x80860010,
+    CPU_POWERPC_e300c4_MPC83xx     = 0x80861010,
     /* MPC83xx microcontrollers */
 #define CPU_POWERPC_MPC831x          CPU_POWERPC_e300c3
 #define CPU_POWERPC_MPC832x          CPU_POWERPC_e300c2
 #define CPU_POWERPC_MPC834x          CPU_POWERPC_e300c1
 #define CPU_POWERPC_MPC835x          CPU_POWERPC_e300c1
 #define CPU_POWERPC_MPC836x          CPU_POWERPC_e300c1
-#define CPU_POWERPC_MPC837x          CPU_POWERPC_e300c4
+#define CPU_POWERPC_MPC837x          CPU_POWERPC_e300c4_MPC83xx
     /* e500 family */
     /* e500 cores  */
 #define CPU_POWERPC_e500             CPU_POWERPC_e500v2_v22
@@ -7977,7 +7978,7 @@ static const ppc_def_t ppc_defs[] = {
     /* PowerPC e300c3 core                                                   */
     POWERPC_DEF("e300c3",        CPU_POWERPC_e300c3,                 e300),
     /* PowerPC e300c4 core                                                   */
-    POWERPC_DEF("e300c4",        CPU_POWERPC_e300c4,                 e300),
+    POWERPC_DEF("e300c4",        CPU_POWERPC_e300c4_MPC83xx,         e300),
     /* PowerPC e300 microcontrollers                                         */
 #if defined (TODO)
     /* MPC8313                                                               */
-- 
1.7.0.5

[Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Thomas Monjalon]

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;
+#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 */
-- 
1.7.0.5

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Alexander Graf]

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

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Thomas Monjalon]

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
-- 
Thomas

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Alexander Graf]

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

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Thomas Monjalon]

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...

-- 
Thomas

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Hollis Blanchard]

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

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Segher Boessenkool]

>> 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

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Segher Boessenkool]

> 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

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Blue Swirl]

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].

Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

[Segher Boessenkool]

>>  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

[Qemu-devel] VGA blank mode

[K D]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

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

 





________________________________
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Alexander Graf <agraf@suse.de>; qemu-devel@nongnu.org
Sent: Sun, May 2, 2010 7:19:13 AM
Subject: Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300

>>  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


      

[-- Attachment #2: Type: text/html, Size: 1799 bytes --]