qemu-system-arm, configurable does not work with cpu_model=cortex-m4

[GregIthaca]

It appears to me that the logic between the code here:
https://github.com/avatartwo/avatar-qemu/blob/d774496465cc77949be27d0a425264ef6eeaf05d/hw/avatar/configurable_machine.c#L499
and the code here:
https://github.com/avatartwo/avatar-qemu/blob/d774496465cc77949be27d0a425264ef6eeaf05d/target/arm/cpu.c#L1434
creates an unfortunate conflict. If you specify in your configurable device a cpu_model of "cortex-m3" everything works as expected. However if you specify a cpu_model of "cortex-m4" (for example, because your binary requires the vfp instructions) then the emulator terminates with the very mysterious message:

This board cannot be used with Cortex-M CPUs

Is my diagnosis of this correct? Would adding the option to match cortex-m4 in configurable_machine.c address the issue?

This is somewhat related to #116

[aurelf]

The error message is indeed lacking clarity, but IIRC the support for M4 isn't complete. Is that correct @mariusmue @rawsample ?

[rawsample]

Hi,

Indeed the error message is not clear.
If your binary doesn't make usage of cortex-m4 additional features such as FPU, DSP, etc., you should be able to use the cortex-m3 core for emulation.

Simply changing the option to cortex-m4 would not solve the issue because avatar2 python part has no knowledge of it: https://github.com/avatartwo/avatar2/blob/main/avatar2/archs/arm.py

[GregIthaca]

In my case, the binary includes VFP instructions. It was originally built for STM32F405, which happens to be a supported target for core QEMU, so I sort of assumed that all would work OK. After the configurable_machine.c patch below (to a slightly older version, so it doesn't apply directly to the current development branch) it seemed to work for my needs.

499c499
<     if (!strcmp(cpu_type, "cortex-m3")) {
---
>     if (!strcmp(cpu_type, "cortex-m3") || !strcmp(cpu_type, "cortex-m4")) {
508c508,512
<         qdev_prop_set_string(dstate, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
---
>         if (!strcmp(cpu_type, "cortex-m3")) {
>             qdev_prop_set_string(dstate, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
>         } else {
>             qdev_prop_set_string(dstate, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
>         }

[aurelf]

I discussed with a student here (Florian) he seem to have a fix for that and will come back here soon about it.

[albrecht-flo]

On the QEMU side my idea is pretty much what @GregIthaca proposes, QEMU has support for the full cortex-m4 with FPU and DSP.

On the python side a quickfix would be to add this architecture in arm.py:

class ARM_CORTEX_M4(ARM_CORTEX_M3):
    cpu_model = 'cortex-m4'

Although this will NOT transfer the state of the FPU, it will transfer all the other state as the M4 and M3 overlap in most things, just the FPU adds new registers to the M4.
Although, the FPU is an optional feature, we might want to have 2 separate architectures, one with and one without the FPU registers?

[GregIthaca]

Yes, unfortunately it's potentially even more complicated than that, since some core version could theoretically implement only portions of the VFP. But based on the contents of the QEMU cpu->isar.mvfr0 = 0x10110021 (here) QEMU is going to assume that M4=VFPv2.

[albrecht-flo]

Yes but QEmu would still be able to run those firmwares, as long as it provides a superset implementing all operations present in the firmware.
It is not an exact replication but in most cases it should be sufficient.