| Message ID | 1481130858-31767-1-git-send-email-julian@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On 7 December 2016 at 17:14, Julian Brown <julian@codesourcery.com> wrote: > The value of the MVFR1 (Media and VFP Feature Register 1) register for > the Cortex-A8 appears to be incorrect (according to the TRM, DDI0344K), > with the "full denormal arithmetic" and "propagation of NaN" fields > holding both 0 instead of both 1. > > I had a go tracing the history of the use of this value, and it seems > it's always just been wrong in QEMU: maybe it was derived from early > documentation, or guessed based on the use of a "VFP Lite" implementation > in the Cortex-A8. > > Depending on the startup/early-boot code in use, this can manifest as > failure to perform denormal arithmetic properly: in our case, selecting > a Cortex-A8 CPU when using QEMU as an instruction-set simulator for > bare-metal GCC testing caused tests using denormal arithmetic to > fail. Problems might be masked (or not occur) when using a full OS kernel > with suitable trap handlers (I'm not sure). > > Signed-off-by: Julian Brown <julian@codesourcery.com> Applied to target-arm.next for 2.9, thanks. -- PMM
diff --git a/target-arm/cpu.c b/target-arm/cpu.c index 7946877..a609211 100644 --- a/target-arm/cpu.c +++ b/target-arm/cpu.c @@ -1109,7 +1109,7 @@ static void cortex_a8_initfn(Object *obj) cpu->midr = 0x410fc080; cpu->reset_fpsid = 0x410330c0; cpu->mvfr0 = 0x11110222; - cpu->mvfr1 = 0x00011100; + cpu->mvfr1 = 0x00011111; cpu->ctr = 0x82048004; cpu->reset_sctlr = 0x00c50078; cpu->id_pfr0 = 0x1031;
The value of the MVFR1 (Media and VFP Feature Register 1) register for the Cortex-A8 appears to be incorrect (according to the TRM, DDI0344K), with the "full denormal arithmetic" and "propagation of NaN" fields holding both 0 instead of both 1. I had a go tracing the history of the use of this value, and it seems it's always just been wrong in QEMU: maybe it was derived from early documentation, or guessed based on the use of a "VFP Lite" implementation in the Cortex-A8. Depending on the startup/early-boot code in use, this can manifest as failure to perform denormal arithmetic properly: in our case, selecting a Cortex-A8 CPU when using QEMU as an instruction-set simulator for bare-metal GCC testing caused tests using denormal arithmetic to fail. Problems might be masked (or not occur) when using a full OS kernel with suitable trap handlers (I'm not sure). Signed-off-by: Julian Brown <julian@codesourcery.com> --- target-arm/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)