Chris Morgan [Wed, 29 Nov 2023 13:15:50 +0000 (08:15 -0500)]
POSIX port - Switch from allowing the user to specify the stack memory itself, to allowing them to specify the stack size
Change from pthread_attr_setstack() to pthread_attr_setstacksize(), and automatically adjust the stack size
to be at least PTHREAD_STACK_MIN if it wasn't already, removing the size warning.
This permits the user to increase the pthread stack size beyond the PTHREAD_STACK_MIN default of 16384 if
desired, without producing a warning in the typical case where stacks are minimized for RAM limited targets.
Continue to store thread paramters on the provided stack, for consistency with the MCU targets.
Previously pthread_attr_setstack() was used to enable user defined stacks.
Note that:
1. The stack size can still be specified by the user.
2. pxPortInitialiseStack(), and pthread_addr_setstack() was failing on stacks of typical size, as
these are smaller than PTHREAD_STACK_MIN (16384) bytes, and printing out a series of warnings.
Improve usability by having the posix port automatically increase the stack size to be
at least PTHREAD_STACK_MIN as posix platforms have enough memory for this not to be a concern.
3. Reuse of stack memory will also result in valgrind 'invalid write' errors to what is demonstrably
valid memory. Root cause is that Valgrind is tracking a stack pointer as the stack is used.
Reuse of a stack buffer results in the stack being used at its start, in an area that Valgrind thinks
is far away from the start of the stack. There are ways to notify Valgrind of these changes
however this would require linking against and calling Valgrind functions from the FreeRTOS application using
the posix port, https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq.
Also, apparently it isn't permitted by posix to reuse stack memory once its been used in a pthread via pthread_attr_setstack(),
see https://stackoverflow.com/a/5422134
Chris Morgan [Tue, 28 Nov 2023 13:57:37 +0000 (08:57 -0500)]
POSIX port - Cancel and join all FreeRTOS managed pthreads upon shutdown
For a clean shutdown where memory is freed, it is necessary for all pthreads to be joined
at shutdown.
Previously there was explicit cancellation of the idle task and timer daemon task, however
there may be a number of other tasks in the system, both system created and user created,
and those tasks/threads were being left at shutdown.
This change calls pthread_cancel()/pthread_join() on all FreeRTOS managed pthreads upon
shutdown.
Chris Morgan [Tue, 28 Nov 2023 12:40:11 +0000 (07:40 -0500)]
POSIX - Switch from posix timers to a timer thread to fix signal handling with non-FreeRTOS pthreads
Improve upon the elegant approach of using signals to cause task/pthreads
suspension and scheduler execution by using directed signals.
This fixes:
- Deadlocks in non-FreeRTOS pthreads
- Multiple FreeRTOS tasks(pthreads) incorrectly running at the same time
By directing the signals using pthread_kill() the signal handler in the presently running
FreeRTOS task/pthread will be called, ensuring that the scheduler runs both in the context
of a FreeRTOS task/pthread and from the presently executing FreeRTOS task/pthread.
Details
==============
The POSIX port uses signals to preempt FreeRTOS tasks (implemented as pthreads), a very neat and elegant
approach to forcing tasks/pthreads to suspend and run the scheduler.
Signal handlers are process global.
Posix timers generate signals when the timer expires, and the signal is sent to the currently
running pthread.
In systems where there are pthreads that are NOT a result of creating FreeRTOS tasks, such as the
entry point thread that calls main(), or user created pthreads, this poses a serious issue.
While the POSIX port only allows a single FreeRTOS pthread to run at once, by causing all suspended
threads to not be scheduled due to their waiting on a pthread condition variable,
this isn't the case with non-FreeRTOS pthreads.
Thus it is possible that a non-FreeRTOS pthread is running when the timer expires and the signal
is generated. This results in the signal handler running in the non-FreeRTOS thread.
The sequence of events results in these events from signal handler context:
- vPortSystemTickHandler() being called
- The scheduler running
- Selecting another FreeRTOS task to run and switching the active task
- The newly selected task released from suspension by pthread_cond_signal()
- The presently active thread calling event_wait()
- The pthread calling pthread_cond_wait(), suspending the thread and allowing the host OS scheduler
to schedule another thread to run.
If this occurs from a non-FreeRTOS thread this results in:
- The active FreeRTOS pthread (Task A/Thread A) continuing to run (as the signal handler that calls
event_wait() ran instead in a non-FreeRTOS pthread.
- The pthread where the signal handler did run (Thread B) will call event_wait() and pthread_cond_wait(),
but on the condition variable of the previously active FreeRTOS task, oops. This causes the
non-FreeRTOS pthread to block unexpectedly relative to what the developer might have expected.
- The newly selected FreeRTOS Task (Task C/Thread C) will resume and start running.
At this point Task A/Thread A is running concurrently with Task C/Thread C. While this may not
necessarily be an issue, it does not replicate the expected behavior of a single Task running at
once.
Note that Thread B will resume if/when Task A/ThreadA is switched to. However, this could be delayed
by an arbitrary amount of time, or could never occur.
Also note that if there are multiple non-FreeRTOS pthreads that Thread D, E, F...etc could suffer the
same fate as Thread B, if the scheduler were to suspend Task C/Thread C and resume Task E/Thread E.
Implementation
==============
Timer details
-------------
A standalone pthread for the signal generation thread was chosen, rather than using
a posix timer_settime() handler function because the latter creates a temporary
pthread for each handler callback. This makes debugging much more difficult due to
gdb detecting the creation and destruction of these temporary threads.
Signal delivery
--------------
While signal handlers are per-thread, it is possible for pthreads to selectively block
signals, rather than using thread directed signals. However, the approach of blocking
signals in non-FreeRTOS pthreads adds complexity to each of these non-FreeRTOS pthreads
including ensuring that these signals are blocked at thread creation, prior to the thread
starting up. Directed signals removes the requirement for non-FreeRTOS pthreads to be aware
of and take action to protect against these signals, reducing complexity.
chinglee-iot [Wed, 3 Jan 2024 07:47:05 +0000 (15:47 +0800)]
Fix portSET_INTERRUPT_MASK_FROM_ISR definition for atomic operation (#940)
* Introduce portHAS_NESTED_INTERRUPTS to identify if port has nested interrupt or not.
* Update atomic.h to use portHAS_NESTED_INTERRUPTS instead of portSET_INTERRUPT_MASK_FROM_ISR definition.
Soren Ptak [Tue, 26 Dec 2023 10:36:50 +0000 (05:36 -0500)]
Export MPU Section Attributes (#931)
Export the PRIVILEGED_FUNCTION, PRIVILEGED_DATA, and FREERTOS_SYSTEM_CALL
attributes to make it easier for end users to add their own privileged functions and
system calls.
dps.lwk [Tue, 26 Dec 2023 09:02:47 +0000 (09:02 +0000)]
RP2040: FreeRTOS-Kernel-Static use configKERNEL_PROVIDED_STATIC_MEMORY (#934)
Remove the idle_task_static_memory.c and use the new default implementations
to allows for FreeRTOS-Kernel-Static to be used with configNUMBER_OF_CORES > 1
Forty-Bot [Fri, 22 Dec 2023 21:09:55 +0000 (16:09 -0500)]
Fix build with modern GCC (#933)
* GCC: MSP430F449: Add missing attributes
Apparently at some point in the past, GCC (or TI's GCC) used to define
these attributes. Define them ourselves so that we can compile the demo
application.
* GCC: MSP430F449: Make interrupts return void
If a return type of a function is not specified, it defaults to int. Set
the return type of interrupts to void to avoid warnings.
* GCC: MSP430F449: Define portPOINTER_SIZE_TYPE
portPOINTER_SIZE_TYPE defaults to uint32_t if undefined. Define it to
uint16_t, which is correct for this port.
Darian [Mon, 11 Dec 2023 07:12:53 +0000 (15:12 +0800)]
Add portTASK_SWITCH_HOOK (#867)
This commit adds a portTASK_SWITCH_HOOK() macro which allows ports to inject
behavior immediately after a context switch. For example, this macro could be
used by ports that need to set an end of stack watchpoint after a context
swtich.
Co-authored-by: Rahul Kar <118818625+kar-rahul-aws@users.noreply.github.com> Co-authored-by: Soren Ptak <ptaksoren@gmail.com> Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com> Co-authored-by: Tony Josi <tonyjosi@amazon.com> Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Jeff Tenney [Mon, 11 Dec 2023 04:57:47 +0000 (21:57 -0700)]
Detect more startup config errors on Cortex M (#832)
Verify that the application has correctly installed PendSV
and SVCall handlers. The application can choose to
disable these checks by setting configCHECK_HANDLER_INSTALLATION
to 0 in their FreeRTOSConfig.h.
Darian [Tue, 5 Dec 2023 06:31:11 +0000 (14:31 +0800)]
Update xTaskGetIdleTaskHandle() For SMP (#868)
* Update xTaskGetIdleTaskHandle() in SMP
This commit updates xTaskGetIdleTaskHandle() for SMP in the following ways:
- xTaskGetIdleTaskHandle() no longer accepts xCoreID argument in SMP so that
there is not change in API between single-core and SMP
- xTaskGetIdleTaskHandle() now returns the Active idle task handle in SMP,
which matches the behavior in single-core.
- Added xTaskGetIdleTaskHandleForCore() in SMP which accepts an xCoreID
argument. This function can be used to obtain the Passive idle task handles.
* Update xTaskGetIdleTaskHandle
---------
Co-authored-by: Ching-Hsin Lee <chinglee@amazon.com> Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com> Co-authored-by: Rahul Kar <118818625+kar-rahul-aws@users.noreply.github.com> Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Rahul Kar [Tue, 28 Nov 2023 13:46:15 +0000 (19:16 +0530)]
Coverity Report Directory Fix (#909)
* Revert "The curl command to send the report expects the tar file to be in its current directory. The step either needed to have the working-directory: set to the build directory, or the tar file needs to be created in the parent directory. (#903)"
Soren Ptak [Tue, 28 Nov 2023 05:08:57 +0000 (00:08 -0500)]
The curl command to send the report expects the tar file to be in its current directory. The step either needed to have the working-directory: set to the build directory, or the tar file needs to be created in the parent directory. (#903)
Soren Ptak [Thu, 23 Nov 2023 16:47:31 +0000 (08:47 -0800)]
Coverity Scan Workflow Fix (#891)
Currently the Coverity Scan attempts to run on every fork that pulls
the file. This leads to anybody who pulls this file getting emails that
their workflow failed to run when the cron job attempts to run. This
PR sets the scan to only run if the repo is FreeRTOS/FreeRTOS-Kernel.
Also, change the scan from a cron job to a job that runs on a commit
to mainline, or if triggered manually.
Gaurav-Aggarwal-AWS [Thu, 23 Nov 2023 05:17:47 +0000 (10:47 +0530)]
Update system call entry mechanism (#898)
Earlier the System Call entry from an unprivileged task
looked like:
1. SVC for entering system call.
2. System call implementation.
3. SVC for exiting system call.
Now, the system call entry needs to make only one SVC
call and everything else is handled internally.
This PR also makes the following changes:
1. Update the Access Control List (ACL) mechanism to
grant access to all the kernel objects before the
scheduler is started.
2. Add one struct param for system calls with 5 parameters.
This removes the need for special handling for system
calls with 5 parameters.
3. Remove raise privilege SVC when MPU wrapper v2 is used.
4. Add additional run time parameter checks to MPU wrappers
for xTaskGenericNotify and xQueueTakeMutexRecursive APIs.
chinglee-iot [Thu, 16 Nov 2023 01:04:05 +0000 (09:04 +0800)]
Add vApplicationGetPassiveIdleTaskMemory for SMP (#890)
* Update vApplicationGetIdleTaskMemory prototype for SMP. Now SMP and
single core use the same prototype for compatibility.
* Add vApplicationGetPassiveIdleTaskMemory for SMP to get passive idle
task memory.
Moral-Hao [Mon, 6 Nov 2023 09:50:32 +0000 (17:50 +0800)]
Fix vTaskSwitchContext for smp. (#879)
The function vTaskSwitchContext in smp has an parameter of core id,
which means this function is not only used for the core who call it.
Thus we should use the task running on the specific core id,
instead of use the task running on the core who call this function.
Devaraj Ranganna [Tue, 31 Oct 2023 04:36:39 +0000 (04:36 +0000)]
aarch64: Rename ARM_CA53_64_BIT/_SRE to Arm_AARCH64/_SRE (#822)
The Cortex-A53 ports are generic and can be used as a starting point
for other Armv8-A application processors. Therefore, rename
`ARM_CA53_64_BIT` to `Arm_AARCH64` and `ARM_CA53_64_BIT_SRE` to
`Arm_AARCH64_SRE`.
With this renaming, existing projects that use old port, should
migrate to renamed port as follows:
Joe Benczarski [Fri, 27 Oct 2023 18:57:52 +0000 (14:57 -0400)]
Support configurable RISC-V chip extension (#773)
* Support configurable RISC-V chip extension
Added the FREERTOS_RISCV_EXTENSION option to allow the user
to select which chip extension they want included. Removed the
port for pulpino to instead use the new option.
* Add port GCC_RISC_V_GENERIC and IAR_RISC_V_GENERIC
* Add two rics-v generic ports to support FREERTOS_RISCV_EXTENSION
config
---------
Co-authored-by: Joe Benczarski <jbenczarski@trijicon.com> Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com> Co-authored-by: Ching-Hsin Lee <chinglee@amazon.com> Co-authored-by: kar-rahul-aws <118818625+kar-rahul-aws@users.noreply.github.com> Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
Boris van der Meer [Mon, 23 Oct 2023 06:57:54 +0000 (08:57 +0200)]
Remove default behaviour of FREERTOS_HEAP. (#807)
To build a complete static application (configSUPPORT_DYNAMIC_ALLOCATION
set to 0) an ugly workaround is necessary, because when FREERTOS_HEAP is
not set, heap 4 is automatically selected in the current CMake.
Soren Ptak [Thu, 19 Oct 2023 17:08:24 +0000 (10:08 -0700)]
Kernel Checker CI Workflow File Updates (#804)
* Perform sparse checkout of just the .github folder for the header check instead of all the files. Update python checkout version being used. Update the version of the get changed files action being used.
This PR fixes the bug described in the following issue:
https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/612.
This was originally contributed in the following PR:
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/625.
The implementation suspends the scheduler before exiting the
critical section (i.e. before enabling interrupts). If we do not do
so, a notification sent from an ISR, which happens after exiting
the critical section and before suspending the scheduler, will
get lost. The sequence of events will be:
1. Exit critical section.
2. Interrupt - ISR calls xTaskNotifyFromISR which adds the task to
the Ready list.
3. Suspend scheduler.
4. prvAddCurrentTaskToDelayedList moves the task to the delayed
or suspended list.
5. Resume scheduler does not touch the task (because it is not on
the pendingReady list), effectively losing the notification from
the ISR.
The same does not happen when we suspend the scheduler before
exiting the critical section. The sequence of events in this case will
be:
1. Suspend scheduler.
2. Exit critical section.
3. Interrupt - ISR calls xTaskNotifyFromISR which adds the task to
the pendingReady list as the scheduler is suspended.
4. prvAddCurrentTaskToDelayedList adds the task to delayed or
suspended list. Note that this operation does not nullify the add
to pendingReady list done in the above step because a different
list item, namely xEventListItem, is used for adding the task to the
pendingReady list. In other words, the task still remains on the
pendingReady list.
5. Resume scheduler moves the task from pendingReady list to the Ready list.
begriffs.com / projects / freertos / log