Hi Alex,
On 11/13/25 9:44 AM, Alexander Dahl wrote:
Hello Quentin,
thanks for your effort. I'm all in for common behaviour.
See more remarks below.
Am Wed, Nov 12, 2025 at 06:48:15PM +0100 schrieb Quentin Schulz:
From: Quentin Schulz <[email protected]>
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Well, I introduced it back in 2023 with commit 1818b44b7bc ("board:
sam9x60-curiosity: Let LED subsystem init leds if enabled"), maybe
because I found the old property in the documentation?
Not sure since when CONFIG_LED_BOOT and the new property is a thing,
but I have no hard feelings here.
https://github.com/devicetree-org/dt-schema/commit/3033f0b3479760db047fd58f38ed777dc7e2a856
for the new property, that is, a year ago, so pretty new :)
914fd75a5d2f ("led: implement LED boot API") for the first commit for
LED_BOOT, about a year ago as well.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
Fine. Using specified properties and having less board code are both
good things!
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Would be nice to hear the opinion of someone from Microchip for this?!
These properties did not gain adoption on their new boards. It's a
bit dissapointing their boards are not maintained in mainline U-Boot
by themselves anymore. :-/
Note that this is not tested as I do not own this device.
Tested-by: Alexander Dahl <[email protected]>
Thanks!
Note: With CONFIG_LED_BOOT enabled, the LED turns to on in a later boot
phase as with that option disabled. I don't think this is a problem,
just wanted to share the observation.
Mmmmm... Yes, so the board-specific LED thing for this board is done in
board_init() which is very early in the list of callbacks called after
relocation (c.f. initcall_run_r() in common/board_r.c). The generic
support is done in initr_boot_led_on() which is essentially the last
callback before U-Boot enters the main loop. It will blink (but maybe
doesn't have time to actually blink) for the time it takes the few
callbacks between that and initr_boot_led_blink() a few callbacks earlier.
It's still in the same phase (that is the U-Boot phase, e.g. TPL, SPL,
U-Boot proper, before/after relocation), but much later in the boot
process. I'm not sure why it's so late in the boot process except that
blinking probably requires some sort of timer (or whatever CYCLIC is
using under the hood) that needs to be enabled before being able to blink.
If this is an issue, I **think** we could simply call led_boot_on() in
board_leds_init() when CONFIG_IS_ENABLED(LED_BOOT) is true, but I'm not
sure if everything's in place for uclass and DM.
Cheers,
Quentin
