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 <karthikshanmu...@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.mayd...@linaro.org> wrote: > >> On 24 May 2016 at 14:49, Karthik <karthikshanmu...@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 >> >