On 22/05/17 13: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.
Agree. I remembered something about trying to converge on the default kernel settings (that's partly that's why I didn't expend too many words on the kernel section).
Actually I was a little supprised to see my hikey(620) come up without a heartbeat...
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.
Sounds good although I wonder if that train already left the station?
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..
Difficult as in "oh no, we have to carry round even more LK patches" or "oh no, all that GPIO hangs of something we don't have a driver for"?
Daniel.
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