All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Russell King <linux@armlinux.org.uk>, Johan Jonker <jbx6244@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Hüseyin BIYIK" <boogiepop@gmx.com>
Subject: Re: [PATCH] ARM: rockchip: smp: enable CPU1 for rk3066a
Date: Fri, 02 Oct 2026 15:09:10 +0200	[thread overview]
Message-ID: <7009090.MHq7AAxBmi@diego> (raw)
In-Reply-To: <545b78a0-159b-4ebd-9e2a-47d519c98bf9@gmail.com>

Hi Johan,

Am Sonntag, 30. August 2026, 13:17:15 Mitteleuropäische Sommerzeit schrieb Johan Jonker:
> On 8/29/26 23:59, Heiko Stübner wrote:
> > Am Samstag, 29. August 2026, 01:40:57 Mitteleuropäische Sommerzeit schrieb Johan Jonker via B4 Relay:
> >> From: Hüseyin BIYIK <boogiepop@gmx.com>
> >>
> >> RK3066a CPU1 fails to come online. Fix by using
> >> a similar mailbox construction as in use with
> >> other Rockchip SoCs.
> > 
> 
> > "RK3066 CPU1 fails to come online with recent kernels....[rest]" or so
> 
> Not recent..
> 
> > and also please use the line length up a resonable length like around 70> to 75 characters.
> > 
> > Also, is it known, why that happens - i.e. what changed?
> 
> 
> What loader chain did you use then?
> 
> This guessing!!!:
> From TRM: RK PX2/rk3066a supports to boot from internal bootrom or embedded SRAM
> Currently rk3066 U-boot doesn't remap, so we end up in ROM code waiting for deadbeaf:
> 
> void main(void)
> {
>         deadbeaf = 1;
>         if ( !(__mrc(15, 0, 0, 0, 5) & 0xF) )
>         {
>                 __set_CPSR(0xD2u);
>                 __set_CPSR(0xD3u);
>                 DELAY_write(24);
>                 CRU_CLKSEL();
>                 DELAY(10000);
>                 MAIN_LOOP1x4();
>                 DNL_LOOP();
>                 while ( 1 )
>                         ;
>         }
>         __set_CPSR(0xD3u);
>         while ( deadbeaf != 0xDEADBEAF )
>                 __wfe();
>         secondary_startup();
> }
> 
> Can't put a precise time tag on it since when.
> Let us lead by what current available open source loaders solutions can do.
> Please advise here.
> How far does a fixes tag have to go back?

So ... found time to test a bit:
- Both my Marsboard (RK3066) and Radxa Rock (RK3188) currently have a
  u-boot that is really old ... 2017.09 / 2017.11 to be exact.
- Both boards can bring up the other cores just fine
- It seems there the remap was still enabled:
  https://git.u-boot-project.org/u-boot/u-boot/-/blob/v2017.11/arch/arm/mach-rockchip/rk3188-board.c?ref_type=tags#L31
- You cannot require people to update their bootloader, only work around
  old versions.

Right now you end up with a meshup of different parts.
In the old codepath, sram_addr+4 contains the kernel-start-address, which
now gets overwritten, breaking older loaders.

So the way forward would be:
- add code that disables remap on both rk3066+rk3188, hopefully resulting
  in the same behaviour indepent of the loader used
- change to use the bootrom path for all socs in rockchip_boot_secondary()
  so just remove the conditional around it
- drop the rockchip_smp_prepare_sram() part, as it's not needed anymore


Heiko



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

WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Russell King <linux@armlinux.org.uk>, Johan Jonker <jbx6244@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Hüseyin BIYIK" <boogiepop@gmx.com>
Subject: Re: [PATCH] ARM: rockchip: smp: enable CPU1 for rk3066a
Date: Fri, 02 Oct 2026 15:09:10 +0200	[thread overview]
Message-ID: <7009090.MHq7AAxBmi@diego> (raw)
In-Reply-To: <545b78a0-159b-4ebd-9e2a-47d519c98bf9@gmail.com>

Hi Johan,

Am Sonntag, 30. August 2026, 13:17:15 Mitteleuropäische Sommerzeit schrieb Johan Jonker:
> On 8/29/26 23:59, Heiko Stübner wrote:
> > Am Samstag, 29. August 2026, 01:40:57 Mitteleuropäische Sommerzeit schrieb Johan Jonker via B4 Relay:
> >> From: Hüseyin BIYIK <boogiepop@gmx.com>
> >>
> >> RK3066a CPU1 fails to come online. Fix by using
> >> a similar mailbox construction as in use with
> >> other Rockchip SoCs.
> > 
> 
> > "RK3066 CPU1 fails to come online with recent kernels....[rest]" or so
> 
> Not recent..
> 
> > and also please use the line length up a resonable length like around 70> to 75 characters.
> > 
> > Also, is it known, why that happens - i.e. what changed?
> 
> 
> What loader chain did you use then?
> 
> This guessing!!!:
> From TRM: RK PX2/rk3066a supports to boot from internal bootrom or embedded SRAM
> Currently rk3066 U-boot doesn't remap, so we end up in ROM code waiting for deadbeaf:
> 
> void main(void)
> {
>         deadbeaf = 1;
>         if ( !(__mrc(15, 0, 0, 0, 5) & 0xF) )
>         {
>                 __set_CPSR(0xD2u);
>                 __set_CPSR(0xD3u);
>                 DELAY_write(24);
>                 CRU_CLKSEL();
>                 DELAY(10000);
>                 MAIN_LOOP1x4();
>                 DNL_LOOP();
>                 while ( 1 )
>                         ;
>         }
>         __set_CPSR(0xD3u);
>         while ( deadbeaf != 0xDEADBEAF )
>                 __wfe();
>         secondary_startup();
> }
> 
> Can't put a precise time tag on it since when.
> Let us lead by what current available open source loaders solutions can do.
> Please advise here.
> How far does a fixes tag have to go back?

So ... found time to test a bit:
- Both my Marsboard (RK3066) and Radxa Rock (RK3188) currently have a
  u-boot that is really old ... 2017.09 / 2017.11 to be exact.
- Both boards can bring up the other cores just fine
- It seems there the remap was still enabled:
  https://git.u-boot-project.org/u-boot/u-boot/-/blob/v2017.11/arch/arm/mach-rockchip/rk3188-board.c?ref_type=tags#L31
- You cannot require people to update their bootloader, only work around
  old versions.

Right now you end up with a meshup of different parts.
In the old codepath, sram_addr+4 contains the kernel-start-address, which
now gets overwritten, breaking older loaders.

So the way forward would be:
- add code that disables remap on both rk3066+rk3188, hopefully resulting
  in the same behaviour indepent of the loader used
- change to use the bootrom path for all socs in rockchip_boot_secondary()
  so just remove the conditional around it
- drop the rockchip_smp_prepare_sram() part, as it's not needed anymore


Heiko




  reply	other threads:[~2026-10-02 13:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 23:40 [PATCH] ARM: rockchip: smp: enable CPU1 for rk3066a Johan Jonker via B4 Relay
2026-08-28 23:40 ` Johan Jonker
2026-08-28 23:40 ` Johan Jonker via B4 Relay
2026-08-29 21:59 ` Heiko Stübner
2026-08-29 21:59   ` Heiko Stübner
2026-08-30 11:17   ` Johan Jonker
2026-08-30 11:17     ` Johan Jonker
2026-10-02 13:09     ` Heiko Stübner [this message]
2026-10-02 13:09       ` 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=7009090.MHq7AAxBmi@diego \
    --to=heiko@sntech.de \
    --cc=boogiepop@gmx.com \
    --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 \
    /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.