[PATCH v2] arm64: dts: rockchip: Turn all LEDs on at boot for Radxa boards

[Quentin Schulz]

Hi all,

On 11/11/25 5:14 PM, Dragan Simic wrote:
> Hello all,
> 
> (+ Quentin)
> 
> On Tuesday, November 11, 2025 16:32 CET, FUKAUMI Naoki <naoki at radxa.com> wrote:
>> On 11/11/25 23:46, Dragan Simic wrote:
>>> On Tuesday, November 11, 2025 14:07 CET, "Diederik de Haas" <diederik at cknow-tech.com> wrote:
>>>> On Tue Nov 11, 2025 at 6:41 AM CET, FUKAUMI Naoki wrote:
>>>>> Radxa's boards turn all LEDs on at boot(loader), but some boards don't
>>>>> have `default-state` property in Linux kernel tree but have it in
>>>>> U-Boot tree instead[1].
>>>>>
>>>>> This patch adds `default-state = "on"` for (almost) all LEDs (with a
>>>>> few exceptions which should be "off" such as RGB LEDs on E25 and LAN/
>>>>> WAN LEDs on E20C/E52C).
>>>>
>>>> I'm missing the *why* these changes would be an improvement.
>>>>
>>>> Personally, for both 'heartbeat' and 'netdev' triggers, I want them to
>>>> be off by default and once it gets a 'heartbeat' or a 'netdev' trigger,
>>>> THEN I want the LED to be on/blinking.
>>>
>>> That's a good question for Naoki.  My own preference would also
>>> be to have the device's power LED turned on by U-Boot as quickly
>>> as possible after supplying power to the board or turning it on
>>> by pressing the power button.  I'm actually not a big fan of
>>> having all the LEDs shining for a couple of seconds or so, which
>>> may actually look like some error condition to me.
>>>
>>> Having all that in mind, I may suggest that just the U-Boot's
>>> behavior is changed to turn the power LEDs on only.
>>
>> I can't quite explain it, but...
>>
>> - 1st (Power) LED
>>
>> The 1st (power) LED turns on automatically/immediately without software
>> intervention. (On some boards, this LED cannot be controlled by software
>> at all.)
>>
>> In DTS, this should be described using `default-state = "on"`. The use
>> of the Linux-specific property `linux,default-trigger = "default-on"` is
>> unsuitable for non-Linux environments.
>>
>> - 2nd (Heartbeat) LED
>>
>> The 2nd (heartbeat) LED can be controlled by software. It should be lit
>> up as quickly as possible to indicate that the very first software
>> (e.g., the bootloader) is running.
>>
>> On Linux, usually this is used as `linux,default-trigger = "heartbeat"`.
>> It indicates that kernel is running (regardless of the `default-state`
>> setting), and its behavior can be modified in user space.
> 
> As discussed already in the #linux-rockchip IRC channel, [1] perhaps
> the best option would be to have the power LEDs turned on as quickly
> upon powering on the board as possible, and to have U-Boot pulsate
> the heartbeat LEDs using the LED_BOOT feature.  In such a scenario,
> no other LEDs would be turned on early, and the LED-related DT parts
> specific to U-Boot would be migrated to the kernel DTs.
> 
> [1] https://libera.catirclogs.org/linux-rockchip/2025-11-11#38997824;
> 

The LED_BOOT feature (guarded by the Kconfig symbol of the same name) in 
U-Boot only applies if /options/u-boot/boot-led property is set.

If the driver for the LED (typically a GPIO LED controller I guess, so 
LED_GPIO symbol) is compiled in, then, as far as I could tell, the Boot 
LED will be turned on right before entering the main loop of U-Boot.

If LED_BLINK (if HW blinking is supported) or LED_SW_BLINK is enabled, 
the Boot LED will be blinking some time after relocation but still 
turned on soon after (if it reaches that part of the code). This means 
it'll be on before the kernel starts.

I'm not sure there's a way to hook something *after* we've entered 
U-Boot main-loop (read "call led_boot_blink() from some board file"), 
aside from calling `led <led-name> blink <period>` from U-Boot CLI.

I'm a bit bummed by this behavior, I would have preferred the ability to 
have the Boot LED blink until the kernel starts. I could then have a 
different period for U-Boot (50% duty cycle at 250ms period by default) 
and for the kernel. Of course, if it's SW blinking, once exiting U-Boot 
it won't blink anymore until the kernel takes over, but that's also a 
nice information to have. Anyway, I'm not sure this is actually possible 
with the LED_BOOT feature though one should be able to do this by 
specifying the label of an LED node to fetch from DT and then calling 
led_set_period(dev, period_ms); followed by led_set_state(dev, 
LEDST_BLINK); in a board file, but this is also not so nice as it then 
also requires some C board-specific code in U-Boot.

In U-Boot, only LEDs which have a "default-state" properties will be 
auto-configured, otherwise one needs to control them manually (e.g. via 
the `led` CLI command).

If one wants to detect via an LED the current boot stage (U-Boot 
reached, kernel started), then we need to NOT use LED_BOOT feature and 
have U-Boot set the "boot" LED the opposite state than the default HW 
state, i.e. if the LED is on without any running SW (power applied to 
the device, empty boot media), then U-Boot should set it to off. Then 
the kernel simply needs to start the heartbeat mode whenever ready. If 
the default HW state is off, then U-Boot should set it on. I haven't 
looked into the kernel side of things, but there could be a window 
during which default-state property is applied before the heartbeat is 
actually started.

The logic exposed in the previous paragraph should provide visual cues 
on the current boot stage.

Note that LEDs with linux,default-trigger = "pattern" (with 
default-state property) will be blinking once auto-configured in U-Boot 
as well according to my reading of the led-uclass.c.

Hope this helps.

Cheers,
Quentin