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
