faft: Identify the TestFail of firmware failed to auto-boot USB
On dev mode, USB inserted, triggering recovery will directly boot into USB.
However, we saw some TestFails that firmware failed to auto-boot USB.
Repluging the USB can help. This firmware mis-behavior should be identified
and report correctly. This CL tries to do so.
BUG=chromium-os:23309
TEST=on the firmware which failed to directly boot into USB, run:
$ run_remote_tests.sh --board link --remote dut RecoveryButton/control$
...
14:57:33 INFO | Server: Client machine is offline.
15:01:42 INFO | wait_for_client() timed out.
15:01:42 INFO | Try to retrieve recovery reason...
15:01:52 INFO | Setting usb_mux_sel1 to servo_sees_usbkey
15:02:02 INFO | Setting usb_mux_sel1 to dut_sees_usbkey
15:02:29 INFO | Server: Client machine is up.
...
15:02:45 INFO | Server: Relaunched remote faft.
15:02:45 INFO | Got the recovery reason 193.
15:02:45 INFO | calling <bound method firmware_UserRequestRecovery.crossystem_checker of <firmware_UserRequestRecovery.firmware_UserRequestRecovery object at 0x113fdd0>> with args ({'recovery_reason': '193', 'mainfw_type': 'recovery'},)
15:02:45 INFO | Try cold reboot...
...
Change-Id: I1fd6a157e901fb3bc2f720b767444936f1b9510e
Reviewed-on: https://gerrit.chromium.org/gerrit/37003
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
1 file changed