- Add initial support for ARMv8A, ARMV7R and ARMV8R

[Masmiseim36]

• Added core_cxx.h files for ARMv8A, ARMV7R and ARMV8R based profiles
• Moved gic peripheral to separate file
• Moved __FPU_Enable function to the architecture specific file

[github-actions[bot]]

Test Results

   240 files   -   132     240 suites   - 132   0s :stopwatch: - 8m 52s     56 tests +    7      54 :white_check_mark: +   10      2 :zzz:  -     3  0 :x: ±0  12 948 runs   - 5 280  10 860 :white_check_mark:  - 1 104  2 088 :zzz:  - 4 176  0 :x: ±0 

Results for commit 5ac68b52. ± Comparison against base commit 641cb5ec.

This pull request removes 49 and adds 56 tests. Note that renamed tests count towards both.

CMSIS-Core.src ‑ apsr.c
CMSIS-Core.src ‑ basepri.c
CMSIS-Core.src ‑ bkpt.c
CMSIS-Core.src ‑ clrex.c
CMSIS-Core.src ‑ clz.c
CMSIS-Core.src ‑ control.c
CMSIS-Core.src ‑ cp15.c
CMSIS-Core.src ‑ cpsr.c
CMSIS-Core.src ‑ dmb.c
CMSIS-Core.src ‑ dsb.c
…

TC_CML1Cache_CleanDCacheByAddrWhileDisabled
TC_CML1Cache_EnDisableDCache
TC_CML1Cache_EnDisableICache
TC_CoreFunc_APSR
TC_CoreFunc_BASEPRI
TC_CoreFunc_Control
TC_CoreFunc_EnDisIRQ
TC_CoreFunc_EncDecIRQPrio
TC_CoreFunc_FAULTMASK
TC_CoreFunc_FPSCR
…

This pull request removes 5 skipped tests and adds 2 skipped tests. Note that renamed tests count towards both.

CMSIS-Core.src ‑ lda.c
CMSIS-Core.src ‑ ldaex.c
CMSIS-Core.src ‑ stl.c
CMSIS-Core.src ‑ stlex.c
CMSIS-Core.src ‑ systick.c

TC_CoreInstr_WFE
TC_CoreInstr_WFI

:recycle: This comment has been updated with latest results.

[JonatanAntoni]

@Masmiseim36, could you please update this one with latest cleanups @GuentherMartin is working on, see PR #56.

[Masmiseim36]

are the CMSIS compiler include files missing in r-profile?

They come with this pull Request #44. That PR should be merged first It makes it a bit difficult to break-up the changes in small chunks. I did the testing with the complete change than break it up again to have smaller Pull-Requests

[JonatanAntoni]

See PR #58 fixing the tests.

[Masmiseim36]

I try to improve the test routines for the added architectures. There is still some work to do

[Masmiseim36]

It looks quite okay. All new core types are now checked in the automatic test.

I wanted to add another test, for which the core header files (core_cr4.h etc.) would have to be included. In the existing tests, however, "cmsis_compiler.h" was always included. This means that not everything is testable. Do you have a suggestion for this?

[JonatanAntoni]

Hi @Masmiseim36,

We have two sets of tests.

In Core/Test we indeed only have compiler header tests so far. But it should be possible to introduce core header tests in a similar way. The core header of the selected target is exposed as -DCORE_HEADER=<core_XXX.h>. I.e., you could create a test case and instead if #include "cmsis_compiler.h" you could have #include CORE_HEADER.

Now, creating core specific test cases might require us more elaborated filters in lit_cfg.py. I.e., depending on the core we might have different features to test or deviating expectations. This might easily become complex, hence I didn't go for it, yet.

Another set is in CoreValidation where we check runtime behaviour based on target. This requires execution in fast models (not yet accessible with Arm community license). Or, it could work with Qemu, but I never tried. It should be straight forward to add a build/test configuration for Cortex-R4. But it requires compiler and model support, which won't be part of Arm community license. It should work for GCC and Clang but in absence of a fast model we can't get the tests executed on GitHub.

[JonatanAntoni]

Just fyi, I got aware of another Cortex-R enhancement we didn't pick up, yet. https://github.com/stephanosio/CMSIS_5/blob/core_r/CMSIS/Core_R/

[Masmiseim36]

This PR introduces a backward compatibility issue by removing core_ca.h in favour of separate headers per core. Unfortunately, existing Cortex-A DFPs like Cortex DFP refer to core_ca.h explicitly. We need to somehow keep this one for compatibility reasons.

We could use the define __CORTEX_A to bridge into the new headers.

Thanks for the hint. I have reintroduced the file, with the original functionality. Bridging to the new headers would lead to a second definition of __CORTEX_A which would create a compiler warning.

Just fyi, I got aware of another Cortex-R enhancement we didn't pick up, yet. https://github.com/stephanosio/CMSIS_5/blob/core_r/CMSIS/Core_R/

Looks interesting

Another set is in CoreValidation where we check runtime behaviour based on target. This requires execution in fast models (not yet accessible with Arm community license). Or, it could work with Qemu, but I never tried. It should be straight forward to add a build/test configuration for Cortex-R4. But it requires compiler and model support, which won't be part of Arm community license. It should work for GCC and Clang but in absence of a fast model we can't get the tests executed on GitHub.

Thanks for the feedback. I'm trying to read up on the subject. Simulator-based tests are also new to me. My idea was quite simple. I wanted to compile the functions for GIC, Cache, Timer, MMU, FPU with every compiler and target without errors.

[JonatanAntoni]

Thanks for the hint. I have reintroduced the file, with the original functionality. Bridging to the new headers would lead to a second definition of __CORTEX_A which would create a compiler warning.

True, sorry, I was mislead by the different approach we used for core_ca.h. Instead of defining __CORTEX_A in the core header we moved the define to the device header. So yes, just lets keep the core_ca.h for compatibility reasons.

Thanks for the feedback. I'm trying to read up on the subject. Simulator-based tests are also new to me. My idea was quite simple. I wanted to compile the functions for GIC, Cache, Timer, MMU, FPU with every compiler and target without errors.

The core tests using LLVM's lit utility run static checks on the compiler output. While this is feasible for simple stuff it might become arbitrarily complex for (extensive) C code. The compiler has a high degree of freedom how to translate certain C statements into assembly language. Of course, lit can be used at any level and not only on disassembly. But I doubt we can find any representation of compiler output that allows consistent/stable checks across different toolchains and versions.

Hence, this kind of tests should rather go to CoreValidation. Even without execution you could enhance the build configurations and check at least error (and warning) free compilation. On the long run we should check if we can add models for all relevant A and R class processors so that we can execute the dynamic checks. The devil is often in the details and even if the C code passe compilation it can easily cause faults at runtime.

[Masmiseim36]

Hello @JonatanAntoni ,

I have tried to get the CoreValidation Suite to work. Unfortunately I get an error message. Is another environment variable missing?

  CMake Error at CMakeLists.txt:59 (project):
  The CMAKE_C_COMPILER:

    armclang

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.

I also noticed that the readme for the CoreValidation Suite does not mention that the Cortex_DFP package (https://github.com/ARM-software/Cortex_DFP) must be installed.

If I understand correctly, this package must first be extended for the new core types in order to be able to test them here. But first I want to be able to run the current version locally.

[JonatanAntoni]

I have tried to get the CoreValidation Suite to work. Unfortunately I get an error message. Is another environment variable missing?

I am not sure, but it might be missing the AC6_TOOLCHAIN_6_21_0=/path/to/armclang-6.21/bin variable which is used to find the install location of different toolchains and versions. If you are installing Arm Compiler via vcpkg this environment variable should be set automatically. Check the CMSIS-Toolbox user guide..

I also noticed that the readme for the CoreValidation Suite does not mention that the Cortex_DFP package (https://github.com/ARM-software/Cortex_DFP) must be installed.

Yes, that's true. The build command as executed via build.py doesn't add --packs argument to cbuild. Hence, required packs are not installed automatically.

If I understand correctly, this package must first be extended for the new core types in order to be able to test them here. But first I want to be able to run the current version locally.

Yes, we need some sort of device family pack for the new devices/cores. Easiest is probably to enhance Cortex DFP. You can do this locally, by using the "local packs flow":

• Clone the Cortex DFP repo.
• Register the clone as a "local pack", e.g. cpackget add /path/to/ARM.Cortex_DFP.pdsc.
• Uninstall any released version of Cortex DFP or pin the pack version to 0.0.0. This can either be done in the CSolution .clayer.yml where - pack: ARM::[email protected] is requested. Or in the generated CMSIS/CoreValidation/Project/Validation.cbuild-pack.yml by modifying the - resolved-pack: ARM::[email protected] line.

[Masmiseim36]

Hello @JonatanAntoni and @GuentherMartin

Have you changed anything about the core checks? None of the Cortex-A projects build anymore, not even on the current unchanged head version. It seems that tests that are unsupported are counted as errors.

[JonatanAntoni]

Have you changed anything about the core checks? None of the Cortex-A projects build anymore, not even on the current unchanged head version. It seems that tests that are unsupported are counted as errors.

Not that I am aware of. PR workflow shall prevent that. I just check main branch on my machine for all Cortex-A devices, all compilers and optimization modes without issues.

Please double check your environment. Mine was:

arm:compilers/arm/armclang 6.21.0  installed            Arm Compiler for Embedded
arm:compilers/arm/arm-none-eabi-gcc 13.2.1  installed            GCC compiler for ARM CPUs
arm:compilers/arm/llvm-embedded 17.0.1  installed            LLVM Embedded Toolchain for Arm CPUs

And after update:

arm:compilers/arm/armclang 6.22.0  installed            Arm Compiler for Embedded
arm:compilers/arm/arm-none-eabi-gcc 13.2.1  installed            GCC compiler for ARM CPUs
arm:compilers/arm/llvm-embedded 17.0.1  installed            LLVM Embedded Toolchain for Arm CPUs

[Masmiseim36]

Hello @JonatanAntoni

the whole thing is a bit strange.

I have the same behavior locally as in this pull request, whether on this commit, the current head or on older versions: With the AC6 compiler all Cortex-A tests fail.

What makes the whole thing even stranger is that the errors only occur when I start all tests via ' build.py lit'. However, if I specify the compiler and target architecture, it works (build.py -c AC6 -d CA53 lit).

I had a similar problem before. Due to the lack of a license for AC6, every test that was not for Cortex-M0 failed. Since I have been using the MDK6 Community license, however, everything has been OK. Could this be a license problem again?

[JonatanAntoni]

Hi @Masmiseim36,

It probably is an licensing issue. The workflow for your PR runs in "isolation", i.e., it doesn't have access to the professional Arm license. Hence, all tests for Cortex-A and -R are supposed to fail.

Let me check your PR on my local machine. Then, I can recreate the PR with my maintainer privileges which gives it access to the license.

[Masmiseim36]

The PR https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/pull/312 should solve the issues during pack generation

[JonatanAntoni]

The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation

We need to update the pack schema reference URL in the pdsc file once this PR is merged.

[JonatanAntoni]

The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation

We need to update the pack schema reference URL in the pdsc file once this PR is merged.

The updated schema is now available at

https://raw.githubusercontent.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/v1.7.37/schema/PACK.xsd

[Masmiseim36]

The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation

We need to update the pack schema reference URL in the pdsc file once this PR is merged.

Any plans for 0.11.2 release?

[JonatanAntoni]

The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation

We need to update the pack schema reference URL in the pdsc file once this PR is merged.

Any plans for 0.11.2 release?

What 0.11.2 release? The above PR to the pack schema has been merged and published via the schema version 1.3.37 tag.

Please update the schema reference in pdsc file at https://github.com/ARM-software/CMSIS_6/pull/45/files#diff-2f515e4f53b33d558f9d7ef1cea041f96465055739878ea684a6f19dae2f84efR3

[Masmiseim36]

The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation

We need to update the pack schema reference URL in the pdsc file once this PR is merged.

Any plans for 0.11.2 release?

What 0.11.2 release? The above PR to the pack schema has been merged and published via the schema version 1.3.37 tag.

Please update the schema reference in pdsc file at https://github.com/ARM-software/CMSIS_6/pull/45/files#diff-2f515e4f53b33d558f9d7ef1cea041f96465055739878ea684a6f19dae2f84efR3

I have mixed the gen-pack version with the pack-spec version. Sorry for that