Hi Milivoje, On Wed, 30 Sept 2026 at 23:29, Milivoje Legenovic <[email protected]> wrote: > > 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?"
Good idea! Does 'dmesg | grep -i dmi' show a DMI line, and is /sys/firmware/dmi/tables populated? That shows whether the kernel reads the property. Does the hang go away if the property stays but the region is reserved? A quick hack is fdt_add_mem_rsv(fdt, smbiosaddr, TABLE_SIZE) next to the setprop in fdt_chosen() If so, you could add a fix for 209bbc4e003 - i.e. reserve the table. Regards, Simon > > 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
