main
smp
V11.1.0
V11.0.1
V11.0.0
V10.6.2
V10.6.1
V10.6.0
V10.5.1
V10.5.0
V10.4.3-LTS-Patch-3
V10.4.6
V10.4.3-LTS-Patch-2
V202110.00-SMP
V10.4.5
V10.4.3-LTS-Patch-1
V10.4.4
V10.4.0-kernel-only
V10.3.0-kernel-only
V10.3.0
PartialReleases
V10.2.1
V10.2.0
V10.1.1
V10.1.0
V10.0.1
V10.0.0
V8.0.1
V9.0.0
V9.0.0rc2
V9.0.0rc1
V8.2.3
V8.2.2
V8.2.1
V8.2.0
V8.2.0rc1
V8.1.2
V8.1.1
V8.1.0
V8.0.0
V8.0.0rc1
V7.6.0
V7.5.3
V7.5.2
V7.5.1
V7.5.0
V7.4.2
V7.4.1
V7.4.0
V7.3.0
V7.2.0
V7.1.1
BackupPoints
V7.1.0
V7.0.2
V7.0.1
V7.0.0
V6.1.1
V6.1.0
V6.0.5
V6.0.4
V6.0.3
V6.0.1
V6.0.0
V5.4.2
V5.4.1
V5.3.1
V5.3.0
V5.2.0
V5.1.2
V5.0.3
V5.0.2
V5.0.0
V4.8.0
V4.7.2
V4.7.1
V4.7.0
V4.6.1
V4.5.0
V4.4.0
V4.3.1
V4.3.0
V4.2.1
V4.2.0
V4.1.3
V4.1.2
V4.1.1
V4.1.0
V4.0.5
V4.0.3
V4.0.2
V4.0.1
V10.3.1-kernel-only
V10.4.1-kernel-only
V10.4.2
V10.4.3
V8.0.0-rc1
V8.2.0-rc1
V9.0.0-rc1
V9.0.0-rc2
${ noResults }
3 Commits (eac2b9a271be1526efddcde3f22533c3205ded2a)
Author | SHA1 | Message | Date |
---|---|---|---|
|
334de5d8ab
|
Enable ARMv7-M MPU ports to place FreeRTOS kernel code outside of flash (#46)
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> |
5 years ago |
|
88e32327e9
|
version bump to v10.3.1 (#16)
* Verion bump from 10.3.0 to 10.3.1. * version bump in task.h * change history for 10.3.1. |
5 years ago |
|
210b1ffcc8 | Re-sync with upstream and stripping away none kernel related. | 5 years ago |