Using R60-9592.84.0 reef image also shuts down when it gets to  "invoke: flashrom -p ec --fast-verify -w ec.bin"

The NextAction date has arrived: 2017-08-31

The NextAction date has arrived: 2017-09-01

The NextAction date has arrived: 2017-09-05

When imaging the device manually (with the battery unplugged, directly powered), after invoking:

> chromeos-firmwareupdate --mode=factory

the device shuts down on it's own after the

> flashrom -p ec --fast-verify -w ec.bin

subcommand. The device will not restart until power supply is unplugged and plugged back in. After a few seconds the device will boot. Obviously the deployment script can't accommodate this process.

It isn't possible to flash the EC without a battery on devices that use Type-C TCPC mux devices as the mux chips will be reset during the update and you will lose power to the device.

This includes all apollolake and kabylake devices, and likely any other devices built this year.

If the DUT is deployed with the battery installed, then it will pass that obstacle, but fail later in the deployment script when it needs to boot to the servo image via USB. Log attached below. This can be manually cheated, but I don't think that is the right approach.

https://paste.googleplex.com/4864909439401984

From the cited logs:
> 2017-09-08 11:29:15 | DEBUG      | Running (ssh) 'crossystem disable_dev_request=1' from '_install_and_update_afe|_install_test_image|_install_firmware|run|wrapper|run_very_slowly'
> 2017-09-08 11:29:21 | DEBUG      | [stderr] VBNV is uninitialized
> 2017-09-08 11:29:21 | DEBUG      | [stderr] waitpid() or mosys error

This looks suspicious to me.

In any event, when update via servo fails to boot from USB, the next
step in troubleshooting is to take the USB stick from servo, and try
to boot from in manually in recovery mode:
  * Power off.
  * Power on with the three-finger salute.
  * DUT should present the "Chrome OS is missing or damaged"
    screen.
  * Insert the USB stick.
  * DUT should boot from USB.

If the procedure above works, there's something wrong with servo,
or the servo software.  If the procedure fails, there's something
wrong with the DUT, the USB stick, or the firmware.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.