[PATCH 10/11] sam9x60-curiosity: migrate Boot LED setup to use /options/u-boot/boot-led

[Quentin Schulz]

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 <quentin.schulz at cherry.de>
>>
>> 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 <ada at thorsis.com>
> 

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