From: Jan Kiszka <jan.kiszka@web.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] sunxi: CPU disabling
Date: Wed, 26 Nov 2014 09:44:07 +0100 [thread overview]
Message-ID: <547592D7.70809@web.de> (raw)
In-Reply-To: <546999F9.9070009@web.de>
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?
>
> Jan
>
> ---
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S
> index b9ea78b..0e4bca4 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci.S
> @@ -18,6 +18,7 @@
> */
>
> #include <config.h>
> +#include <asm/gic.h>
> #include <asm/psci.h>
> #include <asm/arch/cpu.h>
>
> @@ -38,6 +39,8 @@
>
> #define ONE_MS (CONFIG_SYS_CLK_FREQ / 1000)
> #define TEN_MS (10 * ONE_MS)
> +#define GICD_BASE 0x1c81000
> +#define GICC_BASE 0x1c82000
>
> .macro timer_wait reg, ticks
> @ Program CNTP_TVAL
> @@ -61,7 +64,27 @@
>
> .globl psci_arch_init
> psci_arch_init:
> + movw r4, #(GICD_BASE & 0xffff)
> + movt r4, #(GICD_BASE >> 16)
> +
> + ldr r5, [r4, #GICD_IGROUPRn]
> + bic r5, r5, #(1 << 15) @ SGI15 as Group-0
> + str r5, [r4, #GICD_IGROUPRn]
> +
> + mov r5, #0 @ Set SGI15 priority to 0
> + strb r5, [r4, #(GICD_IPRIORITYRn + 15)]
> +
> + add r4, r4, #0x1000 @ GICC address
> +
> + mov r5, #0xff
> + str r5, [r4, #GICC_PMR] @ Be cool with non-secure
> +
> + ldr r5, [r4, #GICC_CTLR]
> + orr r5, r5, #(1 << 3) @ Switch FIQEn on
> + str r5, [r4, #GICC_CTLR]
> +
> mrc p15, 0, r5, c1, c1, 0 @ Read SCR
> + orr r5, r5, #4 @ Enable FIQ in monitor mode
> bic r5, r5, #1 @ Secure mode
> mcr p15, 0, r5, c1, c1, 0 @ Write SCR
> isb
> @@ -79,6 +102,77 @@ psci_arch_init:
>
> bx lr
>
> +.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
> +
> + pop {r0-r12}
> + movs pc, lr
We have to use "subs pc, lr, #4" to return from FIQ. I guess you can
explain better than I why, I only stumbled over this in a stackoverflow
posting - and it works!
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141126/d8d2b849/attachment.pgp>
next prev parent reply other threads:[~2014-11-26 8:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-10 12:57 [U-Boot] ARM: flush_dcache_all for PSCI Jan Kiszka
2014-11-10 13:10 ` Marc Zyngier
2014-11-17 6:47 ` [U-Boot] sunxi: CPU disabling (was: Re: ARM: flush_dcache_all for PSCI) Jan Kiszka
2014-11-25 10:27 ` [U-Boot] sunxi: CPU disabling Jan Kiszka
2014-11-25 10:51 ` Marc Zyngier
2014-11-25 11:02 ` Jan Kiszka
2014-11-26 8:44 ` Jan Kiszka [this message]
2014-11-26 13:48 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=547592D7.70809@web.de \
--to=jan.kiszka@web.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox