arm: core: cortex_m: add a barrier before the dummy FP instruction

[aurel32]

On Cortex-M7 CPU (at least on STM32F723 with patches from #7284), the dummy move FPU instruction is executed before the FPU lazy state preservation is disabled. This patch adds a barrier before it to avoid that.

This can be easily reproduced with a simple example, like hello_world, by setting CONFIG_FLOAT=y. The system goes in an endless loop very early, before outputting anything on the console. This is something difficult to debug, as executing the instructions step by step in GDB hides the problem. I guess the other Cortex-M7 based platforms are also affected: NXP i.MX RT and Microchip SAM E70. I guess @MaureenHelm can test the first one.

[codecov-io]

Codecov Report

Merging #8373 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8373   +/-   ##
=======================================
  Coverage   64.61%   64.61%           
=======================================
  Files         423      423           
  Lines       40293    40293           
  Branches     6801     6801           
=======================================
  Hits        26034    26034           
  Misses      11126    11126           
  Partials     3133     3133

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a55c72d...b7335c8. Read the comment docs.

[galak]

Do we need both isb & dsb?

[ioannisg]

Good point, I would think that only the instruction barrier is required.

[aurel32]

Do we need both isb & dsb?

I have to say I copied the barriers from below. From what I understand we need both:

• dsb to make sure the write to FPCCR is finished
• isb to empty the pipeline and execute vmov using the new FPU configuration

[ioannisg]

IMHO, a DSB instruction would be needed if we are doing read/write to RAM or system registers and then use that value (so make sure the value is updated before performing new access).
Here, all we need to guarantee is that the FPCCR is updated before we do the dummy write, so we only need to preserve execution synchronization (but we do not use the value of the FPCCR anywhere).

[aurel32]

Ok, I think I got it. Given your explanation I guess it also means the dsb after the vmov is useless.

[aurel32]

I have just pushed a new version without the dsb instruction.

[agross-oss]

with the dsb removal this looks ok

[ioannisg]

Looks OK to me.

[ioannisg]

I think the commit message prefix should read: "arch: arm: ......."

[aurel32]

I have just updated the patch to add the "arch:" prefix.