Status of the GCC/ARM_CM55 (and _NTZ) ports

I am curious on the status of the ARM_CM55 port, as I am starting a project with a CM55 processor. The port seems almost identical to the CM33, which make sense, but it seems TOO close. The only differences seem to be the value of the macro portARCH_NAME and that the port creates an error if configENABLE_MVE is not defined (but it then never uses that value). This makes me think there may not be support for the MVE in the port.

I know this is a fairly new core from Arm, and there may not be much background, but any hints about what rough edges I might hit in using the part would be appreciated.

I would need to refamiliarise myself to provide a complete answer, which I suspect Gaurav and Arm will be able to do sooner. Here are a couple of links to help:

The Cortex-M33 port also works on M55, explaining the similarity, but not explicit on additions required for MVE support - although I believe the vector registers alias onto the FPU registers

This commit (made by Arm) added M85 support. :

Blog with a link to a demo, also from Arm: Previewing the new Arm Corstone FreeRTOS Featured Reference Integration - FreeRTOS

Ok, The similarity between M33 and M55 except for the requirement of the configENABLE_MVE define seemed unusual.

I recall talking to @PaulB-AWS about this - I think that it might also be because the MVE and FPU config options are identical at the port layer?

According to the Armv8-M Architecture Reference Manual, It is possible for an ARMv8M core to include integer-only MVE and not include an FPU. For this reason, configENABLE_MVE is included as a configuration option.

As @rtel noted, the registers used by the FPU and MVE extensions are the same. From a FreeRTOS perspective, the stacking/un-stacking of these registers is the same regardless of whether the FPU extension, MVE extension, or both are included in your particular silicon.

1 Like

The concern was that the M33 port doesn’t require the configENABLE_MVE to be defined, but just uses the macro. The M55 requires the configENABLE_MVE to be defined, even if it uses in exactly the same way.

It sounds like the processors all have similar hardware for this, so the port doesn’t change, but for some reason only the M55 port check that the macro is defined.

1 Like

Thanks for the explanation! I looked into it a bit more, the MVE extension looks like it was added in the ARMv8-M.1 Architecture:

But the CM33 is using the Arvm8-M architecture according to the product comparison table

So that would potentially explain why this check isn’t in the CM33 port

Perhaps, but the CM33 port does USE that symbol (normally in test of either FPU or MVE) which maybe shouldn’t be there if M33’s can’t have an MVE (but won’t cause a problem unless you say you are using the MVE when you have one)

Yeah, I agree it seems a bit misleading for the port to mention it when the CPU itself doesn’t have the support. I feel like since it’s always OR’d with the configENABLE_FPU in the common ARMv8M port.c file (link to example) that it’s a bit more okay? But agree it’s a bit odd.

I’ll need to look into if the work being done in prvSetupFPU() is needed when using the FPU but NOT needed when using the MVE extension. Since if the MVE Extension actually requires this as well, it seems like it might be worth just combining these two configs?

configENABLE_MVE is only applicable to M55 and M85. We should error out if it is set to 1 for M23 or M33 ports. Good catch!

This PR addresses it - Add a check for configENABLE_MVE to M23, M33 ports by aggarg · Pull Request #968 · FreeRTOS/FreeRTOS-Kernel · GitHub.