P.S: the output of --manifest is JSON and looks like

{ "bip": {
    "host": { "versions": { "ro": "Google_Bip.11227.0.0", "rw": "Google_Bip.11227.0.0" },
      "keys": { "root": "b11d74edd286c144e1135b49e7f0bc20cf041f10", "recovery": "c14bd720b70d97394257e3e826bd8f43de48d4ed" },
      "image": "models/bip/bios.bin" },
    "ec": { "versions": { "ro": "bip_v2.0.285-88a949d29", "rw": "bip_v2.0.285-88a949d29" }, "image": "models/bip/ec.bin" },
    "signature_id": "bip"  }}

The output of -V is plain text like

Model:        bip
BIOS image:   310a375141367d8d970148ad3df4eaf5 */models/bip/image-bip.bin
BIOS version: Google_Bip.11227.0.0
EC image:     4476ddabb5afb95f1b473c8c8b50ca23 */models/bip/ec.bin
EC version:   bip_v2.0.285-88a949d29

Also - for Unified Build, the target selection is now done deeply inside futility because we have to look at mosys, firmware and vpd to decide target; so if what you're looking for is "exactly the (single) firmware to be installed, it'll be more difficult - we may need to integrate with --output feature.

I would look for (1) and (2) both, to be able to verify that the system is running what is expected. "What is expected" maybe "latest that updater package has to offer" or "a test version that needs to be different from the updater package". Thanks for filing this!

Sounds like a mixing of --output, --manifest and dryrun.

We should probably introduce a new mode for that.

Hung-Te, (3) may be a valid use-case for firmware developers or other people who care about firmware, so you might want to ask more. 
I care about (1) and (2) because I ended up in situations where I had to circulate trybot firmware images to test folks or other colleagues and have them check that the firmware version they were running was the trybot image and not the latest updater package. 
Having both (1) and (2) would be very useful for those cases.

+kmshelton

Here's some more background for why I'm asking.

Providing (2) or (3) are easy. In previous implementation they simply run crossystem or mosys.
However, there's some concern in trusting the results there, since what they provided were vboot data (i.e., what in boot config), which implies they are not the "real" value in system.

For example, if you boot in recovery mode, ACT: tells you the RO FWID, not A/B. This may be confusing.
Also if you have already executed firmware updater, then both RO/RW values may be different.

That's why in new futility based updater we've changed to reporting the real values in blobs, instead of mosys/crossystem values.

But if you're OK with crossystem values, I may report those data with some simple scripting in chromeos-firmwareupdate, and no need to change futility updater.

One very special value is (1).

With futiltiy update, I can easily provide you the very details of updater package. But for unibuilds, that implies "image for all". There's currently no easy way to match details about "what's going to happen" unless if we run the full process, i.e., read system firmware back and verify the mosys platform & VPD values and apply key switching. This was poorly done in legacy updater and was one of the reason we don't provide that anymore.

well, consider again, I think we can still do something easily for (1) if we ignore the key stuff (and ignore WL, which was also not really presented in the shell version).

Let me make some CLs for them.

One last thing - I think you're fine if the output format is slightly different, right?

A sample output:
  Write Protect: HW=0/0 SW=1
  Current: RO=Google_Eve.9584.131.67 ACT/A=Google_Eve.9584.131.67
  Package: {"ro":"Google_Eve.9584.107.0","rw":"Google_Eve.9584.174.0"}

CL: https://chromium-review.googlesource.com/c/chromiumos/platform/firmware/+/1377813

Revised as

  Machine Model: eve
  Write Protect: HW=0/0 SW=1
  Last Boot Firmware: RO=Google_Eve.9584.131.67 ACT/A=Google_Eve.9584.131.67
  Firmware Updater:   RO=Google_Eve.9584.107.10    RW=Google_Eve.9584.174.0

Both #11 and #13 sound great. Thanks!
Adding some other folks who've had to respin firmware many times and might have an opinion ;)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/firmware/+/f537b72ff8ecbd29b93a7c11e72abc3d4655911d

commit f537b72ff8ecbd29b93a7c11e72abc3d4655911d
Author: Hung-Te Lin <hungte@chromium.org>
Date: Tue Dec 18 08:42:57 2018

pack: sfx: Add 'report_system' even when no args(mode) specified

Before migrating to updater5, executing 'chromeos-firmwareupdate'
without any modes will report some basic system information, which was
helpful for debugging and collecting logs.

Here we'd like to introduce some minimal support in new updater.
A sample output:

  Machine Model: eve
  Write Protect: HW=0/0 SW=1
  Last Boot Version: RO=Google_Eve.9584.131.67 ACT/A=Google_Eve.9584.131.67
  Firmware Updater:  RO=Google_Eve.9584.107.11    RW=Google_Eve.9584.174.0

BUG= chromium:914671 
TEST=chromeos-firmwareupdate

Change-Id: I717e6388d88f7f881799de5a0b8e91f7d5edb108
Reviewed-on: https://chromium-review.googlesource.com/1377813
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>

[modify] https://crrev.com/f537b72ff8ecbd29b93a7c11e72abc3d4655911d/pack/sfx.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/firmware/+/b2c29757b90133e8e6315800a1afdeafe4a2bc5a

commit b2c29757b90133e8e6315800a1afdeafe4a2bc5a
Author: Hung-Te Lin <hungte@chromium.org>
Date: Fri Jan 18 04:20:25 2019

pack: sfx2: Add 'report_system' from SFX v1

The SFX2 needs same usage as SFX v1 (CL:1377817).
A sample output:

  Machine Model: eve
  Write Protect: HW=0/0 SW=1
  Last Boot Version: RO=Google_Eve.9584.131.67 ACT/A=Google_Eve.9584.131.67
  Firmware Updater:  RO=Google_Eve.9584.107.11    RW=Google_Eve.9584.174.0

BUG= chromium:914671 
TEST=chromeos-firmwareupdate

Change-Id: Ic6602c3ce202582d6c1db80fa9074548b257d11d
Reviewed-on: https://chromium-review.googlesource.com/1390023
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>

[modify] https://crrev.com/b2c29757b90133e8e6315800a1afdeafe4a2bc5a/pack/sfx2.sh