| Message ID | 1271841716-11582-3-git-send-email-thomas_ml@monjalon.net |
|---|---|
| State | New |
| Headers | show |
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
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 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
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...
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
>> 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
> 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
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].
>> 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
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
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 */