Hi Quentin, You’re actually right; git bisect has shown that the problematic commit is the following one:
commit c6bba31dbdd450081503dc0e20fcfb4328b347e4 Author: Jonas Karlman <[email protected]> Date: Sat Jul 12 21:12:29 2025 +0000 rockchip: spl-boot-order: Defer probe of boot device Boot devices are being probed when SPL boot order is determined. This may delay boot slightly and can prevent booting from SPI Flash on boards that use same pins for SPI Flash and eMMC due to pinctrl being applied prior to booting. Instead defer probe of the boot device until SPL try to load image from the boot device by using uclass_find_device_by_of_offset() instead of the get variant. Your question about used u-boot and kernel version: currently u-boot version is v2025.10, and this version works. I tried switching to v2026.01 a while ago, but because of this problem I’ve been waiting for a newer version to come out, in the hope that the problem will be sorted out there. I’ve tried every new version, but the problem persisted.. Kernel versiona are: 6.18 (so called "current" kernel in Armbian) and 7.2 (so called "edge"). I have tested both versions, but the behaviour is the same. For git bisect I have used "edge" kernel (7.2.8). I’m absolutely on your side – we should get to the root of the problem rather than just treating the symptoms. Cheers, Milivoje On Thu, Oct 1, 2026 at 8:59 PM Milivoje Legenovic <[email protected]> wrote: > > 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
