[Qemu-devel] ARM Cortex R5 + VFP3

[Qemu-devel] ARM Cortex R5 + VFP3

[Karthik]

Hi,

I am working on adding support for a Spansion microcontroller which has an
Cortex R5 core + VFP3 co processor.

I have added the below line
set_feature(&cpu->env, ARM_FEATURE_VFP3)
to cortex_r5_initfn at /target-arm/cpu.c

But, still I got undefined exception when the processor encountered any VFP
instructions.

To get around the error, I had to enable code protected by CONFIG_USER_ONLY.

Specifically in arm_cpu_reset, where
the bits 20 to 24 are set in env->cp15.cpacr_el1 and
env->vfp.xregs[ARM_VFP_FPEXC] = 1 << 30.

I am sure there is correct way to do things. I'm new to qemu.

Any help will be much appreciated. Thank you.

Best regards,
Karthik

Re: [Qemu-devel] ARM Cortex R5 + VFP3

[Peter Maydell]

On 24 May 2016 at 14:07, Karthik <karthikshanmugam@gmail.com> wrote:
> I am working on adding support for a Spansion microcontroller which has an
> Cortex R5 core + VFP3 co processor.
>
> I have added the below line
> set_feature(&cpu->env, ARM_FEATURE_VFP3)
> to cortex_r5_initfn at /target-arm/cpu.c
>
> But, still I got undefined exception when the processor encountered any VFP
> instructions.

Has your guest code actually enabled the floating point?
It needs to write to CPACR_EL1 itself to set the FPEXC bit. Otherwise
we will correctly generate an exception, just as the real hardware
will. The code you mention is in CONFIG_USER_ONLY because if we
are only emulating a user process then we simulate the behaviour that
a Linux kernel has of setting the CPACR correctly. For system
emulation setting the bit is the guest code's responsibility.

thanks
-- PMM

Re: [Qemu-devel] ARM Cortex R5 + VFP3

[Karthik]

ahh okay. The code I don't think writes to CPACR_EL1 register, but it runs
on the hardware anywary.

I`ll double check.

Thanks for the tip.

Best regards,
Karthik

On Tue, May 24, 2016 at 7:07 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 24 May 2016 at 14:07, Karthik <karthikshanmugam@gmail.com> wrote:
> > I am working on adding support for a Spansion microcontroller which has
> an
> > Cortex R5 core + VFP3 co processor.
> >
> > I have added the below line
> > set_feature(&cpu->env, ARM_FEATURE_VFP3)
> > to cortex_r5_initfn at /target-arm/cpu.c
> >
> > But, still I got undefined exception when the processor encountered any
> VFP
> > instructions.
>
> Has your guest code actually enabled the floating point?
> It needs to write to CPACR_EL1 itself to set the FPEXC bit. Otherwise
> we will correctly generate an exception, just as the real hardware
> will. The code you mention is in CONFIG_USER_ONLY because if we
> are only emulating a user process then we simulate the behaviour that
> a Linux kernel has of setting the CPACR correctly. For system
> emulation setting the bit is the guest code's responsibility.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] ARM Cortex R5 + VFP3

[Peter Maydell]

On 24 May 2016 at 14:49, Karthik <karthikshanmugam@gmail.com> wrote:
> ahh okay. The code I don't think writes to CPACR_EL1 register, but it runs
> on the hardware anywary.

If it does then there's probably some firmware somewhere
which is doing the setup for you somehow.

As you can see in the Cortex-R5 technical reference manual entry
for CPACR:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html

the hardware reset value for bits 21..23 is 0, meaning access denied,
and for FPEXC the EN bit is clear on reset:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html

By the way, QEMU doesn't implement VFPv3-D16, which is what the R5
ought to have -- setting the ARM_FEATURE_VFP3 bit will give you
32 double-precision registers. This is probably close enough that
guest code will work, though obviously if the guest specifically
tests that registers 16..31 don't exist it will not behave as
the hardware does.

thanks
-- PMM

Re: [Qemu-devel] ARM Cortex R5 + VFP3

[Karthik]

Yeah, the micro had a secure boot ROM which we don't have access to.
Probably it is enabled there. I'll check in the target hardware.

The code generated by the compiler doesn't specifically check for
non-existent registers, so we should be good using VFP3 in place for
VFP3-D16.

Best regards,
Karthik
On May 24, 2016 7:31 PM, "Peter Maydell" <peter.maydell@linaro.org> wrote:

> On 24 May 2016 at 14:49, Karthik <karthikshanmugam@gmail.com> wrote:
> > ahh okay. The code I don't think writes to CPACR_EL1 register, but it
> runs
> > on the hardware anywary.
>
> If it does then there's probably some firmware somewhere
> which is doing the setup for you somehow.
>
> As you can see in the Cortex-R5 technical reference manual entry
> for CPACR:
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html
>
> the hardware reset value for bits 21..23 is 0, meaning access denied,
> and for FPEXC the EN bit is clear on reset:
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html
>
> By the way, QEMU doesn't implement VFPv3-D16, which is what the R5
> ought to have -- setting the ARM_FEATURE_VFP3 bit will give you
> 32 double-precision registers. This is probably close enough that
> guest code will work, though obviously if the guest specifically
> tests that registers 16..31 don't exist it will not behave as
> the hardware does.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] ARM Cortex R5 + VFP3

[Karthik]

Hi,

Added enabling VFP co-processor in the bootrom emulation code. Works like a
charm.

Many thanks.

Best regards,
Karthik


On Tue, May 24, 2016 at 7:52 PM, Karthik <karthikshanmugam@gmail.com> wrote:

> Yeah, the micro had a secure boot ROM which we don't have access to.
> Probably it is enabled there. I'll check in the target hardware.
>
> The code generated by the compiler doesn't specifically check for
> non-existent registers, so we should be good using VFP3 in place for
> VFP3-D16.
>
> Best regards,
> Karthik
> On May 24, 2016 7:31 PM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
>> On 24 May 2016 at 14:49, Karthik <karthikshanmugam@gmail.com> wrote:
>> > ahh okay. The code I don't think writes to CPACR_EL1 register, but it
>> runs
>> > on the hardware anywary.
>>
>> If it does then there's probably some firmware somewhere
>> which is doing the setup for you somehow.
>>
>> As you can see in the Cortex-R5 technical reference manual entry
>> for CPACR:
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html
>>
>> the hardware reset value for bits 21..23 is 0, meaning access denied,
>> and for FPEXC the EN bit is clear on reset:
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html
>>
>> By the way, QEMU doesn't implement VFPv3-D16, which is what the R5
>> ought to have -- setting the ARM_FEATURE_VFP3 bit will give you
>> 32 double-precision registers. This is probably close enough that
>> guest code will work, though obviously if the guest specifically
>> tests that registers 16..31 don't exist it will not behave as
>> the hardware does.
>>
>> thanks
>> -- PMM
>>
>