> Currently, device repair supports USB recovery but not reflashing corrupted firmware.

There _is_ a repair procedure that will reflash corrupted firmware.  The procedure
is only applied to FAFT devices, because those are the only ones expected to need it.

We could enable the procedure more broadly, but without more sophistication,
the result would be that any device that went offline would see its firmware
re-flashed every few hours until the device were fixed.  That could go on for
day or weeks, even months.  That would mean that some devices, after failing,
could find themselves undergoing 500-1000 (or more) extra FPROM write cycles.

Full recovery from any level of disaster can be performed by:

* extracting a good firmware firmware from a known good image through chromeos-firmwareupdate
* extracting the broken firmware from the DUT
* copying the vpd and hwid to the known good firmware using vpd -f file, gbb_utilty
* flashing the good firmware (maybe ec too) back
* booting from recovery and clearing TPM

> Full recovery from any level of disaster can be performed by:

As noted, there's existing code in Autotest that knows how to perform
all of the necessary steps to update firmware from a known good
version to a DUT using servo.  The code is in use for FAFT DUTs now.
Based on the state of existing FAFT DUTs, that update process already
preserves VPD and HWID.

To be clear:  The work required here has very little to do with code
for flashing firmware via servo:  All of the necessary pieces are
available, in use, and apparently stable.  What's needed is basically the
following:
  * Add code capable of detecting when firmware is corrupted.
  * To the standard repair flow, add a check so that if firmware is
    corrupted, it will use the existing FAFT repair procedure to install
    the lab-standard firmware version for the DUT.  Then it must invoke
    installation from USB, which already triggers recovery mode and clears
    the TPM.
  * Change the `deploy` script to trigger repair, rather than a custom
    installation flow.

The above summary is slightly simplified, but it captures the most
important work.

Planned for Q4.