From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZppoE-0000IB-KN for qemu-devel@nongnu.org; Fri, 23 Oct 2015 23:48:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZppoB-0007d3-Cp for qemu-devel@nongnu.org; Fri, 23 Oct 2015 23:47:58 -0400 Received: from nm35-vm5.bullet.mail.bf1.yahoo.com ([72.30.238.77]:44231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZppoB-0007ct-5r for qemu-devel@nongnu.org; Fri, 23 Oct 2015 23:47:55 -0400 Date: Sat, 24 Oct 2015 03:47:52 +0000 (UTC) From: sridhar kulkarni Message-ID: <1789016264.2468642.1445658472213.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2468641_262777029.1445658472201" Subject: Re: [Qemu-devel] qemu-system-arm system support for big endian BE8 Reply-To: sridhar kulkarni List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Peter Crosthwaite , QEMU Developers , Alistair Francis ------=_Part_2468641_262777029.1445658472201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peter, I further debugged this issues, Arround line 5000 of file helper.c, I guess updation of uncached_cpsrwas no= t proper.=C2=A0 I changed following line =C2=A0FROM=C2=A0env->uncached_cpsr= =3D (env->uncached_cpsr & !(CPSR_E)) |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0(env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0);=C2= =A0TO=C2=A0env->uncached_cpsr =3D (env->uncached_cpsr & ~(CPSR_E)) |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(env->cp15.sctlr_el[arm_current_el(env)= ] & SCTLR_EE ? CPSR_E : 0); This fixed the crash that I reported earlier. With this my application is u= p and running. I am not sure if this is the right fix, but wanted to share = this with you and get the feedback. RegardsSridhar =20 On Friday, October 23, 2015 5:26 PM, Peter Maydell wrote: =20 On 23 October 2015 at 12:11, sridhar kulkarni wro= te: > Hi, > > Floating point exception error was the result of a divide by zero in the > application. That is now solved and I was able to progress pretty well wi= th > Big Endinan code. > Currently QEMU crashes during handling interrupt controller. > > Following the dump that I captured. > > ---------------- > IN: > 0xe003b47c: 68e0 ldr r0, [r4, #12] > 0xe003b47e: b110 cbz r0, 0xe003b486 > Trace 0x7f1af25f8410 [e003b47c] > R00=3D00000001 R01=3D0001c200 R02=3D00000001 R03=3Dc16890e8 > R04=3Dc16890e8 R05=3De003b18c R06=3D00000080 R07=3D0000a000 > R08=3Dffffffff R09=3D00000001 R10=3D0001c200 R11=3D00000000 > R12=3D00000000 R13=3Dc1c3a320 R14=3De003b33d R15=3De003b47c > PSR=3D20000133 --C- T svc32 > ---------------- > IN: > 0xe003b486: f8d4 b01c ldr.w fp, [r4, #28] > 0xe003b48a: f44f 5180 mov.w r1, #4096 ; 0x1000 > 0xe003b48e: f241 1021 movw r0, #4385 ; 0x1121 > 0xe003b492: f8ab 1000 strh.w r1, [fp] > 0xe003b496: f64f 4100 movw r1, #64512 ; 0xfc00 > 0xe003b49a: f2c7 4102 movt r1, #29698 ; 0x7402 > 0xe003b49e: 8008 strh r0, [r1, #0] > 0xe003b4a0: f242 1012 movw r0, #8466 ; 0x2112 > 0xe003b4a4: 8048 strh---------------- > IN: > 0x00000194: e121f000 msr CPSR_c, r0 > Trace 0x7f1af259c000 [00000194] > R00=3D8000039f R01=3D80000380 R02=3D770004c8 R03=3D80000380 > R04=3D00000148 R05=3D00000000 R06=3Dc16890e8 R07=3D00000001 > R08=3D00000001 R09=3D00000000 R10=3D00000000 R11=3Dc16746e1 > R12=3D00000000 R13=3D00004b80 R14=3D00000188 R15=3D00000194 > PSR=3D80000380 N--- A usr26 Your dump seems to be incomplete, but here you are about to try to execute an instruction, but somehow the CPSR value is wrong (0x80000380, which is an invalid mode field of 0.) QEMU then complains about it. The obvious guess is that your code has a bug in it somewhere; you should debug it to find out why it is corrupting the CPSR. thanks -- PMM ------=_Part_2468641_262777029.1445658472201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peter,

I further de= bugged this issues,


=
Arround line 5000 of file hel= per.c, I guess updation of uncached_cpsr was not proper.  I changed following line
 
FROM
 
env->uncached_cpsr =3D (en= v->uncached_cpsr & !(CPSR_E)) |
     = ;   (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0);
 
TO
 
env->uncached_cpsr =3D (en= v->uncached_cpsr & ~(CPSR_E)) |
     = ;   (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0);


This fixed the crash that I reported earlier. With this my applicatio= n is up and running. I am not sure if this is the right fix, but wanted to = share this with you and get the feedback.

Regards<= /font>
Sridhar




On Friday, October 23, 2015 5:26 PM, Pet= er Maydell <peter.maydell@linaro.org> wrote:

=
On 23 October 2015 at 12:11, sridhar ku= lkarni <sridhar_kulk@yahoo.com> wrote:> Hi,
>
> Floa= ting point exception error was the result of a divide by zero in the
> application. That is now solved and I was able to progress= pretty well with
> Big Endinan code.
> Currently QEMU crashes during handling interrupt controller.
>
> Following the dump that I captured.<= br clear=3D"none">>
> ----------------
> IN:
> 0xe003b47c: 68e0 ldr r0, [r4, #12]> 0xe003b47e: b110 cbz r0, 0xe003b486
= > Trace 0x7f1af25f8410 [e003b47c]
> R00=3D00000001 = R01=3D0001c200 R02=3D00000001 R03=3Dc16890e8
> R04=3Dc= 16890e8 R05=3De003b18c R06=3D00000080 R07=3D0000a000
>= R08=3Dffffffff R09=3D00000001 R10=3D0001c200 R11=3D00000000
> R12=3D00000000 R13=3Dc1c3a320 R14=3De003b33d R15=3De003b47c
> PSR=3D20000133 --C- T svc32
> -------= ---------
> IN:
> 0xe003b486: f8d= 4 b01c ldr.w fp, [r4, #28]
> 0xe003b48a: f44f 5180 mov= .w r1, #4096 ; 0x1000
> 0xe003b48e: f241 1021 movw r0,= #4385 ; 0x1121
> 0xe003b492: f8ab 1000 strh.w r1, [fp= ]
> 0xe003b496: f64f 4100 movw r1, #64512 ; 0xfc00
> 0xe003b49a: f2c7 4102 movt r1, #29698 ; 0x7402
> 0xe003b49e: 8008 strh r0, [r1, #0]
> 0x= e003b4a0: f242 1012 movw r0, #8466 ; 0x2112
> 0xe003b4= a4: 8048 strh----------------
> IN:
= > 0x00000194: e121f000 msr CPSR_c, r0
> Trace 0x7f1= af259c000 [00000194]
> R00=3D8000039f R01=3D80000380 R= 02=3D770004c8 R03=3D80000380
> R04=3D00000148 R05=3D00= 000000 R06=3Dc16890e8 R07=3D00000001
> R08=3D00000001 = R09=3D00000000 R10=3D00000000 R11=3Dc16746e1
> R12=3D0= 0000000 R13=3D00004b80 R14=3D00000188 R15=3D00000194
>= PSR=3D80000380 N--- A usr26

Your dump= seems to be incomplete, but here you are about
to try to= execute an instruction, but somehow the CPSR
value is wr= ong (0x80000380, which is an invalid mode field
of 0.) QE= MU then complains about it.

The obviou= s guess is that your code has a bug in it somewhere;
you = should debug it to find out why it is corrupting the CPSR.


thanks<= br clear=3D"none">-- PMM


------=_Part_2468641_262777029.1445658472201--