[PATCH v6 0/3] Static initcalls

[Michael Nazzareno Trimarchi]

Hi all

On Fri, Jul 4, 2025 at 10:33 AM Jerome Forissier
<jerome.forissier at linaro.org> wrote:
>
> Hi Fabio,
>
> On 7/4/25 04:34, Fabio Estevam wrote:
> > Adding Tom.
> >
> > On Thu, Jul 3, 2025 at 11:33 PM Fabio Estevam <festevam at gmail.com> wrote:
> >>
> >> Hi Jerome and Tom,
> >>
> >> On Fri, Apr 4, 2025 at 10:51 AM Jerome Forissier
> >> <jerome.forissier at linaro.org> wrote:
> >>>
> >>> This series replaces the dynamic initcalls (with function pointers) with
> >>> static calls, and gets rid of initcall_run_list(), init_sequence_f,
> >>> init_sequence_f_r and init_sequence_r. This makes the code simpler and the
> >>> binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510
> >>> bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig).
> >>>
> >>> Execution time doesn't seem to change noticeably. There is no impact on
> >>> the SPL.
> >>>
> >>> The inline assembly fixes, although they look unrelated, are triggered
> >>> on some platforms with LTO enabled. For example: kirkwood_defconfig.
> >>>
> >>> CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514
> >>>
> >>> Changes in v6:
> >>> - Rebase on next branch
> >>
> >> This series breaks the boot on an imx6dl sabresd board (mx6sabresd_defconfig):
> >>
> >> U-Boot SPL 2025.04-01075-g3c9c3d852e00 (Jul 03 2025 - 23:23:12 -0300)
> >> Trying to boot from MMC1
> >>
> >> (Hangs here)
> >>
> >> I ran a git bisect from 2025.04 to master, and that was the result:
> >>
> >> 8c98b57d72d5e5b94ed064fe1041e51216165334 is the first bad commit
> >> commit 8c98b57d72d5e5b94ed064fe1041e51216165334
> >> Merge: 739ad58dbee8 bbee3d41b33f
> >> Author: Tom Rini <trini at konsulko.com>
> >> Date:   Mon Apr 14 08:59:45 2025 -0600
> >>
> >>     Merge patch series "Static initcalls"
> >>
> >>     Jerome Forissier <jerome.forissier at linaro.org> says:
> >>
> >>     This series replaces the dynamic initcalls (with function pointers) with
> >>     static calls, and gets rid of initcall_run_list(), init_sequence_f,
> >>     init_sequence_f_r and init_sequence_r. This makes the code simpler and the
> >>     binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510
> >>     bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig).
> >>
> >>     Execution time doesn't seem to change noticeably. There is no impact on
> >>     the SPL.
> >>
> >>     The inline assembly fixes, although they look unrelated, are triggered
> >>     on some platforms with LTO enabled. For example: kirkwood_defconfig.
> >>
> >>     CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514
> >>
> >>     Link: https://lore.kernel.org/r/20250404135038.2134570-1-jerome.forissier@linaro.org
> >>
> >>  arch/arm/include/asm/system.h             |  22 ++-
> >>  arch/arm/lib/cache.c                      |   5 +-
> >>  arch/arm/mach-kirkwood/include/mach/cpu.h |   9 +-
> >>  arch/sh/lib/board.c                       |   9 +-
> >>  common/board_f.c                          | 223 ++++++++++++++-------------
> >>  common/board_r.c                          | 247 +++++++++++++++---------------
> >>  include/initcall.h                        |  49 +++---
> >>  lib/Makefile                              |   1 -
> >>  lib/initcall.c                            | 102 ------------
> >>  test/py/tests/test_trace.py               |   8 +-
> >>  10 files changed, 297 insertions(+), 378 deletions(-)
> >>  delete mode 100644 lib/initcall.c
> >>
> >> Any ideas?
>
> Have you tried the master branch recently? Hopefully commit 410d59095a9f
> ("arm: kirkwood: fix freeze on boot") should fix the issue.
>

We have problems that our board crashes with display enabled when this
series is applied but we can boot
if the series is reverted. We are still try to understand what is going on

Michael

> Thanks,
> --
> Jerome



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com