From: "Heiko Stübner" <heiko@sntech.de>
To: "Yalçın Can" <ylcncn@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Johan Jonker <jbx6244@gmail.com>
Subject: Re: [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores
Date: Fri, 30 Oct 2026 11:22:32 +0100 [thread overview]
Message-ID: <1940718.QZUTf85G27@diego> (raw)
In-Reply-To: <20261030073647.164416-1-ylcncn@gmail.com>
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/
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: "Yalçın Can" <ylcncn@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Johan Jonker <jbx6244@gmail.com>
Subject: Re: [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores
Date: Fri, 30 Oct 2026 11:22:32 +0100 [thread overview]
Message-ID: <1940718.QZUTf85G27@diego> (raw)
In-Reply-To: <20261030073647.164416-1-ylcncn@gmail.com>
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
next prev parent reply other threads:[~2026-10-30 10:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 7:36 [PATCH] ARM: rockchip: rk3066: set soc_remap before starting secondary cores Yalçın Can
2026-10-30 7:36 ` Yalçın Can
2026-10-30 10:22 ` Heiko Stübner [this message]
2026-10-30 10:22 ` 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=1940718.QZUTf85G27@diego \
--to=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=ylcncn@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.