On 2017/5/22 20:18, Nicolas Dechesne wrote:
hi Daniel,
On Mon, May 22, 2017 at 1:37 PM, Daniel Thompson daniel.thompson@linaro.org wrote:
Hi Folks
I've ended up talking to a few people recently about LEDs.
CE and EE have four user lights which are often hooked up in different ways on each board.
good to bring that up (again). It's been discussed several times in the past, but i don't think there is any good conclusion as of yet...
Are there any common recommendations about default LED hook ups for the kernel (e.g. USR1 -> heartbeat, USR2 -> disk I/O, etc)?
I will try to find the old thread.. but the overall agreement was: LED1 -> heartbeat LED2 -> on board storage i/o LED3 -> SD card i/o LED4 -> free/available
At some point, we talked about adding that as recommendations in the specs, iirc. Maybe Amit will remember more on this topic.
We also discussed about calling the LED with the same name in DTS so that all LED appear at the same place in /sys/class/led for all 96boards which would be good.
Similarly it might be useful to have a couple of events nominated where we recommend a firmware level bootloader[1] change LED status. Some examples:
- Set USR1 on when bootloader starts up (a NOR/eMMC/SD is not empty light).
- Set USR3 on when entering fastboot mode (if supported)
- Set USR3 off when leaving fastboot mode, including via "fastboot boot" (if supported)
- Set USR1 off and USR2, 3 and 4 on if bootloader panics.
This might be a good idea. Might be difficult in the QCOM case, but that's a separate issue, and it shouldn't prevent any discussion..
I like this idea. And I have a few comments.
If bootloader boots kernel, should USR1 keep on or off?
Especially for CE board (where users often don't have a UART adapter) even the above simple hints that the bootloader has been fetched from somewhere is useful.
I know this can't be a rule, only "good advice" (like asking CE boards to put console on LS-UART1 if possible). However, is there any appetite to converge for the boards we have influence over?
Yes, I think so.
Daniel.
[1] Here I definitely mean EDK2 rather than grub. If we have multiple chained firmware level bootloaders (e.g. LK -> u-boot) things are less clear although, as it happens, if *both* implemented the above proposal the results would still be perfectly useable from a user perspective.
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev