* Style: Change FreeRTOS websites in comments
* Style: Change freertos to FreeRTOS in comments
* Style: Remove broken link
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
The TEX, Shareable (S), Cacheable (C) and Bufferable (B) bits define
the memory type, and where necessary the cacheable and shareable
properties of the memory region.
The default values for these bits, as configured in our MPU ports, are
sometimes not suitable for application. One such example is when the MCU
has a cache, the application writer may not want to mark the memory as
shareable to avoid disabling the cache. This change allows the
application writer to override default vales for TEX, S C and B bits for
Flash and RAM in their FreeRTOSConfig.h. The following two new
configurations are introduced:
- configTEX_S_C_B_FLASH
- configTEX_S_C_B_SRAM
If undefined, the default values for the above configurations are
TEX=000, S=1, C=1, B=1. This ensures backward compatibility.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
ARMv7-M supports 8 or 16 MPU regions. FreeRTOS Cortex-M4 MPU ports so
far assumed 8 regions. This change adds support for 16 MPU regions. The
hardware with 16 MPU regions must define configTOTAL_MPU_REGIONS to 16
in their FreeRTOSConfig.h.
If left undefined, it defaults to 8 for backward compatibility.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The reason for the change is that the register is called System Handler
Priority Register 3 (SHPR3).
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
When Link Time Optimization (LTO) is enabled, some of the LDR
instructions result in out of range access. The reason is that the
default generated literal pool is too far and not within the permissible
range of 4K.
This commit adds LTORG assembly instructions at required places to
ensure that access to literals remain in the permissible range of 4K.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Problem Description
-------------------
The current flash organization in ARMv7-M MPU ports looks as follows:
__FLASH_segment_start__ ------->+-----------+<----- __FLASH_segment_start__
| Vector |
| Table |
| + |
| Kernel |
| Code |
+-----------+<----- __privileged_functions_end__
| |
| |
| |
| Other |
| Code |
| |
| |
| |
__FLASH_segment_end__ ------>+-----------+
The FreeRTOS kernel sets up the following MPU regions:
* Unprivileged Code - __FLASH_segment_start__ to __FLASH_segment_end__.
* Privileged Code - __FLASH_segment_start__ to __privileged_functions_end__.
The above setup assumes that the FreeRTOS kernel code
(i.e. privileged_functions) is placed at the beginning of the flash and,
therefore, uses __FLASH_segment_start__ as the starting location of the
privileged code. This prevents a user from placing the FreeRTOS kernel
code outside of flash (say to an external RAM) and still have vector
table at the beginning of flash (which is many times a hardware
requirement).
Solution
--------
This commit addresses the above limitation by using a new variable
__privileged_functions_start__ as the starting location of the
privileged code. This enables users to place the FreeRTOS kernel code
wherever they choose.
The FreeRTOS kernel now sets up the following MPU regions:
* Unprivileged Code - __FLASH_segment_start__ to __FLASH_segment_end__.
* Privileged Code - __privileged_functions_start__ to __privileged_functions_end__.
As a result, a user can now place the kernel code to an external RAM. A
possible organization is:
Flash External RAM
+------------+ +-----------+<------ __privileged_functions_start__
| Vector | | |
| Table | | |
| | | |
__FLASH_segment_start__ ----->+------------+ | Kernel |
| | | Code |
| | | |
| | | |
| | | |
| Other | | |
| Code | +-----------+<------ __privileged_functions_end__
| |
| |
| |
__FLASH_segment_end__ ----->+------------+
Note that the above configuration places the vector table in an unmapped
region. This is okay because we enable the background region, and so the
vector table will still be accessible to the privileged code and not
accessible to the unprivileged code (vector table is only needed by the
privileged code).
Backward Compatibility
----------------------
The FreeRTOS kernel code now uses a new variable, namely
__privileged_functions_start__, which needs to be exported from linker
script to indicate the starting location of the privileged code. All of
our existing demos already export this variable and therefore, they will
continue to work.
If a user has created a project which does not export this variable,
they will get a linker error for unresolved symbol
__privileged_functions_start__. They need to export a variable
__privileged_functions_start__ with the value equal to
__FLASH_segment_start__.
Issue
-----
https://sourceforge.net/p/freertos/feature-requests/56/
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
alfred gedeon
Gaurav-Aggarwal-AWS
Alfred Gedeon
Yuhui.Zheng