New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
- Add initial support for ARMv8A, ARMV7R and ARMV8R #45
base: main
Are you sure you want to change the base?
- Add initial support for ARMv8A, ARMV7R and ARMV8R #45
Conversation
Masmiseim36
commented
Aug 12, 2023
- 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
Test Results 240 files - 132 240 suites - 132 0s ⏱️ - 8m 45s Results for commit a85823e. ± Comparison against base commit b0bbb04. This pull request removes 49 and adds 56 tests. Note that renamed tests count towards both.
This pull request removes 5 skipped tests and adds 2 skipped tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
8da3caa
to
396c99a
Compare
@Masmiseim36, could you please update this one with latest cleanups @GuentherMartin is working on, see PR #56. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are the CMSIS compiler include files missing in r-profile?
396c99a
to
924de88
Compare
They come with this pull Request #44. That PR should be merged first |
See PR #58 fixing the tests. |
924de88
to
4961d52
Compare
bc0287b
to
ce515d6
Compare
ce515d6
to
f66607e
Compare
1b0f516
to
d760a27
Compare
f66607e
to
dd2c27b
Compare
00ed1eb
to
7f7aae9
Compare
1d08f09
to
ed4a77e
Compare
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
Looks interesting
Thanks for the feedback. I'm trying to read up on the subject. Simulator-based tests are also new to me. |
True, sorry, I was mislead by the different approach we used for
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. |
Hello @JonatanAntoni , I have tried to get the CoreValidation Suite to work. Unfortunately I get an error message. Is another environment variable missing?
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. |
I am not sure, but it might be missing the
Yes, that's true. The build command as executed via
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":
|
ed4a77e
to
33afe88
Compare
Hello @JonatanAntoni and @GuentherMartin Have you changed anything about the core checks? |
Not that I am aware of. PR workflow shall prevent that. Please double check your environment. Mine was:
And after update:
|
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? |
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. |
8d2bcd8
to
4f98c7f
Compare
The PR Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#312 should solve the issues during pack generation |
4f98c7f
to
75f40ab
Compare
We need to update the pack schema reference URL in the pdsc file once this PR is merged. |
75f40ab
to
432826e
Compare
The updated schema is now available at https://raw.githubusercontent.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/v1.7.37/schema/PACK.xsd |
432826e
to
9a7d696
Compare
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 |
9a7d696
to
780e513
Compare
I have mixed the gen-pack version with the pack-spec version. Sorry for that |
- 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 - Extend core-test routines for new supported core-types
780e513
to
a85823e
Compare