[U-Boot] sunxi: CPU disabling
Marc Zyngier
marc.zyngier at arm.com
Tue Nov 25 11:51:30 CET 2014
On 25/11/14 10:27, Jan Kiszka wrote:
> On 2014-11-17 07:47, Jan Kiszka wrote:
>> On 2014-11-10 14:10, Marc Zyngier wrote:
>>> On 10/11/14 12:57, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi
>>>> working on a B-Pi. After the first discussion it became clear that we
>>>> need something like flush_dcache_all in the PSCI monitor (I don't think
>>>> we need an icache flush, do we?). Does anyone have a clever suggestion
>>>
>>> No, I-cache can be left alone.
>>>
>>>> how to reuse the existing code for that? Or do we really need to
>>>> re-implement everything, in the worst case in assembly?
>>>
>>> Why don't you turn the u-boot code into a set of macros, included by
>>> both the core u-boot code and the PSCI code?
>>
>> I've now ported over v7_flush_dcache_all from the Linux kernel.
>>
>> However, that didn't magically solve the remaining issues with your
>> patch: I'm getting crashes on CPU 0 after handling the shoot-down FIQ.
>> That is even then the case if I only acknowledge the FIQ on the receiver
>> side, don't do any fiddling with CPU1's power states. Only if I
>> disabling sending the FIQ from CPU 1, the system remains stable in a CPU
>> off/on loop.
>>
>> Below the patch I'm using. Any ideas if something is wrong with the FIQ
>> handler or the setup of this mechanism or whatever?
>
> Ping. I'm still seeing no light in this tunnel. One finding below, but
> maybe a non-issue.
Sorry, I haven't had a chance to look at this at all, as the next kernel
merge window is getting closer and I still have tons of things to review.
What you describe above seems to indicate that it is the FIQ handling
that breaks something. Just to understand what you're observing:
- does CPU0 always lock-up?
- if not, can you find out if it locks up on the "out" path or not?
I vaguely remember seeing issues in the "wait" loop below, but my
memory is very fuzzy... Any chance you could instrument this?
>> +.globl psci_fiq_enter
>> +psci_fiq_enter:
>> + push {r0-r12}
>> +
>> + @ Switch to secure
>> + mrc p15, 0, r7, c1, c1, 0
>> + bic r8, r7, #1
>> + mcr p15, 0, r8, c1, c1, 0
>> + isb
>> +
>> + movw r8, #(GICC_BASE & 0xffff)
>> + movt r8, #(GICC_BASE >> 16)
>> + ldr r9, [r8, #GICC_IAR]
>> + movw r10, #0x3ff
>> + movt r10, #0
>> + cmp r9, r10
>> + beq out
>> + movw r10, #0x3fe
>> + cmp r9, r10
>> + beq out
>> + str r9, [r8, #GICC_EOIR]
>> + dsb
>> +
>> + @ Compute CPU number
>> + lsr r9, r9, #10
>> + and r9, r9, #0xf
>> +
>> + movw r8, #(SUN7I_CPUCFG_BASE & 0xffff)
>> + movt r8, #(SUN7I_CPUCFG_BASE >> 16)
>> +
>> + @ Wait for the core to enter WFI
>> + lsl r11, r9, #6 @ x64
>> + add r11, r11, r8
>> +
>> +1: ldr r10, [r11, #0x48]
>> + tst r10, #(1 << 2)
>> + bne 2f
>> + timer_wait r10, ONE_MS
>> + b 1b
>> +
>> + @ Reset CPU
>> +2: mov r10, #0
>> + str r10, [r11, #0x40]
>> +
>> + @ Lock CPU
>> + mov r10, #1
>> + lsl r9, r10, r9 @ r9 is now CPU mask
>> + ldr r10, [r8, #0x1e4]
>> + bic r10, r10, r9
>> + str r10, [r8, #0x1e4]
>> +
>> + @ Set power gating
>> + ldr r10, [r8, #0x1b4]
>> + orr r10, r10, #1
>> + str r10, [r8, #0x1b4]
>> + timer_wait r10, ONE_MS
>> +
>> + @ Activate power clamp
>> + mov r10, #1
>> +1: str r10, [r8, #0x1b0]
>> + lsl r10, r10, #1
>> + orr r10, r10, #1
>> + tst r10, #0x100
>> + beq 1b
>> +
>> + @ Restore security level
>> +out: mcr p15, 0, r7, c1, c1, 0
>
> There is no isb here - not required? It has no impact on the stability
> issue, though.
The following instructions contain an exception return (movs pc, lr),
which acts implicitly as an isb.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
More information about the U-Boot
mailing list