Hi Christian,
On 6/5/24 9:21 PM, Christian Marangi wrote:
This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something.
This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover.
There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on.
A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink.
I haven't used it yet but we do have a cyclic framework now for things happening in the background. I think this is a good use-case for this framework? Something would set the blinking frequency (could be from CLI directly, or as part of board files, or architecture, etc...) and the LED would just blink then. This would allow to highlight stages in the boot process, though that is not like an activity LED so if you're stuck in a stage, you wouldn't know if something is still happening or if you're really stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it would be way less intrusive than patching all commands that could make use of that LED. Right now, this only adds support to MTD, SPI and TFTP, but what about MMC, NVMe, USB, other net stuff (e.g. wget), etc...
Cheers, Quentin