This commit adds support for queue direct transfer buffer being owned by
the task's TCB. This inherently solves some design issues with the
buffer being owned by the queue's object. On the flip side, this adds
memory cost to the task's TCB.
According to the RISC-V Privileged Architecture Specification (20211203),
writing Initial or Clean to the FS field of mstatus may result in the FS
value getting set to Dirty in some implementations. This means we cannot
rely on reading back the same FS value after writing to mstatus.
Previously, the context restore code would:
1. Write an FS value to mstatus
2. Read mstatus again at a later point
3. Use the read FS value to determine FPU status
This change updates the context restore code to use the mstatus value
from the saved context instead of re-reading mstatus after writing to
it. This required chaning the location of the mstatus slot in the
context.
Fixes: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/1327
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
This commit adds support for direct transfer for queue operations. A ew
config option configQUEUE_DIRECT_TRANSFER is introduced to enable this
option. With this feature, we enable directly copying data to a waiting
task's buffer and avoid copying data to the queue buffer. This helps in
avoiding priority inversions where a lower priority task can steal
a data from a higher priority task blocked on the queue. This also
reduces a copy operation and helps with the queue performance.
Stream buffer task lists (xTaskWaitingToSend and xTaskWaitingToReceive)
are updated without critical sections. These objects are shared objects
and can be updated from an ISR context as well. Hence, these lists must
always be updated in critical sections.
prvLockQueue() and prvUnlockQueue() helper functions now only take the
ISR locks because they are always called with the task lock already
taken. However, these functions must also increment and decrement the
critical nesting count as both locks get taken eventually. This commit
fixes it.
This commit removes the need for suspending the scheduler when calling
some event_groups.c APIs as the non-deterministic operations are
happening with the event group being locked and the preemption being
disabled from the current task.
Updated timers.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL() with tmrENTER/EXIT_CRITICAL().
- Added vTimerEnterCritical() and vTimerExitCritical() to map to the
data group critical section macros.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated stream_buffer.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with sbENTER/EXIT_CRITICAL_FROM_ISR().
- Added vStreambuffersEnterCritical/FromISR() and
vStreambuffersExitCritical/FromISR() to map to the data group critical
section macros.
- Added prvLockStreamBufferForTasks() and prvUnlockStreamBufferForTasks() to suspend the stream
buffer when executing non-deterministic code.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated event_groups.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with event_groupsENTER/EXIT_CRITICAL/_FROM_ISR().
- Added vEventGroupsEnterCritical/FromISR() and
vEventGroupsExitCriti/FromISR() functions that map to the data group
critical section macros.
- Added prvLockEventGroupForTasks() and prvUnlockEventGroupForTasks() to suspend the event
group when executing non-deterministic code.
- xEventGroupSetBits() and vEventGroupDelete() accesses the kernel data group
directly. Thus, added vTaskSuspendAll()/xTaskResumeAll() to these fucntions.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated queue.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with queueENTER/EXIT_CRITICAL_FROM_ISR().
- Added vQueueEnterCritical/FromISR() and vQueueExitCritical/FromISR()
which map to the data group critical section macros.
- Added prvLockQueueForTasks() and prvUnlockQueueForTasks() as the granular locking equivalents
to prvLockQueue() and prvUnlockQueue() respectively
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated critical section macros with granular locks.
Some tasks.c API relied on their callers to enter critical sections. This
assumption no longer works under granular locking. Critical sections added to
the following functions:
- `vTaskInternalSetTimeOutState()`
- `xTaskIncrementTick()`
- `vTaskSwitchContext()`
- `xTaskRemoveFromEventList()`
- `vTaskInternalSetTimeOutState()`
- `eTaskConfirmSleepModeStatus()`
- `xTaskPriorityDisinherit()`
- `pvTaskIncrementMutexHeldCount()`
Added missing suspensions to the following functions:
- `vTaskPlaceOnEventList()`
- `vTaskPlaceOnUnorderedEventList()`
- `vTaskPlaceOnEventListRestricted()`
Fixed the locking in vTaskSwitchContext()
vTaskSwitchContext() must aquire both kernel locks, viz., task lock and
ISR lock. This is because, vTaskSwitchContext() can be called from
either task context or ISR context. Also, vTaskSwitchContext() must not
alter the interrupt state prematurely.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
- Updated prvCheckForRunStateChange() for granular locks
- Updated vTaskSuspendAll() and xTaskResumeAll()
- Now holds the xTaskSpinlock during kernel suspension
- Increments/decrements xPreemptionDisable. Only yields when 0, thus allowing
for nested suspensions across different data groups
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Changed xPreemptionDisable to be a count rather than a pdTRUE/pdFALSE. This
allows nested calls to vTaskPreemptionEnable(), where a yield only occurs when
xPreemptionDisable is 0.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
xTaskPriorityInherit() is called inside a critical section from queue.c. This
commit moves the critical section into xTaskPriorityInherit().
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
In the RL78 FAR data model, pxPortInitialiseStack() did not initialize
the register image for the task parameter (pvParameters) correctly.
A:DE registers were saved with dummy values instead of the actual pointer.
Effect: on first context restore the function prologue read a corrupted
parameter. NEAR builds were not affected.
This patch aligns the FAR path with the calling convention and compiler
version:
- IAR V2: pass pvParameters via registers → DE = low 16 bits, A = high 8
- IAR V1 (fallback): keep legacy stack write
Also keeps the original stack-frame layout and updates the comment to
reflect that pointer sizes depend on __DATA_MODEL__.
Result: tasks in FAR receive the correct parameter at entry; NEAR remains
unchanged.
Co-authored-by: Thomas Quiniou <tquiniou@fdi-access.com>
The goal of this commit is to add the GCC/ARMClang non-MPU
port variant for ARM Cortex-R82 processor which is
ARMv8-R AArch64 based.
The work done is inspired by the GCC ARM_AARCH64 FreeRTOS port.
This port has the following features:
* Uses single security state (non TrustZone).
* Supports SMP (Symmetric multi-processing).
* Doesn't support Hypervisor (EL2).
* Doesn't support neither PMSA (MPU) nor VMSA (MMU).
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
* cortex-M ports: Clarify hardware-saved exception frame size variable
- Rename ulStackFrameSize to ulHardwareSavedExceptionFrameSize to
reflect the hardware-saved exception frame (8 or 26 words based
on FPU/lazy stacking).
- Add comments explaining standard vs extended frames.
- Apply across Cortex-M ports.
- No functional change, improves readability.
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* kernel-checker-script: Modify Arm copyright header regex
Arm's copyright header regex is modified with the following:
* Accept both single year copyright headers (e.g., "2024")
and year range copyright headers (e.g., "2024-2025").
* Accept both single-line copyright header and also
multi-line header.
* Add the escape backslash to accept only literal dot
not any character.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
---------
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
If a user configures the configASSERT macro to expand to nothing,
a call to the Win32 API SetWaitableTimer() doesn't get compiled.
This can happen if, for example, configASSERT(x) set defined as
assert(x) (from assert.h) which expands to nothing when NDEBUG is
set (common for "release" builds).
This commit does the following:
* Remove xEventGroupClearBitsFromISR and
xEventGroupSetBitsFromISR functions direct mapping
to xTimerPendFunctionCallFromISR in case the trace
facility is feature not set. This should match the
current implementation in which the application calling
xEventGroupClearBitsFromISR
without defining the trace macros
(i.e. traceENTER_xEventGroupClearBitsFromISR is
a blank function in this case) will end up calling
xTimerPendFunctionCallFromISR function directly.
This enhances the readability of the code by not
guarding the xEventGroup<Set/Clear>BitsFromISR
functions' declaration and definition based on
the trace facility macro (i.e. configUSE_TRACE_FACILITY).
* Refactor the guarding macros for MPU_xEventGroupClearBitsFromISR
and MPU_xEventGroupSetBitsFromISR functions to match the
change above.
The current implementation leads to redefinition warnings
as `event_groups.h`redefines xEventGroupClearBitsFromISR
and xEventGroupSetBitsFromISR based on
`configUSE_TRACE_FACILITY' after they have been defined based
on configUSE_MPU_WRAPPERS_V1 in `mpu_wrappers.h`. The
implemented changes should resolve these warnings.
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Add GCC_ARM_CRX_MPU to the set of FREERTOS_PORT patterns that trigger
adding mpu_wrappers.c and mpu_wrappers_v2.c to freertos_kernel_port
target_sources.
* [MSVC-MingW] Move windows headers to port.c
This prevents the inclusion of windows.h. into all header files using
FreeRTOS.h and thus defining several macros conflicting with common
definitions.
* [MSVC-MingW] Include correct header for compiler intrinsics
---------
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
GNU as makes unrecognized sections loadable and writable by default, but
LLVM's assembler requires specifying flags explicitly. Without them, the
linker generates "has non-ABS relocation" errors when trying to link the
resulting object files.
Previously, the shared thread key was deleted in xPortStartScheduler
after scheduler was ended. This created a race condition where
prvThreadKeyDestructor (responsible for freeing thread-specific heap
memory) would not be called if xPortStartScheduler deleted the key
before the last task deletion, as destructors are not invoked after key
deletion (see https://github.com/walac/glibc/blob/master/nptl/pthread_create.c#L145-L150).
Move thread key deletion to process exit to ensure all thread-specific
memory is properly freed.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
