On Wed, 2012-09-26 at 16:01 +0100, Peter Maydell wrote:
On 26 September 2012 15:12, Peter Maydell peter.maydell@linaro.org wrote:
On 26 September 2012 14:37, Peter Maydell peter.maydell@linaro.org wrote:
On 6 September 2012 18:12, Dave Martin dave.martin@linaro.org wrote:
Signed-off-by: Dave Martin dave.martin@linaro.org
This patch causes the kernel to get stuck at "Calibrating delay loop...".
I'm not sure why this happens (investigating) but if I move the enter_hyp macro call back to where it used to be (leaving the rest of the patch intact) it boots OK...
...hmm, no, seems to be a false alarm. I must not have recompiled properly or something, it works OK now. Sorry for the noise.
I was right the first time. The model runs really slowly because CPU1+ have run off into the weeds.
I saw something like that when I tried this patch. I was just about going to get back to looking at this after being sidetracked on more urgent issues, but I see you have solved this particular issue...
The patch has added an 'enter_hyp' call into the chunk of code which is relocated to some random address, which means the code is now too long and we only relocate half of it. So when the primary CPU wakes up the secondaries they just run off into the weeds. Solution: move the enter_hyp to before the secondary-CPU pen code rather than after it.
That analysis sounds reasonable to me and I have successfully tested this modified solution on an A15x4 model. And also on A15x4-A7x4 after first applying the CCI hack to get bit.LITTLE working. To avoid ambiguity about the code I tested, I applied the following diff on top of Dave's v2 patches...
---------------------------------------------------------------------- diff --git a/boot.S b/boot.S index fe7acdf..cd2c09d 100644 --- a/boot.S +++ b/boot.S @@ -106,6 +106,8 @@ start: @ Secondary CPUs (following the RealView SMP booting protocol) @
+ enter_hyp + ldr r1, =fs_start - 0x100 adr r2, 1f ldmia r2, {r3 - r7} @ move the code to a location @@ -124,7 +126,6 @@ start: cmp r1, #0 beq 1b
- enter_hyp mov pc, r1 @ branch to the given address #endif ----------------------------------------------------------------------
The further good news is that after this patchset, enabling the CCI works OK when done just before entering the kernel. This proves that we'll be able to implement functionality in the C code to conditionally setup CCI based on device-tree contents.