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

[Karthik <karthikshanmugam@gmail.com>]

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