Add SMP support - #205
Conversation
8cdf4be to
421f9a3
Compare
Also means we can collapse the mps3-an536-smp example back into mps3-an536, because we don't need special start-up routines any more (the presence of a custom `_default_start` before meant we weren't testing the supplied `_default_start` routine, so we had to split the example up).
You cannot check the stack contents of Core 1 on Core 0 when the MPU is enabled. So, now I set a flag and make sure not to do that for that particular test.
I copied from this example and got confused when it didn't work. Now it's fixed.
421f9a3 to
2896d2d
Compare
9names
left a comment
9names
left a comment
There was a problem hiding this comment.
I did a quick pass through. I'm not familiar with this part of the ARM spec so the review is mostly that comments make sense.
You mention in the code that the cores definitely have to wait on a hardware register because ram contents will be garbage.
Isn't the register value also not guaranteed at startup?
Also, I could imagine a scheme where either there's a shared address (that every core writes initially so it's not "random"), then spin for some amount of time that we can assume all cores will have done init, and then have the secondary cores poll for primary to set them.
Or, each core having it's own address and having cpu0 wake them all individually?
Peripheral registers generally go to known values on reset (think GPIO direction registers, or GPIO output data registers - pins are not randomised on boot-up). The thing about this design - using a secondary core park function - is that the library user is entirely in charge of which mechanism to use. You could write a secondary core park function where each core writes a zero to the same memory location, waits 10 seconds, and then starts polling for a non-zero value. You could write a secondary core park function where each core waits on a different memory address. All very possible. For the MPS3-AN536, waiting on the FPGA's LED register works, because it resets to zero. |
Co-authored-by: 9names <60134748+9names@users.noreply.github.com>
docs for each global_asm function. The docs are easy to read outside of the assembly string, because they get syntax highlighted as comments and not text. Also swaps the last few .sections for .pushsection
a523a4c to
74f261b
Compare
OK, turns out we cannot write |
|
Tested on the S32Z2, where it allowed me to delete a whole bunch of assembly code from the example and still enjoy SMP support. |
|
One general question: Assuming there are SoCs which even have something like 4 or 8 cores, maybe the kmain_secondary should receive the core ID as an input argument? |
A quad core cluster is quite possible, or even multiple clusters with some number of cores in each. But in that case, the secondary function can just read the CPUID register and work out what to do. I think the important thing is the split between the primary core (that zeroes .bss and initialises .data) and the secondary cores (which do not). |
|
Damn you GitHub. I’ll queue it again later on my work laptop. |
4 participants
Integrates SMP support into aarch32-rt. Now the default start-up routines (for Armv7-R, Armv7-A and Armv8-R) check MPIDR and do normal start-up on Core 0, and park any secondary core.
To get the secondary cores to work, you have to replace the park routine (
_asm_secondary_core_park) with one that waits for a reliable signal from Core 0 (like a hardware register, not definitely not a RAM location because RAM has random contents) and then returns. After that, stacks are initialised and the core ends up inkmain_secondary.This is a breaking change, but I think it makes SMP examples much easier to write. So much so, the
mps3-an536-smpexample folder has gone - they've been folded into the normalmps3-an536examples because they are now so similar.Closes #168
Closes #167