You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit includes the following changes
* Currently, the expectation is that applications
would explicitly call xPortStartScheduler() on all
secondary cores. However, this approach places an
unnecessary burden on the application developer and
assumes strict adherence to our example code,
which we cannot guarantee.
To make the port more inclusive and align with the principle
that the kernel should take care of system responsibilities,
we are shifting this logic into the port itself.
With this change, the application developer only needs to call
vTaskStartScheduler() on the primary core, does an SVC call once
the secondary cores are online, and the kernel will ensure
that all secondary cores are properly managed.
* Support tasks running in EL0 and only kernel running in EL1,
the changes are just having multiple SVCs for different purposes
(whenever a privileged instruction (e.g., MSR) is to be executed).
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Copy file name to clipboardExpand all lines: portable/GCC/ARM_CR82/README.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,3 +17,26 @@ The port is supported and tested on the following toolchains:
17
17
- This port assumes the hardware or model is fully cache coherent.
18
18
- The port does not perform cache maintenance for shared buffers.
19
19
- If your hardware or model doesn't support full cache coherency, you must handle cache clean/invalidate operations, memory attributes, and any additional barriers in your BSP/application (especially around shared-memory regions).
20
+
21
+
# SMP Multicore Bring-up
22
+
23
+
For SMP systems using this port, the application only needs to start the scheduler on the primary core and issue an SVC from each secondary core once they are online. The kernel coordinates the rest and ensures all cores are properly managed.
24
+
25
+
- Developer-facing summary: call `vTaskStartScheduler()` on the primary core; each secondary core, in its **reset handler**, performs its local init and then issues an SVC (immediate value `106`) to hand off to the kernel. The port will bring all cores under the scheduler.
26
+
27
+
Primary core flow:
28
+
29
+
1. Perform core-specific and shared initialization (e.g., set EL1 stack pointer, zero-initialize `.bss`).
30
+
2. Jump to `main()`, create user tasks, optionally pin tasks to specific cores.
31
+
3. Call `vTaskStartScheduler()` which invokes `xPortStartScheduler()`.
32
+
4.`xPortStartScheduler()` configures the primary core tick timer and signals secondary cores that shared init is complete using the `ucPrimaryCoreInitDoneFlag` variable.
33
+
5. Wait until all secondary cores report as brought up.
34
+
6. Once all cores are up, call `vPortRestoreContext()` to schedule the first task on the primary core.
35
+
36
+
Secondary core flow (to be done in each core’s reset handler):
37
+
38
+
1. Perform core-specific initialization (e.g., set EL1 stack pointer).
39
+
2. Wait for the primary core's signal that shared initialization is complete (i.e., `ucPrimaryCoreInitDoneFlag` set to 1).
40
+
3. Update `VBAR_EL1` from the boot vector table to the FreeRTOS vector table.
41
+
4. Initialize the GIC redistributor and enable SGIs so interrupts from the primary core are receivable; signal the primary that this secondary is online and ready by setting the its flag in the `ucSecondaryCoresReadyFlags` array.
42
+
5. Issue an SVC with immediate value `106` to enter `FreeRTOS_SWI_Handler`, which will call `vPortRestoreContext()` based on the SVC number to start scheduling on this core.
0 commit comments