Hi Jonas, I've applied your patches, and can confirm it fixes the problem. Therefore the mystery is solved.
Thanks to everyone involved. Cheers, Milivoje On Fri, Oct 2, 2026 at 7:47 AM Jonas Karlman <[email protected]> wrote: > > Hi Milivoje, > > On 10/2/2026 2:55 AM, Milivoje Legenovic wrote: > > 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. > > This patch changed so that devices is lazy probed in SPL, a side affect > from this has likely been that the clock drivers are no longer always > probed in SPL phase. > > Please see the test the series "rockchip: Always init clocks in SPL > build for RK35xx" [1], it should help ensure that e.g. SPLL and CPU PLLs > are configured in SPL, instead of possible having to wait until Linux > configures CPU clocks. > > [1] https://lore.kernel.org/u-boot/[email protected]/ > > Regards, > Jonas > > > > > 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 >
