[PATCH] arm: rockchip: Guard call of board_early_init_f in SPL

Tom Rini trini at konsulko.com
Wed Mar 25 20:51:29 CET 2026


On Wed, Mar 25, 2026 at 01:42:28PM -0600, Simon Glass wrote:
> Hi Jonas,
> 
> On Wed, 25 Mar 2026 at 13:31, Jonas Karlman <jonas at kwiboo.se> wrote:
> >
> > Hi Tom,
> >
> > On 3/25/2026 8:00 PM, Tom Rini wrote:
> > > Today, no platforms call board_early_init_f, and rockchip provides a
> > > weak default function. Change this to not providing a weak function and
> > > only call board_early_init_f if CONFIG_BOARD_EARLY_INIT_F is enabled.
> > > This will allow any potential future needs to be taken care of, and make
> > > future consolidation easier.
> > >
> > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > ---
> > > Cc: Philipp Tomsich <philipp.tomsich at vrull.eu>
> > > Cc: Kever Yang <kever.yang at rock-chips.com>
> > > ---
> > >  arch/arm/mach-rockchip/spl.c | 8 ++------
> > >  1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> > > index e989c148079a..8026cc0abb8d 100644
> > > --- a/arch/arm/mach-rockchip/spl.c
> > > +++ b/arch/arm/mach-rockchip/spl.c
> > > @@ -97,11 +97,6 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
> > >       return MMCSD_MODE_RAW;
> > >  }
> > >
> > > -__weak int board_early_init_f(void)
> > > -{
> > > -     return 0;
> > > -}
> > > -
> > >  __weak int arch_cpu_init(void)
> > >  {
> > >       return 0;
> > > @@ -111,7 +106,8 @@ void board_init_f(ulong dummy)
> > >  {
> > >       int ret;
> > >
> > > -     board_early_init_f();
> > > +     if (IS_ENABLED(CONFIG_BOARD_EARLY_INIT_F))
> >
> > This patch seem to introduce a change in behavior for chromebook bob and
> > kevin, they do not seem to enable BOARD_EARLY_INIT_F, yet they have a
> > board_early_init_f() in board/google/gru/gru.c no longer being called
> > after this change.

I wouldn't call it a behavior change, since it's not called now, and
this is the output from building before/after, checking for size
differnces (and how I spotted odd cases as part of this overall work):

            chromebook_bob : spl/u-boot-spl:all -8 spl/u-boot-spl:text -8
               spl-u-boot-spl: add: 0/-1, grow: 0/-1 bytes: 0/-12 (-12)
                 function                                   old     new   delta
                 board_init_f                               148     144      -4
                 board_early_init_f                           8       -      -8
            chromebook_kevin: spl/u-boot-spl:all -8 spl/u-boot-spl:text -8
               spl-u-boot-spl: add: 0/-1, grow: 0/-1 bytes: 0/-12 (-12)
                 function                                   old     new   delta
                 board_init_f                               148     144      -4
                 board_early_init_f                           8       -      -8


> > I do not have a chromebook_bob/kevin so I cannot help verify if this
> > change break anything, hopefully Simon can help test/verify.
> 
> Kevin spews some junk to the console with or without this patch.
> 
> No change observed on bob or kevin. BTW both are in the lab so you
> should be able to test if you push to your tree.
> 
> Tested-by: Simon Glass <sjg at chromium.org>  # chromebook_kevin
> Tested-by: Simon Glass <sjg at chromium.org>  # chromebook_bob

Perhaps the problem is those platforms should be enabling, but lost.
I'll take a look, but would be unrelated to this (since if enabling
BOARD_EARLY_INIT_F it would then call it).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260325/36ecbce5/attachment.sig>


More information about the U-Boot mailing list