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

[Tom Rini]

On Wed, Mar 25, 2026 at 09:12:31PM +0100, Jonas Karlman wrote:
> On 3/25/2026 8:51 PM, Tom Rini wrote:
> > 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
> 
> You mean the function is currently being optimized out? Why would it not
> be called before the change introduced in this patch?
> 
> The code in board/google/gru/gru.c is silly and probably gets optimized
> out anyway, but the comment there suggest something was done to try and
> make so it was not.

You're right, sorry. Since the size change is the exact same as every
platform that was calling the weak function, it seemed like it must have
not been using that gru.c version at all. But building on top of this
patch and enabling BOARD_EARLY_INIT_F for bob/kevin (and some quick
rework so that full U-Boot links), and there's no size change to SPL.

> > 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).
> 
> board_early_init_f() in gru.c is wrapped around CONFIG_XPL_BUILD so
> should only be included in SPL and was called from rockchip spl.c
> board_init_f() prior to this patch.
> 
> Based on Simons comment I guess the board_early_init_f() in gru.c
> probably could and should be fully removed, as it currently does not
> seem to provide the suggested delay.

Yes, both currently go green in GitLab when we run CI on them, with or
without this patch, so there's no change in the end.

-- 
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/fa629550/attachment.sig>