On Wed, 2012-09-26 at 16:01 +0100, Peter Maydell wrote:
> On 26 September 2012 15:12, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> > On 26 September 2012 14:37, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> >> On 6 September 2012 18:12, Dave Martin <dave.martin@xxxxxxxxxx> wrote:
> >>> Signed-off-by: Dave Martin <dave.martin@xxxxxxxxxx>
> >>
> >> 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.
--
Tixy
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
