what tpm2 version are you running?

Is factory image brought up by the RO path in firmware? If not - the platform authorisation is disabled so nvram spaces can not be modified.

IIUC developer mode is not sufficient, you need recovery mode.
Kernel and firmware indexes are only writeable when platform hierarchy is enabled, and firmware disables it unless in recovery mode.
And it should: you shouldn't be able to rewrite firmware and kernel version indexes - even though it's dev mode, the anti-rollback protection should still work (or that's my understanding).
So, for non-recovery mode these errors are expected. 

> what tpm2 version are you running?
 Can you provide the right command to get this info?

> Is factory image brought up by the RO path in firmware?
 Yes. As indicated in the description, we boot it by recovery mode (esc-F3-Power).
 I can clear TPM1 in same step so authorisation should be fine.

 However, we did try to prevent tcsd running for TPM1, but we haven't stop trunksd before running chromeos-tpm-recovery. Not sure if that's the reason.

the latest chromes-tpm-recovery as of this patch in ToT https://chromium-review.googlesource.com/#/c/407796/ will stop trunksd/tcsd as required, so it is odd that it is failing in your case.

You can determine the running tpm version by executing 'usb_updater -f' after stopping trunksd.

Re #4: it did stop trunksd (and then successfully restarted it), based on the log in description. The errors are from tpmc write failing. And that's due to platform authorization being disabled.

When doing TPM1, we had a rule that "tcsd can't be executed since it'll lock TPM; i.e., stopping tcsd won't help". So factory shim did try to disable tcsd so it's never executed before we run tpmc write.

Does that apply to trunksd & TPM2?

Trunksd doesn't disable tpm. And I doubt tcsd did. As long as it is running (tcsd or trunksd), nobody can access /dev/tpm0 and send commands to tpm. That's true. But stopping it if it runs should be fine. And the original version of the script also just stopped tcsd if it was running.

In terms of nvram indexes access that you need in this script, it's not trunksd/tcsd that disable access to them, it's the firmware (see below). It was so for 1.2, it is still so for 2.0.

But in this case, based on the log, trunksd _was_ stopped successfully. 'tpmc write' failed not because trunksd or tcsd was running, but because the system was in the state (non-recovery mode) when writing to these indexes is not allowed. Only fw can write to them using storm authorisation. And fw disables platform authorization that is req'd for such writes before passing control to kernel (unless, again, it runs in recovery mode).

Oh, I got it. It is chromeos-tpm-recovery that dies stop trunksd.
Whatever script is run when you press 'i' in recovery image apparently doesn't stop trunksd. That should be fixed.

Two line after usb_updater -f:
open_device 18d1:5014
can't find device

this is on reef I presume. Do you have suzy-q connected to the device by any chance? It should not be plugged in.

tpm_version:
  TPM 2.0 Version Info:
  Chip Version:        2.0.0.0
  Spec Family:         322e3000
  Spec Family String:  2.0
  Spec Level:          0
  Spec Revision:       116
  Manufacturer Info:   43524f53
  Manufacturer String: CROS
  Vendor ID:           xCG fTPM
  TPM Model:           00000001
  Firmware Version:    0de0f53a007ec984

Can you please run
initctl stop trunksd
tpmc getpf
tpmc getvf
initctl start trunksd
to see what's going on with the hierarchies?

This is Gru, and didn't connect any suzy-q.

tpmc getpf:
ownerAuthSet 0
endorsementAuthSet 0
lockoutAuthSet 0
disableClear 0
inLockout 0
tpmGeneratedEPS 1

tpmc getvf:
phEnable 1
shEnable 1
ehEnable 1
phEnableNV 1
orderly 1

the -s command line flag is missing in usb_updater invocation, it is necessary on gru.

While that CL that supports 'getp' hasn't landed yet, can you please run the following raw commands to read the public areas for those indices:
# tpmc raw 80 01 00 00 00 0e 00 00 01 69 01 00 10 07
# tpmc raw 80 01 00 00 00 0e 00 00 01 69 01 00 10 08

Also, please try
# tpmc raw 80 02 00 00 00 24 00 00 01 37 40 00 00 0c 01 00 10 07 00 00 00 09 40 00 00 09 00 00 00 00 00 00 01 01 00 00
(that's equivalent to writing 1 byte to firmware index = 'tpmc write 0x1007 01')
I want to see what error code you get in the raw response.

And the same for index 0x1008:
# tpmc raw 80 02 00 00 00 24 00 00 01 37 40 00 00 0c 01 00 10 08 00 00 00 09 40 00 00 09 00 00 00 00 00 00 01 01 00 00

quick update. I just borrowed a reef and chromeos-tpm-recovery happily works correctly, without errors. So this is probably a gru-specific issue?

"usb_updater -sf" after "initctl stop trunksd":
start
Target running protocol version 5
Offsets: backup RO at 0x40000, backup RW at 0x4000
Keyids: RO 0x3716ee6b, RW 0xb93d6539
Current versions:
RO 0.0.10
RW 0.0.9

Re #15: four commands' error info:

request failed with code 395
command "raw" failed with code 0x18b
the TPM error code is unknown to this program
0x80 0x01 0x00 0x00 0x00 0x0a 0x00 0x00 
0x01 0x8b 
=============
request failed with code 395
command "raw" failed with code 0x18b
the TPM error code is unknown to this program
0x80 0x01 0x00 0x00 0x00 0x0a 0x00 0x00 
0x01 0x8b 
=============
request failed with code 651
command "raw" failed with code 0x28b
the TPM error code is unknown to this program
0x80 0x01 0x00 0x00 0x00 0x0a 0x00 0x00 
0x02 0x8b 
=============
request failed with code 651
command "raw" failed with code 0x28b
the TPM error code is unknown to this program
0x80 0x01 0x00 0x00 0x00 0x0a 0x00 0x00 
0x02 0x8b 

All commands, including NV_ReadPublic return TPM_RC_HANDLE error for both nvram indexes. Looks like the indexes are just not created by the firmware.
For TPM2 case, chromeos-tpm-recovery doesn't (yet - the fix is in plans) create the indexes if they don't exist. So, subsequent writes fail.

Hmm, I don't see how coreboot can not create the indexes if they don't exist at boot... Unless there were problems during tpm setup or self test. Do you have the logs from core boot? Any errors indicated there?

In any case, could you please try
# tpmc def 0x1007 0xa 0x40054001
# tpmc def 0x1008 0xd 0x40054001
And then repeat chromeos-tpm-recovery

(Please note, the provided permissions are not 100% correct for prod system, but that's as close as I can get. So, use that board for dev purposes only, and later we'll need to recover this board again, when we have up-to-date scripts for that for tpm2).

Re #20:
Stopping trunksd...
(was not running)
writing 10 bytes
space 0x1007 was recreated successfully
writing 13 bytes
space 0x1008 was recreated successfully
writing 16 bytes
command "write" failed with code 0x5008
the TPM error code is unknown to this program
writing to 0x1009 failed
could not fix backup space
TPM has successfully been reset to factory defaults

Ok, so the indexes indeed didn't exist.

This was a run of chromeos-tpm-recovery, is this right?

In this case the indices must have existed before, as this script bypasses creating spaces for tpm2.

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

commit c2e2fbeef92eb2391dbda5d4fca3eaf7bbfa9b1d
Author: Hung-Te Lin <hungte@chromium.org>
Date: Fri Nov 11 08:21:47 2016

factory_install: Call chromeos-tpm-recovery to reset TPM.

Factory Reset shim has to clear (wipe/zero) TPM NV spaces so devices
with wrong antirollback records can be recovered. However, the script
becomes more complicated due to (1) vboot changes (2) TPM2.

vboot_reference has an utility 'chromeos-tpm-recovery' that was has
more complete support of TPM recovery, although it does more (try to
re-create or even redefine the space) than what we need. To prevent
duplicating code, we should just run chromeos-tpm-recovery instead of
introducing our own implementation.

BUG= chromium:664390 
TEST=./build_image factory_install; boot as recovery mode on Link+TPM1,
     enter menu, select item "r" (Reset) or "i" (Install). Also tried
     on Reef+TPM2.

Change-Id: I7b618946c55e24e775dc6972a23b6d271455ff06
Reviewed-on: https://chromium-review.googlesource.com/410523
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>

[modify] https://crrev.com/c2e2fbeef92eb2391dbda5d4fca3eaf7bbfa9b1d/factory_install.sh

So is Gru ok? Or there's some bug in Gru firmware?

Re #24: Yes, that was run of chromeos-tpm-recovery

Re #26: I tried I(Install) on recovery mode, and got this:

Clearing NVData.
Command not supported on this platform
Warning: NVData not cleared.
Checking for Firmware Write Protect
Request to clear TPM owner at next boot.
Checking if TPM should be recovered (for version and owner)
Stopping trunksd...
done
writing 10 bytes
space 0x1007 was recreated successfully
writing 13 bytes
space 0x1008 was recreated successfully
writing 16 bytes
command "write" failed with code 0x5008
the TPM error code is unknown to this program
writing to 0x1009 failed
ERROR: could not fix backup space
Restarting trunksd...
ERROR: TPM was not fully recovered.
 - TPM recovery failed.
...
...
...

We don't use firmware space 0x1009 anymore. coreboot is moving to use SPI flash for NvStorage on all platforms, so it's not vulnerable to battery power loss.

... legacy machines still use space 0x1009 of course, but newer ones don't. And of course none of the machines with TPMv2.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/factory_installer/+/8ce5e38b8bc627a4f6f294bf4eb8bd045c888c01

commit 8ce5e38b8bc627a4f6f294bf4eb8bd045c888c01
Author: Hung-Te Lin <hungte@chromium.org>
Date: Fri Nov 11 08:21:47 2016

factory_install: Call chromeos-tpm-recovery to reset TPM.

Factory Reset shim has to clear (wipe/zero) TPM NV spaces so devices
with wrong antirollback records can be recovered. However, the script
becomes more complicated due to (1) vboot changes (2) TPM2.

vboot_reference has an utility 'chromeos-tpm-recovery' that was has
more complete support of TPM recovery, although it does more (try to
re-create or even redefine the space) than what we need. To prevent
duplicating code, we should just run chromeos-tpm-recovery instead of
introducing our own implementation.

BUG= chromium:664390 
TEST=./build_image factory_install; boot as recovery mode on Link+TPM1,
     enter menu, select item "r" (Reset) or "i" (Install). Also tried
     on Reef+TPM2.

Reviewed-on: https://chromium-review.googlesource.com/410523
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>

(cherry picked from commit c2e2fbeef92eb2391dbda5d4fca3eaf7bbfa9b1d)

Change-Id: I267a6694f46a5ab47a417936e2f08d8b4a47a6fd
Reviewed-on: https://chromium-review.googlesource.com/412496
Reviewed-by: Chun-Tsen Kuo <chuntsen@chromium.org>
Commit-Queue: Chun-Tsen Kuo <chuntsen@chromium.org>
Tested-by: Chun-Tsen Kuo <chuntsen@chromium.org>

[modify] https://crrev.com/8ce5e38b8bc627a4f6f294bf4eb8bd045c888c01/factory_install.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/factory_installer/+/9bbd27dfb0684abbf4ae3c6ac5b1333d820d55f6

commit 9bbd27dfb0684abbf4ae3c6ac5b1333d820d55f6
Author: Hung-Te Lin <hungte@chromium.org>
Date: Fri Nov 11 08:21:47 2016

factory_install: Call chromeos-tpm-recovery to reset TPM.

Factory Reset shim has to clear (wipe/zero) TPM NV spaces so devices
with wrong antirollback records can be recovered. However, the script
becomes more complicated due to (1) vboot changes (2) TPM2.

vboot_reference has an utility 'chromeos-tpm-recovery' that was has
more complete support of TPM recovery, although it does more (try to
re-create or even redefine the space) than what we need. To prevent
duplicating code, we should just run chromeos-tpm-recovery instead of
introducing our own implementation.

BUG= chromium:664390 
TEST=./build_image factory_install; boot as recovery mode on Link+TPM1,
     enter menu, select item "r" (Reset) or "i" (Install). Also tried
     on Reef+TPM2.

Change-Id: I7b618946c55e24e775dc6972a23b6d271455ff06
Reviewed-on: https://chromium-review.googlesource.com/410523
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit c2e2fbeef92eb2391dbda5d4fca3eaf7bbfa9b1d)
Reviewed-on: https://chromium-review.googlesource.com/414666
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Trybot-Ready: Hung-Te Lin <hungte@chromium.org>

[modify] https://crrev.com/9bbd27dfb0684abbf4ae3c6ac5b1333d820d55f6/factory_install.sh