Hi Milivoje,
On 10/1/26 12:28 AM, Milivoje Legenovic wrote:
[You don't often get email from [email protected]. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
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.
As far as my understanding goes, there's actually nothing consuming this
DT property right now. There is a patch on the Linux kernel mailing
list, c.f.
https://lore.kernel.org/lkml/[email protected]/
but it's not merged. I doubt Armbian would backport this but maybe they did?
So I don't think the *presence* of this property changes anything, but
there could be side-effects (e.g. actually having the SMBIOS3 table
somewhere it isn't expected, potentially corrupting e.g. the kernel).
I'm a bit skeptical though as the commit you point to only adds a
property, it doesn't seem to be doing anything else.
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
So the probe of the drivers/leds/leds-gpio.c driver took 60+seconds,
that seems quite improbable (well, it technically could be anything on
the path for this driver to probe, c.f. really_probe() in drivers/base/dd.c.
Can you disable that driver (CONFIG_LEDS_GPIO) and see if it goes
further? Being curious :) (I see Armbian did some - clearly downstream -
changes to this driver, so being curious :) ).
Can you provide us with a link (with commit hash) to the exact sources
of U-Boot and Linux kernel that Armbian builds for your board?
Can you provide us with the full bootlog (including U-Boot up until the
Linux kernel's hung)?
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?"
I'm not convinced we're there yet but that's the kind of spirit I like,
let's not fix symptoms or consequences :)
Cheers,
Quentin
