What does "not usable" mean for you? Not shown at all? Doesn't respond to keyboard events? ...

Maybe after ten seconds the background is shown, and then after three more seconds the accounts are shown, and I am able to enter a password or select a different account.

Sounds like a legit problem.

I assume this happens after a powerwash too (I don't think there's much one can do as a user to slow down boot to the login prompt so much).

Any chance you can submit feedback? (Hamburger menu on the top right -> Help -> Report an issue?

+bccheng

I can test a powerwash next week. I believe, there is a way to upload logs too, right? Maybe I figure that out too, and provide these.

I believe that Ryan is tasked with finding an owner here.  Performance graphs that I see do show some regression in boot time, but nothing I can see shows 13 seconds.

One thing I'd be curious about: do you have an SD card inserted or anything connected via USB?  

NOTE: logs will be uploaded if you submit feedback (see @4).  Ideally put in a tag like @ bug780817  or something like that so that the feedback can be found more easily.

> One thing I'd be curious about: do you have an SD card inserted or anything connected via USB?

No, nothing is connected.

Ben, will your team be able to help investigate this?

Ben: is your team interested in digging into this?  If not, let's find another owner.

https://chromeperf.appspot.com/report?sid=8f4f5c868de3ddd9e89a843476db94ba6c5aa8d994ab0244997ae30e1956beb5

Vovo could you take a look?

https://chromeperf.appspot.com/report?sid=c22f4f6bb226f77f98e506e49901114d72fd74f37f5503605dc5ac9d97f6accf

veyron_tiger, veyron_minnie, veyron_mighty, veyron_jerry, veyron_jaq have this regression between R63.10019.0.0 and R63.10020.0.0 .

@13: there's certainly nothing that looks relevant in:

https://crosland.corp.google.com/log/10019.0.0..10020.0.0

...any chance that they swapped out USB Ethernet adapters in the lab on this date?  I think they've been slowly replacing them in an attempt to get things more consistent.

---

Of course, that also wouldn't explain the original report here which talks about slow boot times on R62.

...speaking of the original report, I still haven't seen any actual logs and nothing in the test lab shows a boot time of anywhere near 13 seconds.  We may have regressions to track down, but it seems like we may be tracking down things unrelated to the original bug report.  If we want to have any chance of tracking down the original bug then we need logs.

@13: One other note is that:

https://crosland.corp.google.com/log/10020.0.0..10021.0.0

...shows a whole pile of ext4 backports to kernel 3.14.  I wouldn't be at all insane to guess those could have caused a performance regression.  ...but that doesn't quite line up with the version numbers you identified...

https://chromeperf.appspot.com/report?sid=dc75cae941a702d1d34da557bbc00b58cd7cddb32f665d2b09686c10a4b01269&start_rev=31990000989000000&end_rev=32120000994100000

veyron_minnie, veyron_mighty, veyron_jerry, veyron_jaq have boot time regression between R62.9901.41.0 and R62.9901.42.0

https://crosland.corp.google.com/log/9901.41.0..9901.42.0
https://crosland.corp.google.com/log/10019.0.0..10020.0.0

The common CL in the previous ranges is "Add infineon-firmware ebuild":
https://chrome-internal-review.googlesource.com/c/chromeos/overlays/chromeos-overlay/+/437852

I will check if this CL caused the regression.

The regression of veyron_jaq seconds_power_on_to_login on lab is from 9.6 secs to 10.1 secs on R62.9901.42.0.

Applying CL https://chrome-internal-review.googlesource.com/437852 on veyron_minnie R63.10019.0.0 increased platform_BootPerfServer seconds_power_on_to_login from 9.89 secs to 10.51 secs.

mnissler@ , could you take a look?

Here are the debug logs from my device.

Deleted: debug-logs_20171113-200806 5.6 MB

debug-logs_20171113-200806 5.6 MB View Download

Sorry, this fell through the cracks, only found it now. It's well possible that my change caused the regression. I'll have to dig some more to figure out what exactly is slow and what can be done avoid the regression. I hope to spend some cycles on this next week, but I'm travelling the second half of the week, so it might be a while.

Quickly timed tpm-firmware-update.sh on a different device (link), but in the same scenario as reported: the update exists, but the tpm is owned (exit code = 6):
  time /usr/share/cros/init/tpm-firmware-update.sh

I get between 320 and 350ms of real time.

[Running under dash doesn't change much:
  time (dash /usr/share/cros/init/tpm-firmware-update.sh)
It adds 10-15 ms (probably just for staring dash) and brings the time to 330-365ms.]

Seems consistent with the reported ~500ms regression (the timing may be particularly bad on veyron).

Calling just the updater:
  time /usr/sbin/tpm-firmware-updater 2>&1
takes between 235 and 255ms

[Running with -x under dash adds ~30ms:
  time (dash -x /usr/sbin/tpm-firmware-updater)
results in 265-285ms. Not a game changer, given that 10-15 of that is just from starting dash. So, the extra 15-20ms comes from being verbose.]

I also timed the external operations performed by the update script in this scenario:
time (tpmc getversion; tpmc ifxfieldupgradeinfo; tpmc getownership; crossystem mainfw_type)

I get between 125 and 145ms for that, or less than 60% of the updater time. [with getversion/getownership taking 30-40ms, ifxfui taking 60-70ms, and crossystem taking ~0] We can probably reduce it further, if we combine all tpmc requests into a single call.

But overall, seems it's not a single lengthy external operation but rather a death from thousand cuts - all the parsing of output and processing the conditions in the script itself.

For example, timing (date +%T.%N) read_key_value_pair() functions on one of the runs shows that we spend ~150ms (or more than it takes to actually query the tpm) parsing tpmc output, with >100ms coming from parsing a lengthy tpmc ifxfui output. Here it is:

read_key_value_pairs tpmc_version
+ dlog DBG: read_key_value_pairs start 11:01:30.579460521
+ dlog DBG: read_key_value_pairs end 11:01:30.601951113

read_key_value_pairs tpmc_ifxfui
+ dlog DBG: read_key_value_pairs start 11:01:30.668852991
+ dlog DBG: read_key_value_pairs end 11:01:30.778374969

read_key_value_pairs tpmc_version
+ dlog DBG: read_key_value_pairs start 11:01:30.780726309
+ dlog DBG: read_key_value_pairs end 11:01:30.802508656

Probably it makes sense to come up with a special tpmc command that returns only what we actually need and returns it in script-friendly format that simplifies/eliminates parsing (e.g. tpmc just sets it in env variables itself). Doing that could reduce 130+150 seconds spent on tpmc+parsing to something like 100+0, shaving ~150ms off the time.

Plus, it's also interesting what updater.sh does for almost 100ms outside of the updater.

Of course, it should be noted, that if the user upgrades firmware on that device, in the current situation the time should go down to the same values as if CL:437852 is not applied. That CL adds firmware upgrade images that match the current tpm f/w revision. Thus the f/w is upgraded, they will stop matching, so the search for image will fail - same as when they are simply not there pre-CL:437852.

Combining all checks into a single tpmc command as suggested in comment #24 would improve performance for the non-upgraded tpm f/w scenario. But it will actually hurt performance for the upgraded f/w scenario. In that case we do just tpmc getversion + read_key_value_pairs (50-60ms now) and bail out after finding no match for the version. A combined tpmc command would likely need more that 50ms (e.g. 100ms as I guesstimated in comment #24), since it will have to send several tpm commands.

But assuming that the majority will likely NOT upgrade tpm firmware, improving performance for the 1st path still makes sense. And we should actually implement & measure, of course, in any case. All this is just guesswork for now.

Looked at this on veyron_minnie before reading Andrey's comments, and I independently come to the same conclusion. timing /usr/share/cros/init/tpm-firmware-update.sh takes around a second. One notable slow thing is creating namespaces (this happens when we invoke minijail).

Anyhow, the conclusion here is that we need to move this stuff of the hot path. Per an offline discussion with apronin@, the plan is to:

1. Gate the updater to run on the critical path only if there is a flag file that indicates we should perform a firmware update.
2. Move all other processing (determining whether there's an update available or not) to a point after login-prompt-visible. Options:
  a) Keep the script mostly as is and run it before starting tcsd.
  b) Move the logic to determine whether and which firmware update image to install to C++ and rely on tcsd. This is somewhat complicated by the fact that the recovery image needs to be able to do the same thing and tcsd is not running there. Keeping two versions of the code is unfortunate though. Maybe we can produce something code that can link against tlcl or trousers?

Bottom line - we'll fix this, but need to think more about the best way to do so.

OK, after some more pondering, here's a rough plan:

1. Break the logic to determine whether there's an update out into a separate script that consumes the version information and IFX firmware upgrade info data.
2. Run the new update availability checking script late during boot, after starting tcsd to determine whether to offer the update in the UI.
4. When running the update availability checking script from tpm-firmware-updater, we can use tpmc getversion and tpmc ifxfui as is.
5. When running the update availability checking script later during boot, tpm-manager get_version_info already supplies all data on versions that we require. We'll need to add support for IFX firmware upgrade info, which shouldn't be too hard.
6. Change the tpm-firmware-update.sh script to only invoke tpm-firmware-updater if there's flag file on disk. This flag will replace the existing "mode" parameter in VPD. This is also useful to address other issues, i.e. issue 	768342 will be fixed by this, and the stateful preservation logic can also check the flag first before it does anything that adds latency in the boot path.

Andrey, does this make sense to you?

Thinking more about this: Implementing IFX firmware upgrade info support in tpm-manager is somewhat difficult - we'd have to add support for that command in trousers as well. An alternative could be to run tpmc ifxfui and capture the output just before starting tcsd. I've timed this on veyron_minnie, and it clocks in at 100ms... That's quite slow actually, so we might have to bite the bullet.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/trousers/+/b511e950e8a70d59251eb360a38a91d4ec96191b

commit b511e950e8a70d59251eb360a38a91d4ec96191b
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed Feb 07 23:04:07 2018

Expose the FieldUpgrade command.

Fill in gaps in FieldUpgrade handling to allow client code to issue
FieldUpgrade commands via the tcsd socket. Note that this only
supports unauthenticated FieldUpgrade commands, which is sufficient
for the IFX FieldUpgradInfoRequest2 use case that motivates this
change.

BUG= chromium:780817 
TEST=Manual: tpm-manager get_ifx_field_upgrade_info

Change-Id: I48b1818fa911413e28f4c4f14cc0308fe2a8067b
Reviewed-on: https://chromium-review.googlesource.com/822338
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/include/rpc_tcstp_tcs.h
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tspi/tspi_admin.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tcs/rpc/tcstp/rpc_admin.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tcs/tcsi_admin.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/include/tss/tspi.h
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tspi/rpc/tcs_api.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tcs/rpc/tcstp/rpc.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tcs/tcs_pbg.c
[modify] https://crrev.com/b511e950e8a70d59251eb360a38a91d4ec96191b/src/tspi/rpc/tcstp/rpc_admin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e

commit 8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed Feb 07 23:04:06 2018

cryptohome: IFX field upgrade info in tpm-manager

Add a new get_ifx_field_upgrade_info command in tpm-manager that
retrieves field upgrade status parameters for Infineon TPMs via
trousers.

BUG= chromium:780817 
TEST=Manual: tpm-manager get_fix_field_upgrade_info
CQ-DEPEND=CL:822338

Change-Id: I60a96c2685f3b6dd52f6a74b4546863841d919c4
Reviewed-on: https://chromium-review.googlesource.com/822339
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm_manager_v1.cc
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm2_impl.cc
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm_impl.cc
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm_manager_v2.cc
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm2_impl.h
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm_impl.h
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/stub_tpm.h
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm_manager.cc
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/mock_tpm.h
[modify] https://crrev.com/8ac77b7bb6a2e46d7e78755f3dc0cebf7c84f01e/cryptohome/tpm.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/9b302444d0018da9b8223763638d8db064b94041

commit 9b302444d0018da9b8223763638d8db064b94041
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed Feb 07 23:04:08 2018

cryptohome: Adjust tpm-manager get_version_info output

This changes the format of the printed information to coincide with
the output of tpmc getversion. This is useful so the output can be
used interchangably in scripts.

BUG= chromium:780817 
TEST=Builds.

Change-Id: I1e282a2b8f79aeb6c260fd8089db3194a87ca751
Reviewed-on: https://chromium-review.googlesource.com/824608
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/9b302444d0018da9b8223763638d8db064b94041/cryptohome/tpm_manager.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/978c09fb14e328835bde6f08e69ba2047a3042a7

commit 978c09fb14e328835bde6f08e69ba2047a3042a7
Author: Mattias Nissler <mnissler@chromium.org>
Date: Thu Feb 08 17:24:03 2018

infineon-firmware-updater: Break out availability check.

This change separates the code that examines TPM state and available
firmware update binaries on the root file system into a separate
script. This allows to run the check whether an update is available to
run later in the boot process in preparation to fix a boot time
regression.

BUG= chromium:780817 , chromium:768342
CQ-DEPEND=CL:842406,CL:824608,CL:822339
TEST=Manual

Change-Id: I9ba4602afcc7051659214e60c014cc84e8e0b75d
Reviewed-on: https://chromium-review.googlesource.com/842724
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[add] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/files/tpm-firmware-locate-update
[rename] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/infineon-firmware-updater-1.1.2459.0-r21.ebuild
[add] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/files/tpm-firmware-check.sh
[modify] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/files/tpm-firmware-updater
[add] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/files/tpm-firmware-check.conf
[modify] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/infineon-firmware-updater-1.1.2459.0.ebuild
[modify] https://crrev.com/978c09fb14e328835bde6f08e69ba2047a3042a7/chromeos-base/infineon-firmware-updater/files/tpm-firmware-updater-test

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/e0929ff6e0cddfafebf5e5718146aeea4696874a

commit e0929ff6e0cddfafebf5e5718146aeea4696874a
Author: Mattias Nissler <mnissler@chromium.org>
Date: Thu Feb 08 17:24:02 2018

login: Adjust TPM firmware update availability testing.

TPM firmware update availability is now decided asynchronously by an
init job running after the boot process is completed. This addresses a
boot performance regression where the update check running earlier did
slow down boot times. Availability is now indicated via a different
file with slightly different semantics (i.e. absence of the file only
indicates the check hasn't completed, not that no update is
available).

BUG= chromium:780817 
CQ-DEPEND=CL:842724
TEST=unit tests

Change-Id: I7f7c3c09a2151b3cd96f917669c01d1f675fdaae
Reviewed-on: https://chromium-review.googlesource.com/842406
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/e0929ff6e0cddfafebf5e5718146aeea4696874a/login_manager/session_manager_impl.cc
[modify] https://crrev.com/e0929ff6e0cddfafebf5e5718146aeea4696874a/login_manager/session_manager_impl_unittest.cc
[modify] https://crrev.com/e0929ff6e0cddfafebf5e5718146aeea4696874a/login_manager/session_manager_impl.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2a7266e6ddefff558518a19b44b2e535080d75f0

commit 2a7266e6ddefff558518a19b44b2e535080d75f0
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed Feb 14 19:50:18 2018

Generate callbacks for StubCrosSettingsProvider::PrepareTrustedValues

The contract of the function requires the CrosSettingsProvider
implementation to call back PrepareTrusteValues() consumers when in
TEMPORARILY_UNTRUSTED state. StubCrosSettingsProvider now implements
this behavior so tests observe more accurate behavior.

BUG= chromium:780817 
TEST=None

Change-Id: I31542123f78d901e93a30256c81e1ba8f71d8fe0
Reviewed-on: https://chromium-review.googlesource.com/840011
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536782}
[modify] https://crrev.com/2a7266e6ddefff558518a19b44b2e535080d75f0/chrome/browser/chromeos/settings/stub_cros_settings_provider.cc
[modify] https://crrev.com/2a7266e6ddefff558518a19b44b2e535080d75f0/chrome/browser/chromeos/settings/stub_cros_settings_provider.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14b5618d8e24b89f1d64f0d5424268559febb660

commit 14b5618d8e24b89f1d64f0d5424268559febb660
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed Feb 14 22:17:48 2018

Chrome OS powerwash: Rework TPM firmware update test.

To fix a boot time regression, TPM firmware update availability is now
decided asynchronously after the system has booted up. This creates a
race condition where the file exposed by the system to indicate update
availability might not be present immediately after boot but the
powerwash dialog is already visible. To address this, change the code
to (1) show the TPM firmware update checkbox immediately if an update
was previously requested and (2) use a FilePathWatcher to wait for the
update availability decision.

BUG= chromium:780817 
TEST=Reboot-to-powerwash-with-TPM-firmware-update flow shows checkbox.

Change-Id: Ibd68ca5a94b5594931c258c8951e499e84a70fdd
Reviewed-on: https://chromium-review.googlesource.com/840012
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536845}
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/chromeos/BUILD.gn
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/chromeos/login/screens/reset_screen.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/chromeos/tpm_firmware_update.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/chromeos/tpm_firmware_update.h
[add] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/chromeos/tpm_firmware_update_unittest.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/ui/webui/chromeos/login/core_oobe_handler.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/ui/webui/settings/about_handler.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/browser/ui/webui/settings/browser_lifetime_handler.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/common/chrome_paths.cc
[modify] https://crrev.com/14b5618d8e24b89f1d64f0d5424268559febb660/chrome/common/chrome_paths.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/0f991ee1388709951276efd0faf402dc4cc50cd6

commit 0f991ee1388709951276efd0faf402dc4cc50cd6
Author: Mattias Nissler <mnissler@chromium.org>
Date: Sat Feb 17 02:47:30 2018

infineon-firmware-updater: Trigger via flag file.

Remove the mechanism that stored user consent in VPD and instead
consider invocation of the script sufficient evidence that we actually
want to install a TPM firmware update if possible. This allows a quick
check in the init script, thus reducing perf impact to the absolute
minimum for the case where there is no update.

BUG= chromium:780817 , chromium:768342
CQ-DEPEND=CL:860379,CL:824609
TEST=unit tests

Change-Id: Ib378c9b2740ae8b7d469b7952003cd89e280d89b
Reviewed-on: https://chromium-review.googlesource.com/857496
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/0f991ee1388709951276efd0faf402dc4cc50cd6/chromeos-base/infineon-firmware-updater/files/tpm-firmware-update.sh
[modify] https://crrev.com/0f991ee1388709951276efd0faf402dc4cc50cd6/chromeos-base/infineon-firmware-updater/files/tpm-firmware-updater-test
[modify] https://crrev.com/0f991ee1388709951276efd0faf402dc4cc50cd6/chromeos-base/infineon-firmware-updater/files/tpm-firmware-update-factory.sh
[rename] https://crrev.com/0f991ee1388709951276efd0faf402dc4cc50cd6/chromeos-base/infineon-firmware-updater/infineon-firmware-updater-1.1.2459.0-r22.ebuild
[modify] https://crrev.com/0f991ee1388709951276efd0faf402dc4cc50cd6/chromeos-base/infineon-firmware-updater/files/tpm-firmware-updater

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/1243e274bfab0146cf15cea7b1e10c296b7b8939

commit 1243e274bfab0146cf15cea7b1e10c296b7b8939
Author: Mattias Nissler <mnissler@chromium.org>
Date: Sat Feb 17 02:47:32 2018

login: Signal TPM firmware update request via flag file.

TPM firmware update requests are now indicated via a flag file
instead via the tpm_firmware_update_params value in VPD.

BUG= chromium:780817 , chromium:768342
CQ-DEPEND=CL:857496
TEST=additional unit tests

Change-Id: I303908e54a7c31fd4786556697f7655c855fcb72
Reviewed-on: https://chromium-review.googlesource.com/824609
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/1243e274bfab0146cf15cea7b1e10c296b7b8939/login_manager/session_manager_impl.cc
[modify] https://crrev.com/1243e274bfab0146cf15cea7b1e10c296b7b8939/login_manager/dbus_bindings/org.chromium.SessionManagerInterface.xml
[modify] https://crrev.com/1243e274bfab0146cf15cea7b1e10c296b7b8939/login_manager/session_manager_impl_unittest.cc
[modify] https://crrev.com/1243e274bfab0146cf15cea7b1e10c296b7b8939/login_manager/session_manager_impl.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/initramfs/+/99ffe3b908f39927843e044bccb3215b3e4fe28a

commit 99ffe3b908f39927843e044bccb3215b3e4fe28a
Author: Mattias Nissler <mnissler@chromium.org>
Date: Sat Feb 17 02:47:31 2018

recovery: Adjust TPM firmware updating decision

Change the recovery script to evaluate the conditions under which to
install a TPM firmware update itself instead of relying on
tpm-firmware-updater to do so. Doing so reflects that the decision on
whether to update is best taken by the caller, so we are more flexible
to make the decision in normal boot. Recovery behavior should be
unchanged, i.e. the new code matches the approve_update() checks in
tpm-firmware-updater.

BUG= chromium:780817 , chromium:768342
CQ-DEPEND=CL:857496
TEST=Manual: Run TPM firmware update in recovery for various situations (failed selftest mode, request by VPD, no update)

Change-Id: I3bc528843451bc6e8f2b240186adbe59fd409651
Reviewed-on: https://chromium-review.googlesource.com/860379
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/99ffe3b908f39927843e044bccb3215b3e4fe28a/recovery/recovery_init.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ab50768732698a332158c88a87c2d07ed276c701

commit ab50768732698a332158c88a87c2d07ed276c701
Author: Mattias Nissler <mnissler@chromium.org>
Date: Mon Feb 19 09:30:48 2018

Bypass reset screen eligibility check after reboot

Show the reset screen immediately if powerwash has previously been
requested before reboot. This addresses a case where the screen
wouldn't show because the pending TPM availability test
incorrectly turns the eligibility check negative immediately after
reboot.

BUG= chromium:780817 
TEST=Reboot-to-powerwash-with-TPM-firmware-update flow works for enrolled devices

Change-Id: Ia9c56a2422c70d19dc2cccea6b5fb21c62fa510a
Reviewed-on: https://chromium-review.googlesource.com/921842
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537612}
[modify] https://crrev.com/ab50768732698a332158c88a87c2d07ed276c701/chrome/browser/ui/webui/chromeos/login/core_oobe_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef8cc3eada065b3c13e867b99039f076cb015df3

commit ef8cc3eada065b3c13e867b99039f076cb015df3
Author: Mattias Nissler <mnissler@chromium.org>
Date: Fri Feb 23 09:52:22 2018

Fix propagation of TPM firmware update request flag

ResetScreen keeps a flag in local state to indicate whether a TPM
firmware update has been requested. For the case where the powerwash
UI first triggered a restart, the previous code didn't propagate the
firmware update flag, causing the TPM firmware update checkbox to not
appear after reboot. Fix the restart handler to propagate the flag
correctly.

While at it, increase the firmware update eligibility check timeout to
10 seconds, since some devices have been observed in practice to
require more than 5 seconds to finish the eligibility check.

BUG= chromium:780817 
TEST=Reboot from reset screen to invoke TPM firmware update shows TPM firmware update checkbox in reset screen shown after reboot.

Change-Id: I096b26bc5ddba87f38f5dc6efb638ba36bc50852
Reviewed-on: https://chromium-review.googlesource.com/921843
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538741}
[modify] https://crrev.com/ef8cc3eada065b3c13e867b99039f076cb015df3/chrome/browser/chromeos/login/screens/reset_screen.cc

This should be fixed now.

I can't seem to make the perf dashboard show recent data (is it just me or is the data missing for veyron boards?), so it'd be good if someone could verify.

Yes, it shows the improvements from 
https://crosbolt.teams.x20web.corp.google.com/time_series/platform_BootPerfServer/seconds_power_on_to_login.html?sku_filter=%5Efievel_%7C%5Ejaq_%7C%5Ejerry_%7C%5Emickey_%7C%5Emighty_%7C%5Eminnie_%7C%5Eminnie_%7C%5Etiger_