As Cr50 becomes more prevalent, it makes sense to make it as easy as possible for "users" (i.e., developers/vendors/etc. who are not regular developers of the Cr50 codebase) to deal with it. Common tasks are as simple as checking what firmware is installed/running, and updating the Cr50 firmware from an otherwise working system [1].

Currently, the steps are something like this:

initctl strop trunksd 
usb_updater -s /opt/google/cr50/firmware/cr50.bin.prod
reboot  # <= this is not going to be necessary in general case.

This has a few deficiencies, as noted in tangentially-related bugs [2]:
(a) we don't always (ever?) talk to Cr50 over USB, so 'usb_updater' is not a logical name (i.e., harder to discover, or remember)
(b) the path to the relevant cr50.bin.* is not obvious
(c) talking to the /dev/tpmX device requires special knowledge of which daemon owns the device currently (i.e., trunksd) and whether/when to kill it

It seems that more of this could be handled automagically to make non-experts' lives easier. For one, a quick browse of /etc/init/cr50-update.conf looks like it encodes some of the logic for resolving (b) for us -- it parses whether to try a .dev or .prod image. 

There was some mention of rolling some of this magic sauce into chromeos-firmwareupdate, but there are likely good reasons not do this (e.g., rollback isn't supported, so this can't be tested the same way as other firmware updates).

As Philip noted on [2]:

"I recalled a month ago cr50 team did discuss about refactoring some cr50 features out of 'usb_updater' to be 'cr50tool'."

So TL;DR: can we consider something like a 'cr50tool'?

[1] i.e., from the host. Flashing via external cable is an extra level of difficulty and shouldn't be required often.

[2] https://buganizer.corp.google.com/issues/64284664