search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.93k stars 6.65k forks source link

Add Cortex-M4 testing platform #22870

Closed stephanosio closed 2 years ago

stephanosio commented 4 years ago

Currently, there is no emulated testing platform available for the floating point-capable ARM M-profile devices (i.e. Cortex-M4 and above).

Since the QEMU 5.0.0 will add the netduinoplus2 machine, which emulates the STM32F405 SoC that embeds the Cortex-M4F core, once released and integrated into the Zephyr SDK, add the qemu_cortex_m4 to serve as the primary testing platform for the ARMv7-M devices.

~In addition, once we add qemu_cortex_m4, remove qemu_cortex_m3 as qemu_cortex_m4 is a superset of it and mps2_an385 already serves as the default testing platform for the Cortex-M3 devices.~

~Instead of removing qemu_cortex_m3, make it the default MPU/FPU-less testing platform and make qemu_cortex_m4 the default MPU+FPU(+DSP) testing platform. In addition, phase out mps2_an385 as the default testing platform, since both MPU-less and MPU-ful test cases will be covered by qemu_cortex_m3 and qemu_cortex_m4, respectively.~ Keep mps2_an385 as the default testing platform since its test coverage is better compared to qemu_cortex_m3 (305 vs 261, respectively).

Notes:

stephanosio commented 4 years ago

cc @ioannisg @galak

ioannisg commented 4 years ago

Nice to do for next release

stephanosio commented 4 years ago

https://wiki.qemu.org/ChangeLog/5.0 https://wiki.qemu.org/Planning/5.0

stephanosio commented 4 years ago

NOTE: Running STM32F405 Zephyr image on QEMU netduinoplus2 requires some (not upstreamed yet) patches:

https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg07841.html https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg07842.html

In summary, Zephyr links code and rodata in the flash at 0x8000000, which is aliased to 0x0. QEMU has a bug in which the ROM reset handler is executed after the CPU reset handler, and this causes the aliased memory data to be unavailable at the time of CPU vector table read and SP/PC initialisation- leading to boot failure.

stephanosio commented 4 years ago

NOTE: Running STM32F405 Zephyr image on QEMU netduinoplus2 requires some (not upstreamed yet) patches:

https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg07841.html https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg07842.html

In summary, Zephyr links code and rodata in the flash at 0x8000000, which is aliased to 0x0. QEMU has a bug in which the ROM reset handler is executed after the CPU reset handler, and this causes the aliased memory data to be unavailable at the time of CPU vector table read and SP/PC initialisation- leading to boot failure.

In addition, the STM32Cube driver used by Zephyr expects the RCC and FLASH peripheral registers, which are currently not emulated on the QEMU, to function properly. The following patches add emulation support for these two peripherals:

https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg08453.html https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg00001.html

nashif commented 3 years ago

@stephanosio are you still looking into that?

stephanosio commented 3 years ago

@ioannisg Have we managed to get an alternative for this? Or do we still need this?

ioannisg commented 3 years ago

@ioannisg Have we managed to get an alternative for this? Or do we still need this?

@stephanosio I have an open pr for qemu support on cortex-m33. So we will cover fpu testing on a slightly different ARCH though... Maybe worth keeping this open

stephanosio commented 3 years ago

@stephanosio I have an open pr for qemu support on cortex-m33. So we will cover fpu testing on a slightly different ARCH though... Maybe worth keeping this open

Comparing the QEMU emulation feature sets of Cortex-M4 and Cortex-M33:

Cortex-M4

    set_feature(&cpu->env, ARM_FEATURE_V7);
    set_feature(&cpu->env, ARM_FEATURE_M);
    set_feature(&cpu->env, ARM_FEATURE_M_MAIN);
    set_feature(&cpu->env, ARM_FEATURE_THUMB_DSP);
    set_feature(&cpu->env, ARM_FEATURE_VFP4);

Cortex-M33

    set_feature(&cpu->env, ARM_FEATURE_V8);
    set_feature(&cpu->env, ARM_FEATURE_M);
    set_feature(&cpu->env, ARM_FEATURE_M_MAIN);
    set_feature(&cpu->env, ARM_FEATURE_M_SECURITY);
    set_feature(&cpu->env, ARM_FEATURE_THUMB_DSP);
    set_feature(&cpu->env, ARM_FEATURE_VFP4);

As far as the QEMU emulation goes, Cortex-M33F can be thought of as a simple superset of Cortex-M4F, and considering the main reason for adding M4F support was to facilitate Cortex-M floating point testing in Zephyr, I am not sure if there is any major advantage in adding M4F support alongside your planned M33 FP support.

I don't think there is anything Cortex-M4F emulation can offer that Cortex-M33F emulation cannot. Do you agree? @ioannisg

ioannisg commented 3 years ago

I don't think there is anything Cortex-M4F emulation can offer that Cortex-M33F emulation cannot. Do you agree? @ioannisg

What I was thinking of is the combination of FPU along with the (legacy) MPU architecture of Cortex-M4. If we care about that, we could only test it on M4F (or M7F), but not M33F.

stephanosio commented 3 years ago

What I was thinking of is the combination of FPU along with the (legacy) MPU architecture of Cortex-M4. If we care about that, we could only test it on M4F (or M7F), but not M33F.

In that case, I will look into resurrecting this PR.

stephanosio commented 3 years ago

Marking it low priority since #35381 already addresses the main problem at hand, which was lack of ARM hard FP testing in the CI.

stephanosio commented 2 years ago

Although #35381 introduced the mps2_an521_remote target, which executes code on the CPU 1, a Cortex-M33F core that supports DSP and single-precision FPU, it has some limitations:

  1. Its code memory is limited to 512K due to the TFM partitioning, which is not enough for some tests (e.g. CMSIS-DSP).

    https://github.com/zephyrproject-rtos/zephyr/blob/88ca4fb5336151f11857f966bb8ed1e11bf1962d/boards/arm/mps2_an521/mps2_an521_remote.dts#L104-L106

  2. It does not support double precision FPU (Cortex-M33 core cannot be configured with double-precision support).

QEMU introduced the MPS2-AN386 machine type, which includes a Cortex-M4 core, so consider adding the support for it.

Also there exists MPS2-AN500, which includes a Cortex-M7 core, so consider adding it also in order to support double-precision coverage.

stephanosio commented 2 years ago

Closing this in favour of https://github.com/zephyrproject-rtos/zephyr/issues/45319