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

[Jonas Karlman]

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.

> 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.

Regards,
Jonas