Hi Simon, 'dmesg | grep -i dmi' shows this:
[ 1.107089] DMI not present or invalid. and /sys/firmware/dmi/tables is not populated: ls -l /sys/firmware/dmi/tables ls: cannot access '/sys/firmware/dmi/tables': No such file or directory Adding fdt_add_mem_rsv() does not change anything, it still hangs, and "DMI not present or invalid" message remains. This is how I did it: fdt_add_mem_rsv(fdt, smbiosaddr, 0x00001000); As I’m not familiar with the code, I didn’t know how to calculate or determine the table size, so I simply used the SZ_4K constant (aligned to 4KB). Let me know if that is wrong, and what the correct value should be. Cheers, Milivoje On Thu, Oct 1, 2026 at 3:27 AM Simon Glass <[email protected]> wrote: > > 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
