* fix: CLEAR MIE BIT IN INITIAL RISC-V MSTATUS VALUE
The MIE bit in the RISC-V MSTATUS register is used to globally enable
or disable interrupts. It is copied into the MPIE bit and cleared
on entry to an interrupt, and then copied back from the MPIE bit on
exit from an interrupt.
When a task is created it is given an initial MSTATUS value that is
derived from the current MSTATUS value with the MPIE bit force to 1,
but the MIE bit is not forced into any state. This change forces
the MIE bit to 0 (interrupts disabled).
Why:
If a task is created before the scheduler is started the MIE bit
will happen to be 0 (interrupts disabled), which is fine. If a
task is created after the scheduler has been started the MIE bit
is set (interrupts enabled), causing interrupts to unintentionally
become enabled inside the interrupt in which the task is first
moved to the running state - effectively breaking a critical
section which in turn could cause a crash if enabling interrupts
causes interrupts to nest. It is only an issue when starting a
newly created task that was created after the scheduler was started.
Related Issues:
https://forums.freertos.org/t/risc-v-port-pxportinitialisestack-issue-about-mstatus-value-onto-the-stack/9622
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
Enabling Link Time Optimization (LTO) causes some of the functions used
in assembly to be incorrectly stripped off, resulting in linker error.
To avoid this, these functions are marked with portDONT_DISCARD macro,
definition of which is port specific. This commit adds the definition
of portDONT_DISCARD for ARMv7-M ports.
Signed-off-by: Gaurav Aggarwal
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>
