On 06/30/2015 05:56 AM, Jonas Jensen wrote:
Hello,
I have found the following issue with RPi 2:
Only 1 CPU is brought up when the kernel is started from script (see [1]).
All 4 CPUs are brought up if started "manually" typing in environment variables from said script (see [2]).
I suspect it's a fluke that it works when you run things manually/slowly.
I /think/ that before the binary FW starts U-Boot (or whatever it boots), it releases all 4 CPUs from reset, and CPU1..n all end up running a tiny piece of code ("SMP pen") that just loops doing nothing until some flag is set. All code that runs on CPU0 must be careful not to corrupt that code or the flag it uses. However, U-Boot (and I expect the upstream kernel) don't yet know about this, and hence sometimes/often corrupt that SMP pen, resulting in strange behaviour. I'm pretty sure I've seen all 4 CPUs start booting the Linux kernel in parallel before.
In summary, I know there are issues in this area when using U-Boot. I don't know of any fix at present. Either U-Boot must hard-code some reserved memory regions, or perhaps the binary FW has some way of informing SW where the SMP pen region is, and U-Boot needs to learn how to find/interpret that information (and pass it to the kernel via /memreserve/ or similar in DT).
Eric, did you find out any more details on the SMP pen mechanism since I last asked you about it?