[PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores

[PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores

[Yalçın Can]

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

[PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores

[Yalçın Can]

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

Re: [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores

[Heiko Stübner]

Hi,

Am Freitag, 30. Oktober 2026, 08:36:47 Mitteleuropäische Normalzeit schrieb Yalçın Can:
> 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>

there is another patch from Johan pending [0], which I plan to apply after
the merge-window, that moves all of the A9 cores over to booting via
the SoCs bootrom and gets rid of the whole trampoline code.


Heiko


[0] https://lore.kernel.org/linux-rockchip/20261017-cpu-v3-1-25d8f4b06362@gmail.com/

Re: [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores

[Heiko Stübner]

Hi,

Am Freitag, 30. Oktober 2026, 08:36:47 Mitteleuropäische Normalzeit schrieb Yalçın Can:
> 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>

there is another patch from Johan pending [0], which I plan to apply after
the merge-window, that moves all of the A9 cores over to booting via
the SoCs bootrom and gets rid of the whole trampoline code.


Heiko


[0] https://lore.kernel.org/linux-rockchip/20261017-cpu-v3-1-25d8f4b06362@gmail.com/



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