On 22/05/17 13:35, Haojian Zhuang wrote:
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.
At this point I should admit I mus-remembered the spec (the diagram in the spec numbers the lights from 0-3 not from 1-4).
Currently I think Hikey performs as above if you subtrace 1 from all the numbers ;-) .
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?
I don't really see any need for the bootloader to hand over with all LEDs off.
Actually users are often very bad at describing intermediate phases of boot. Thus if we want to attach a change of state to the "I tried to load the kernel" event then I would prefer we turn the second LED on rather than turn the first one off. Thus we get a useful combination of lights if the kernel fails to boot (assuming the kernel has drivers enough to turn the lights off again).
Basically, it's easier to "trust" a user who reports the board is stuck and these LEDs are on because it is unambiguous. Some users so humble that they describe the light on/off sequence in an unconvincing manner (they are worried their problem might be due to a mistake on their part and so somehow convey the impression that they might be watching it wrong)!
Daniel.