Stephen Warren swarren@wwwdotorg.org writes:
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?
Oh, I thought we were settled on this back in May -- the CPUs are spinning in the low 8kb. They are in that state by the time the firmware has handed off to us. I think it's modifying a /memreserve/ node for you to know where the pen is.
Hey, do you know what's going on with merging code? I feel really stuck here -- I've got a graphics driver, and a Pi2 implementation, and Andrea has cpufreq, and we're still stuck on getting the firmware driver merged.