Add option to customize FLASH range #104
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Certain microcontrollers (e.g. RP2040) utilize BootROM which contains useful utility functions to accelerate certain common but expensive tasks such as division, etc. In such case the linker file doesn't capture this inside the FLASH region so memory protection will exclude BootROM from read and execute. If such thing happens then developer can use new options to override definition of FLASH region and specify region that will include both FLASH and BootROM. As of now there is only one region available for this purpose, so BootROM and FLASH have to create area that is not interrupted by any other region which shall have different access flags, such as peripherals or RAM.
Fix the code so that custom ranges are used only if CMRX_CUSTOM_FLASH_RANGE macro is set.
Unused region was previously saved in the MPU state with other regions. It was a preparation for the future use by the thread. Remove it to conserve memory and prepare for different use. Unused and stack regions swapped index so now unused region is #6.
Enums are given cleaner names and enum counter is introduced, so arrays which are indexed by this enum can be statically checked to match the size with enum count. Statically check that ARM port array that provides flag translation to ARM MPU has correct count of entries.
Not all chips are made equal and some need special code to handle their uniqueness. This is a beginning of effort to allow chip-specific code in platform support code and chip-specific CMake modules. Primary purpose of this code is to allow platform specific code for system, core and thread initialization in a similar way how architecture can do custom initialization at these points. Secondary purpose might be to help processing HAL integration. While HAL integration is not tremendously hard, it is a repetitive work and could be modularized and automated.
This is a stub of platform support code for RP2xxx chips. Its purpose is to create additional MPU region with read-only + execute privileges which provides access to jump tables used by C runtime and some runtime functions which are put into RAM rather than FLASH by the linker script to speed-up certain operations. This platform code is not fully done yet, it depends on the fact that linker script contains two additional symbols __rp2xxx_platform_custom_start and __rp2xxx_platform_custom_end. These symbols wrap deployments of .text*, .rodata* and .data* inside data section. Symbols must be aligned to base at least of the length of region in between them. Linker script manipulator which would do this is not written yet.
Added support for platforms creates the need of having a generic platform. In case of ARM, the generic platform does nothing. So this platform just configures path to a header which defines all platform-specific calls as empty macros.
Convert some newer non-bool option from option() to set(... CACHE).
Give developer a notion on which platform has been chosen.
Cache entries tend to overwrite user settings. Avoid setting cache entry if user already configured platform. This makes sure that platform is picked-up on first CMake run.
RP2xxx needs custom memory map. Do this change automatically so user doesn't have to deal with it. For now the only user action needed is to set CMRX_PLATFORM to rp2xxx and to provide linker script patch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Certain microcontrollers (e.g. RP2040) utilize BootROM which contains useful utility functions to accelerate certain common but expensive tasks such as division, etc.
In such case the linker file doesn't capture this inside the FLASH region so memory protection will exclude BootROM from read and execute.
If such thing happens then developer can use new options to override definition of FLASH region and specify region that will include both FLASH and BootROM.
As of now there is only one region available for this purpose, so BootROM and FLASH have to create area that is not interrupted by any other region which shall have different access flags, such as peripherals or RAM.