Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Yalçın Can" <ylcncn@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores
Date: Fri, 30 Oct 2026 10:36:47 +0300	[thread overview]
Message-ID: <20261030073647.164416-1-ylcncn@gmail.com> (raw)

A Cortex-A9 core on the rk3066 starts at address 0 when it is powered up.
The SMP code copies a trampoline to the start of the internal sram and
relies on GRF_SOC_CON0 soc_remap (bit 12) mapping the sram at address 0.
The vendor loader sets that bit before starting the kernel, but a boot
loader started directly by the bootrom leaves it cleared. The core then
runs the bootrom instead, which parks it and also writes into the start of
the sram, so the trampoline's target word is overwritten as well, and the
boot logs "CPU1: failed to come online".

Set soc_remap after the secondary cores have been powered down and before
the trampoline is copied. The rk3188 shares these smp operations; its grf
has a different compatible and is left alone.

Tested on an RK3066a board (MK808B) with U-Boot started from the NAND ID
blocks by the bootrom: before, CPU1 never came online (GRF_SOC_CON0 bit 12
clear, sram+4 read 0x00000001 instead of the physical address of
secondary_startup); with this patch both cores come up at boot, three
offline/online cycles of cpu1 work, and the board restarts normally after
a reboot and after a forced panic. Booting through the vendor loader, which
already sets the bit, is unchanged. Not tested on rk3188.

Fixes: a7a2b3118b41 ("ARM: rockchip: add smp bringup code")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Yalçın Can <ylcncn@gmail.com>
---
 arch/arm/mach-rockchip/platsmp.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index f659d894b..2edd0fa46 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -198,6 +198,29 @@ static int __init rockchip_smp_prepare_sram(struct device_node *node)
 	return 0;
 }
 
+#define RK3066_GRF_SOC_CON0	0x150
+#define RK3066_SOC_REMAP	BIT(12)
+
+/*
+ * A starting core fetches its first instruction from address 0. Only with
+ * soc_remap set is that the on-chip sram holding the trampoline; otherwise it
+ * is the bootrom, which parks the core and writes into the start of the sram.
+ * The vendor loader sets the remap, other loaders (e.g. U-Boot started from
+ * the bootrom) leave it cleared. The secondary cores are powered down here.
+ * Only the rk3066 is handled; other socs using these smp ops are left alone.
+ */
+static void __init rockchip_smp_remap_sram(void)
+{
+	struct regmap *grf;
+
+	grf = syscon_regmap_lookup_by_compatible("rockchip,rk3066-grf");
+	if (IS_ERR(grf))
+		return;
+
+	regmap_write(grf, RK3066_GRF_SOC_CON0,
+		     RK3066_SOC_REMAP | (RK3066_SOC_REMAP << 16));
+}
+
 static const struct regmap_config rockchip_pmu_regmap_config = {
 	.name = "rockchip-pmu",
 	.reg_bits = 32,
@@ -321,6 +344,8 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
 		pmu_set_power_domain(0 + i, false);
 
 	if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+		rockchip_smp_remap_sram();
+
 		if (rockchip_smp_prepare_sram(node)) {
 			of_node_put(node);
 			return;
-- 
2.47.3


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

             reply	other threads:[~2026-10-30  7:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30  7:36 Yalçın Can [this message]
2026-10-30 10:22 ` [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores Heiko Stübner

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=20261030073647.164416-1-ylcncn@gmail.com \
    --to=ylcncn@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    /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