Hello everyone, Here are the details of my analysis: The commit that introduced the change in behavior in version 2026.01 is this one:
commit 209bbc4e0032228c6ea17e2172a8a6b89756c4f5 Author: Adriana Nicolae <[email protected]> Date: Thu Nov 27 08:28:34 2025 -0800 boot/bootfdt: Add smbios3-entrypoint to FDT for non-EFI boots The Linux kernel can discover SMBIOS tables through two primary methods: 1. Via EFI tables, when using EFI boot; 2. Via the 'smbios3-entrypoint' property in the /chosen node of the device tree. ... I found this out by comparing the device tree from a working version, decompiled using sudo dtc -I fs -O dts /sys/firmware/devicetree/base -o live_tree.dts and difference was in /chosen node: chosen { u-boot,version = "2026.01_armbian-2026.01-S127a-P7283-Hee1c-V2928-B3a7f-R448a"; linux,initrd-end = <0x00 0xecbffca5>; bootargs = ... smbios3-entrypoint = <0x00 0xedf47000>; kaslr-seed = <0x00 0x00>; linux,initrd-start = <0x00 0xeb519000>; stdout-path = "serial2:1500000n8"; }; In 2026.01 version smbios3-entrypoint was there, in 2025.10 not. I searched for this term in git history and found the commit mentioned above. With git show I saw what activates this, and made a patch in armbian build system to disable it and confirm it fixes the problem. And it fixed it. Here is also where kernel hangs for 60 seconds (always at the same place): [ 14.482048] calling gpio_led_driver_init+0x0/0x38 @ 1 [ 78.137967] Freeing initrd memory: 23448K [ 78.165027] probe of leds returned 0 after 63677665 usecs [ 78.166792] initcall gpio_led_driver_init+0x0/0x38 returned 0 after 63684076 usecs As you can see, I was only able to find the cause, but that’s the extent of my expertise. At first, I wanted to sort out the problem with a patch in the Armbian build project, but then I thought: "Why not sort it out at source?" Cheers, Milivoje On Mon, Sep 28, 2026 at 4:37 PM Simon Glass <[email protected]> wrote: > > On Fri, 25 Sept 2026 at 18:59, Milivoje Legenovic <[email protected]> > wrote: > > > > After upgrading u-boot in Armbian for the Odroid M2 board from > > version v2025.10 to a higher version (it doesn’t matter which one), > > the board does boot, but the boot process halts for 60 seconds, > > and only continues once this time has elapsed. Debugging via a > > UART cable showed that u-boot hands control over to the kernel, > > and then freezes there. The only difference compared to v2025.10 > > was the SMBIOS table. After disabling this configuration option > > everything worked perfectly. > > > > Signed-off-by: Milivoje Legenovic <[email protected]> > > --- > > configs/odroid-m2-rk3588s_defconfig | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Simon Glass <[email protected]> > > But I agree it would be useful to know why the kernel can hang in this > way (I didn't even know it looked at SMBIOS tables!) > > - Simon
