You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Power On keyword consistently causing problems: #578 #603
And probably there are more occurrences in the past.
Describe the solution you'd like
Many platforms have a power LED exposed on a front panel header, which could be used to determine if platform has been/is powered or not. Some platform have the LED on 3.3V level some on 5V level. OrangePi Zero woudl have to be checked against 5V tolerance on the pins.
It would look like this: the "+" pin of the power LED would be connected to a fixed GPIO input on RTE. Tests or libraries would read the GPIO state to confirm the platform power state after powering it on.
Platforms known to have front panel header with power LED: Protectli, MSI, PC Engines apus (on COM2 header there is 5V and 3V), ODROID H4 (EXTHEAD 3.3V_RUN_H), OptiPlex (LPC_DEBUG header or service mode jumper).
Where is the value to a user, and who might that user be?
3mdeb testers. Tests will be more reliable and less likely to fail, which essentially means less effort needed for testing.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Implementing Dasharo/osfv-scripts#69 may be also a good first step here, to drop the logic from tests and leave it in a single place in Python code to fully control power of the board.
Seems to have been done here. Now, I'm working on implementing the LED check as osfv_cli rte pwr check_led.
The check gets called at the end of the Power Cycle On keyword - if the LED doesn't light up, it tries to push the power button again. If it still doesn't light up, the keyword fails prompting the tester to verify the setup manually.
an LED checking command to osfv_cli: osfv_cli rte pwr check_led
an OSFV keyword: Rte Check Power Led.
So far I've prepared the pin connections and tested the keyword on VP66XX, VP32XX, VP46XX, VP1X10 and MinnowBoard Turbot, need to add Odroid to the list. Also works on APU platforms using this branch.
The problem you're addressing (if any)
Power On keyword consistently causing problems:
#578
#603
And probably there are more occurrences in the past.
Describe the solution you'd like
Many platforms have a power LED exposed on a front panel header, which could be used to determine if platform has been/is powered or not. Some platform have the LED on 3.3V level some on 5V level. OrangePi Zero woudl have to be checked against 5V tolerance on the pins.
It would look like this: the "+" pin of the power LED would be connected to a fixed GPIO input on RTE. Tests or libraries would read the GPIO state to confirm the platform power state after powering it on.
Platforms known to have front panel header with power LED: Protectli, MSI, PC Engines apus (on COM2 header there is 5V and 3V), ODROID H4 (EXTHEAD 3.3V_RUN_H), OptiPlex (LPC_DEBUG header or service mode jumper).
Where is the value to a user, and who might that user be?
3mdeb testers. Tests will be more reliable and less likely to fail, which essentially means less effort needed for testing.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: