[Qemu-devel] qemu-system-arm system support for big endian BE8

[Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

Hi,
I am looking at big endian support in QEMU for BE8 arm system. Looks like this is possible in user mode, but not in system mode. I am looking at system mode support for BE8. I have noticed few discussions around supporting BE8, and I believe there are few patches available. I am not sure if any of them made it to QEMU main line code. 
Can anyone point me to patches or share the work which has been already done to support BE8? If not, can anybody point what it takes to support big endian, and where in qemu source code I can start looking at this feasibility?
 I am trying to run the big endian code on vxpress a9 board.
RegardsSridhar

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

I am cc'ing few guys who have worked on the Arm big endian system support. I am looking at BE8. Can you please help me with the current status of the work on big endian support? I would really want to have this working for my setup.

 


     On Tuesday, September 8, 2015 10:55 PM, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
   

 Hi,
I am looking at big endian support in QEMU for BE8 arm system. Looks like this is possible in user mode, but not in system mode. I am looking at system mode support for BE8. I have noticed few discussions around supporting BE8, and I believe there are few patches available. I am not sure if any of them made it to QEMU main line code. 
Can anyone point me to patches or share the work which has been already done to support BE8? If not, can anybody point what it takes to support big endian, and where in qemu source code I can start looking at this feasibility?
 I am trying to run the big endian code on vxpress a9 board.
RegardsSridhar

  

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Crosthwaite]

On Tue, Sep 8, 2015 at 10:12 PM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> I am cc'ing few guys who have worked on the Arm big endian system support.
> I am looking at BE8. Can you please help me with the current status of the
> work on big endian support? I would really want to have this working for my
> setup.
>
>

The latest work is here, which should handle be8 and AA64 big endianness:

https://github.com/Xilinx/qemu/commits/mainline/big_endian

Regards,
Peter

>
>
>
> On Tuesday, September 8, 2015 10:55 PM, sridhar kulkarni
> <sridhar_kulk@yahoo.com> wrote:
>
>
> Hi,
>
> I am looking at big endian support in QEMU for BE8 arm system. Looks like
> this is possible in user mode, but not in system mode. I am looking at
> system mode support for BE8. I have noticed few discussions around
> supporting BE8, and I believe there are few patches available. I am not sure
> if any of them made it to QEMU main line code.
>
> Can anyone point me to patches or share the work which has been already done
> to support BE8? If not, can anybody point what it takes to support big
> endian, and where in qemu source code I can start looking at this
> feasibility?
>
>  I am trying to run the big endian code on vxpress a9 board.
>
> Regards
> Sridhar
>
>

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

Hi Peter,
I was able to progress well using the BE8 work in the branch that you pointed out. I am experiencing floating point issue. The qemu just exits, by putting a message that "floating point exception(core dumped)". I suppose QEMU do support floating point operations. I heard about hard floating point and soft floating point support. Is there any configuration option in QEMU for floating point? 

ThanksSridhar
 


     On Thursday, September 10, 2015 10:38 PM, Peter Crosthwaite <crosthwaitepeter@gmail.com> wrote:
   

 On Tue, Sep 8, 2015 at 10:12 PM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> I am cc'ing few guys who have worked on the Arm big endian system support.
> I am looking at BE8. Can you please help me with the current status of the
> work on big endian support? I would really want to have this working for my
> setup.
>
>

The latest work is here, which should handle be8 and AA64 big endianness:

https://github.com/Xilinx/qemu/commits/mainline/big_endian

Regards,
Peter

>
>
>
> On Tuesday, September 8, 2015 10:55 PM, sridhar kulkarni
> <sridhar_kulk@yahoo.com> wrote:
>
>
> Hi,
>
> I am looking at big endian support in QEMU for BE8 arm system. Looks like
> this is possible in user mode, but not in system mode. I am looking at
> system mode support for BE8. I have noticed few discussions around
> supporting BE8, and I believe there are few patches available. I am not sure
> if any of them made it to QEMU main line code.
>
> Can anyone point me to patches or share the work which has been already done
> to support BE8? If not, can anybody point what it takes to support big
> endian, and where in qemu source code I can start looking at this
> feasibility?
>
>  I am trying to run the big endian code on vxpress a9 board.
>
> Regards
> Sridhar
>
>



  

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Maydell]

On 23 September 2015 at 03:48, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
> Hi Peter,
>
> I was able to progress well using the BE8 work in the branch that you
> pointed out. I am experiencing floating point issue. The qemu just exits, by
> putting a message that "floating point exception(core dumped)". I suppose
> QEMU do support floating point operations. I heard about hard floating point
> and soft floating point support. Is there any configuration option in QEMU
> for floating point?

QEMU's floating point support for ARM is good and known to work.
If QEMU exits with a coredump then that is either:
 * your test binary is dumping core due to a bug in your test
   (assuming you're using linux-user mode)
 * a bug in QEMU (unlikely but not impossible)

If you can provide a reproducible test case we can have a look at it.

thanks
-- PMM

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Crosthwaite]

On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 23 September 2015 at 03:48, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
>> Hi Peter,
>>
>> I was able to progress well using the BE8 work in the branch that you
>> pointed out. I am experiencing floating point issue. The qemu just exits, by
>> putting a message that "floating point exception(core dumped)". I suppose
>> QEMU do support floating point operations. I heard about hard floating point
>> and soft floating point support. Is there any configuration option in QEMU
>> for floating point?
>
> QEMU's floating point support for ARM is good and known to work.
> If QEMU exits with a coredump then that is either:
>  * your test binary is dumping core due to a bug in your test
>    (assuming you're using linux-user mode)
>  * a bug in QEMU (unlikely but not impossible)
>
> If you can provide a reproducible test case we can have a look at it.
>

Yes, so the thing stopping me upstreaming this was a reasonable test.
Can I have a look at your reproducer?

Regards,
Peter

> thanks
> -- PMM

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

The issue is mostly related to my application under test. When the application calls a function the PC is getting set up to a wrong address, and then qemu crashes by displaying "floating point exception(core dumped)" message. 
I am able to move ahead by resolving the issue. But interestingly whenever my app crashes it always displays the same "floating point exception" message. But I don't see any floating operations at the point code crashes. I don't see any dump of the processor registers also. It's always just a one line message as I described above.
RegardsSridhar
 


     On Thursday, September 24, 2015 8:23 AM, Peter Crosthwaite <crosthwaitepeter@gmail.com> wrote:
   

 On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 23 September 2015 at 03:48, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
>> Hi Peter,
>>
>> I was able to progress well using the BE8 work in the branch that you
>> pointed out. I am experiencing floating point issue. The qemu just exits, by
>> putting a message that "floating point exception(core dumped)". I suppose
>> QEMU do support floating point operations. I heard about hard floating point
>> and soft floating point support. Is there any configuration option in QEMU
>> for floating point?
>
> QEMU's floating point support for ARM is good and known to work.
> If QEMU exits with a coredump then that is either:
>  * your test binary is dumping core due to a bug in your test
>    (assuming you're using linux-user mode)
>  * a bug in QEMU (unlikely but not impossible)
>
> If you can provide a reproducible test case we can have a look at it.
>

Yes, so the thing stopping me upstreaming this was a reasonable test.
Can I have a look at your reproducer?

Regards,
Peter

> thanks
> -- PMM



  

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Crosthwaite]

On Thu, Sep 24, 2015 at 3:48 AM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> The issue is mostly related to my application under test. When the
> application calls a function the PC is getting set up to a wrong address,
> and then qemu crashes by displaying "floating point exception(core dumped)"
> message.
> I am able to move ahead by resolving the issue.

Was this a QEMU bug or an issue in your program?

But interestingly whenever
> my app crashes it always displays the same "floating point exception"
> message. But I don't see any floating operations at the point code crashes.
> I don't see any dump of the processor registers also. It's always just a one
> line message as I described above.
>

Ok, are you unable to share the binary or source? Alternatively, can
you strip it down to a super-minimal program that replicates just this
one issue? Pasting us a GDB backtrace of the failure might help as
well.

Regards,
Peter

> Regards
> Sridhar
>
>
>
> On Thursday, September 24, 2015 8:23 AM, Peter Crosthwaite
> <crosthwaitepeter@gmail.com> wrote:
>
>
> On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>> On 23 September 2015 at 03:48, sridhar kulkarni <sridhar_kulk@yahoo.com>
>> wrote:
>>> Hi Peter,
>>>
>>> I was able to progress well using the BE8 work in the branch that you
>>> pointed out. I am experiencing floating point issue. The qemu just exits,
>>> by
>>> putting a message that "floating point exception(core dumped)". I suppose
>>> QEMU do support floating point operations. I heard about hard floating
>>> point
>>> and soft floating point support. Is there any configuration option in
>>> QEMU
>>> for floating point?
>>
>> QEMU's floating point support for ARM is good and known to work.
>> If QEMU exits with a coredump then that is either:
>>  * your test binary is dumping core due to a bug in your test
>>    (assuming you're using linux-user mode)
>>  * a bug in QEMU (unlikely but not impossible)
>>
>> If you can provide a reproducible test case we can have a look at it.
>>
>
> Yes, so the thing stopping me upstreaming this was a reasonable test.
> Can I have a look at your reproducer?
>
> Regards,
>
> Peter
>
>> thanks
>> -- PMM
>
>
>

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

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 with 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, 0xe003b486Trace 0x7f1af25f8410 [e003b47c] R00=00000001 R01=0001c200 R02=00000001 R03=c16890e8R04=c16890e8 R05=e003b18c R06=00000080 R07=0000a000R08=ffffffff R09=00000001 R10=0001c200 R11=00000000R12=00000000 R13=c1c3a320 R14=e003b33d R15=e003b47cPSR=20000133 --C- T svc32----------------IN: 0xe003b486: f8d4 b01c ldr.w fp, [r4, #28]0xe003b48a: f44f 5180 mov.w r1, #4096 ; 0x10000xe003b48e: f241 1021 movw r0, #4385 ; 0x11210xe003b492: f8ab 1000 strh.w r1, [fp]0xe003b496: f64f 4100 movw r1, #64512 ; 0xfc000xe003b49a: f2c7 4102 movt r1, #29698 ; 0x74020xe003b49e: 8008 strh r0, [r1, #0]0xe003b4a0: f242 1012 movw r0, #8466 ; 0x21120xe003b4a4: 8048 strh----------------IN: 0x00000194: e121f000 msr CPSR_c, r0Trace 0x7f1af259c000 [00000194] R00=8000039f R01=80000380 R02=770004c8 R03=80000380R04=00000148 R05=00000000 R06=c16890e8 R07=00000001R08=00000001 R09=00000000 R10=00000000 R11=c16746e1R12=00000000 R13=00004b80 R14=00000188 R15=00000194PSR=80000380 N--- A usr26qemu: hardware error: bank number requested for bad CPSR mode value 0x0CPU #0:R00=8000039f R01=80000380 R02=770004c8 R03=80000380R04=00000148 R05=00000000 R06=c16890e8 R07=00000001R08=00000001 R09=00000000 R10=00000000 R11=c16746e1R12=00000000 R13=00004b80 R14=00000188 R15=00000194PSR=80000380 N--- A usr26s00=00000000 s01=00000000 d00=0000000000000000s02=00000000 s03=00000000 d01=0000000000000000s04=00000000 s05=00000000 d02=0000000000000000s06=00000000 s07=00000000 d03=0000000000000000s08=00000000 s09=00000000 d04=0000000000000000s12=00000000 s13=00000000 d06=0000000000000000s14=00000000 s15=00000000 d07=0000000000000000s16=00000000 s17=00000000 d08=0000000000000000s18=00000000 s19=00000000 d09=0000000000000000s20=00000000 s21=00000000 d10=0000000000000000s22=00000000 s23=00000000 d11=0000000000000000s24=00000000 s25=00000000 d12=0000000000000000s26=00000000 s27=00000000 d13=0000000000000000s28=00000000 s29=00000000 d14=0000000000000000s30=00000000 s31=00000000 d15=0000000000000000s32=00000000 s33=00000000 d16=0000000000000000s34=00000000 s35=00000000 d17=0000000000000000s36=00000000 s37=00000000 d18=0000000000000000s38=00000000 s39=00000000 d19=0000000000000000s40=00000000 s41=00000000 d20=0000000000000000s42=00000000 s43=00000000 d21=0000000000000000s44=00000000 s45=00000000 d22=0000000000000000s46=00000000 s47=00000000 d23=0000000000000000s48=00000000 s49=00000000 d24=0000000000000000s50=00000000 s51=00000000 d25=0000000000000000s52=00000000 s53=00000000 d26=0000000000000000s54=00000000 s55=00000000 d27=0000000000000000s56=00000000 s57=00000000 d28=0000000000000000s58=00000000 s59=00000000 d29=0000000000000000s60=00000000 s61=00000000 d30=0000000000000000s62=00000000 s63=00000000 d31=0000000000000000FPSCR: 03000000Aborted (core dumped)

_______________________________________________________
Please let me know if you have inputs for this crash. Also let me know if you need any further info to help look in to this.
RegardsSridhar　

 


     On Thursday, September 24, 2015 9:47 PM, Peter Crosthwaite <crosthwaitepeter@gmail.com> wrote:
   

 On Thu, Sep 24, 2015 at 3:48 AM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> The issue is mostly related to my application under test. When the
> application calls a function the PC is getting set up to a wrong address,
> and then qemu crashes by displaying "floating point exception(core dumped)"
> message.
> I am able to move ahead by resolving the issue.

Was this a QEMU bug or an issue in your program?

But interestingly whenever
> my app crashes it always displays the same "floating point exception"
> message. But I don't see any floating operations at the point code crashes.
> I don't see any dump of the processor registers also. It's always just a one
> line message as I described above.
>

Ok, are you unable to share the binary or source? Alternatively, can
you strip it down to a super-minimal program that replicates just this
one issue? Pasting us a GDB backtrace of the failure might help as
well.

Regards,
Peter

> Regards
> Sridhar
>
>
>
> On Thursday, September 24, 2015 8:23 AM, Peter Crosthwaite
> <crosthwaitepeter@gmail.com> wrote:
>
>
> On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>> On 23 September 2015 at 03:48, sridhar kulkarni <sridhar_kulk@yahoo.com>
>> wrote:
>>> Hi Peter,
>>>
>>> I was able to progress well using the BE8 work in the branch that you
>>> pointed out. I am experiencing floating point issue. The qemu just exits,
>>> by
>>> putting a message that "floating point exception(core dumped)". I suppose
>>> QEMU do support floating point operations. I heard about hard floating
>>> point
>>> and soft floating point support. Is there any configuration option in
>>> QEMU
>>> for floating point?
>>
>> QEMU's floating point support for ARM is good and known to work.
>> If QEMU exits with a coredump then that is either:
>>  * your test binary is dumping core due to a bug in your test
>>    (assuming you're using linux-user mode)
>>  * a bug in QEMU (unlikely but not impossible)
>>
>> If you can provide a reproducible test case we can have a look at it.
>>
>
> Yes, so the thing stopping me upstreaming this was a reasonable test.
> Can I have a look at your reproducer?
>
> Regards,
>
> Peter
>
>> thanks
>> -- PMM
>
>
>



  

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Maydell]

On 23 October 2015 at 12:11, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
> 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 with
> 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=00000001 R01=0001c200 R02=00000001 R03=c16890e8
> R04=c16890e8 R05=e003b18c R06=00000080 R07=0000a000
> R08=ffffffff R09=00000001 R10=0001c200 R11=00000000
> R12=00000000 R13=c1c3a320 R14=e003b33d R15=e003b47c
> PSR=20000133 --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=8000039f R01=80000380 R02=770004c8 R03=80000380
> R04=00000148 R05=00000000 R06=c16890e8 R07=00000001
> R08=00000001 R09=00000000 R10=00000000 R11=c16746e1
> R12=00000000 R13=00004b80 R14=00000188 R15=00000194
> PSR=80000380 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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[sridhar kulkarni]

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

Hi Peter,
I further debugged this issues,

Arround line 5000 of file helper.c, I guess updation of uncached_cpsrwas not proper.  I changed following line  FROM env->uncached_cpsr = (env->uncached_cpsr & !(CPSR_E)) |       (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0); TO env->uncached_cpsr = (env->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 application 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.
RegardsSridhar
 


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

 On 23 October 2015 at 12:11, sridhar kulkarni <sridhar_kulk@yahoo.com> wrote:
> 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 with
> 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=00000001 R01=0001c200 R02=00000001 R03=c16890e8
> R04=c16890e8 R05=e003b18c R06=00000080 R07=0000a000
> R08=ffffffff R09=00000001 R10=0001c200 R11=00000000
> R12=00000000 R13=c1c3a320 R14=e003b33d R15=e003b47c
> PSR=20000133 --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=8000039f R01=80000380 R02=770004c8 R03=80000380
> R04=00000148 R05=00000000 R06=c16890e8 R07=00000001
> R08=00000001 R09=00000000 R10=00000000 R11=c16746e1
> R12=00000000 R13=00004b80 R14=00000188 R15=00000194
> PSR=80000380 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


  

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

Re: [Qemu-devel] qemu-system-arm system support for big endian BE8

[Peter Crosthwaite]

On Fri, Oct 23, 2015 at 8:47 PM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> Hi Peter,
>
> I further debugged this issues,
>
>
> Arround line 5000 of file helper.c, I guess updation of uncached_cpsr was
> not proper.  I changed following line
>

You can use git to generate this change information for you in a
standard format. try git diff at first. Then as you make commits git
show and when you come to submit changes, git format-patch.

> FROM
>
> env->uncached_cpsr = (env->uncached_cpsr & !(CPSR_E)) |
>         (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0);
>
> TO
>
> env->uncached_cpsr = (env->uncached_cpsr & ~(CPSR_E)) |
>         (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE ? CPSR_E : 0);
>

Looks better. I think you might be working on out-of-tree code though.
You might want to look into rebasing your work and submitting the
patches for inclusion in mainline QEMU. You would amend this change
into the commit that got it wrong in the first place.

Regards,
Peter

>
> This fixed the crash that I reported earlier. With this my application 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
> Sridhar
>
>
>
>
> On Friday, October 23, 2015 5:26 PM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
>
>
> On 23 October 2015 at 12:11, sridhar kulkarni <sridhar_kulk@yahoo.com>
> wrote:
>> 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
>> with
>> 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=00000001 R01=0001c200 R02=00000001 R03=c16890e8
>> R04=c16890e8 R05=e003b18c R06=00000080 R07=0000a000
>> R08=ffffffff R09=00000001 R10=0001c200 R11=00000000
>> R12=00000000 R13=c1c3a320 R14=e003b33d R15=e003b47c
>> PSR=20000133 --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=8000039f R01=80000380 R02=770004c8 R03=80000380
>> R04=00000148 R05=00000000 R06=c16890e8 R07=00000001
>> R08=00000001 R09=00000000 R10=00000000 R11=c16746e1
>> R12=00000000 R13=00004b80 R14=00000188 R15=00000194
>> PSR=80000380 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
>
>