lib/cmsis: Upgrade to CMSIS 5.5.0. #4610
Conversation
Yes I think that's a good idea, considering that:
Also, would be important to check and understand what changed in CM4 and CM7 headers (and maybe CM1, CM3), eg by checking how an stm32 board's firmware changes (if it does). |
Upgrading CMSIS to version 5.5.0. Deleting hard commited copy of CMSIS and replacing it by submodule targeted lib/cmsis. Pointing submoudle to the release 5.5.0 tag. Source: https://github.com/ARM-software/CMSIS_5/releases/tag/5.5.0
af74c54 to
fa086bb
Compare
|
@dpgeorge, I have updated the PR to delete the hard coded copy of CMSIS Core and introduced a submodule that points to https://github.com/ARM-software/CMSIS_5, 5.5.0 tag. I found that CMSIS was updated yesterday, and its probably better to use as close as possible to head when updating. Also updated what i found of references to CMSIS includes in Makefiles in the repository.
Yeah, i guess we need to do some kind of sanitycheck of firmware. I did not really plan myself to do any deep analysis of ASM, other than validating that its not having size impacts and that the targets run as expected. But if you would, we can probably take a deep down look at the details before/if we merge this. My initial plan is to test the pca1000x + microbit target boards in nrf-port with and without BLE enabled. And verify that there are not size impacts on cortex-m0/m4 targets. I'm not having stm targets available though, so i would need some help testing those. |
Ok, thanks. It's definitely nice to point to ARM's repository for these files, but... that repo is about 300Mbyte in size, which is much larger than the MicroPython repo. The existing lib/cmsis dir is under 1Mbyte, so for ports that need CMSIS suddenly the required download and disk usage more than doubles. If this size increase is deemed a problem, an option is to create our own copy of the CMSIS repo keeping only the files we need (files in CMSIS/Core, which total less than 2MByte). It's not much effort to do this so maybe worth it to save the bandwidth. Any opinions?
I can test stm32 targets, no problem. |
I count more around 140MB, but that does not change the fact that it is huge. And your point of only using a fraction of this is valid. Maybe the first Commit wasn't to bad after all (af74c54). Could this still be a liable option, even if the license has changed? |
The git metadata (found in .git/modules/lib/cmsis) is around 200MB and the actual code (in lib/cmsis) is 140MB so in total it's more than 300MB. I guess the git metadata is large because the history is long, the files are big, and there were lots of big changes in that repo. In contrast, the stm32lib submodule has git metadata of 15MB and actual code size of 108MB. And the git metadata of the main uPy repo itself is around 35MB.
Yes, let's just go back to that, it's the simplest thing to do and has the least impact in the change of size. If users need the old version (for whatever reason) it's pretty easy to just have a separate directory (eg lib/cmsis_custom) and point to that instead of the standard one.
I have tested PYBV10 with this new CMSIS. The generated firmware is 4 bytes smaller and inspecting the disassembly there is a lot that's changed. But it seems superficial change, that chunks of code are reordered within a given function (eg a Running tests with the new CMSIS, they all pass. Performance is the same. And all other boards for the stm32 port build without error. Also teensy and cc3200 build fine. So I'd be happy to update it. But let's wait until after the next release, which should be very soon. |
|
I created a new PR to update the files in-place to v5.5.1, see #4820 |
|
CMSIS was updated to 5.5.1 in 0a6c479 |
Motivation for the PR is to facilitate for newer cortex-m architectures being candidates for micropython.
Also license seems to change from previous 4.3.0 to 5.4.0, from BSD 3 Clause to Apache 2.0.
@dpgeorge, could it be an option to move CMSIS to a git-submodule instead of having the files committed?