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.73k stars 6.55k forks source link

Add provisions for supporting multiple CMSIS variants #19717

Closed stephanosio closed 5 years ago

stephanosio commented 5 years ago

At the time of writing, the Zephyr repository only includes CMSIS-Core(M) variant under ext/hal/cmsis and assumes that the only form of "CMSIS" available is CMSIS-Core(M).

In order to facilitate the development of Cortex-A and Cortex-R ports, the CMSIS-to-Zephyr RTOS integration structure should be refactored to support multiple CMSIS-Core variants as well as other coprocessor and extension variants.

The planned implementation strategy is as follows (feel free to discuss and provide suggestions):

  1. Create a dedicated directory for CMSIS-Core(M) at ext/hal/cmsis/Core and relocate the current ext/hal/cmsis/Include to under it.

    • This is following the directory structure of the original CMSIS repository- Core directory is Core(M) variant.
    • Using the original CMSIS repository directory structure under ext/hal/cmsis should make future merging easier and avoid confusion as to what's what.
    • Other CMSIS variants can be added to ext/hal/cmsis/ using their original CMSIS repository directory name in the future as necessary; for instance, CMSIS-Core(A) may be added to ext/hal/cmsis/Core_A.

  2. Change Kconfig HAS_CMSIS to HAS_CMSIS_CORE.

    • The actual meaning of HAS_CMSIS currently is that CMSIS-Core(M) is used.
    • Separate Kconfig configurations for other forms of CMSIS can be added as necessary in the future. For example, add HAS_CMSIS_DSP for CMSIS-DSP.

  3. Make HAS_CMSIS_CORE automatically select the appropriate CMSIS-Core variant based on the core type configuration (-M, -A, -R).

    • Since it makes no sense to enable, for instance, CMSIS-Core(M) and CMSIS-Core(A) in the same project, automatic CMSIS-Core variant selection upon enabling HAS_CMSIS_CORE should not be a problem.
ioannisg commented 5 years ago

FYI @galak @MaureenHelm We also have the option would be to pull-in CMSIS via west; have we ruled-out this possibility?

stephanosio commented 5 years ago

@ioannisg Is the long term plan to completely phase out ext/? I see that all the SoC HALs have been recently moved out to separate repos.

ioannisg commented 5 years ago

There is a reason to keep CMSIS here @stephanosio ; that is to be able to run QEMU for ARM without external dependencies, but, i think we may well use the upstream code. We need to think seriously about this; there are certain consequences of moving CMSIS to external repo or using the upstream CMSIS directly

stephanosio commented 5 years ago

There is a reason to keep CMSIS here @stephanosio ; that is to be able to run QEMU for ARM without external dependencies

@ioannisg Since that means pulling CMSIS via west would be a problem, I will go ahead with implementing the changes described in this issue in ext/hal/cmsis and make a PR.

I'm still working on CMSIS-Core(R), so the initial PR will only make the necessary changes to accommodate other CMSIS variants.

ioannisg commented 5 years ago

So can this issue be closed now?

stephanosio commented 5 years ago

So can this issue be closed now?

Yes, all proposed changes have been implemented in #19875.