It would be nice to have distinct non-zero error codes to distinguish between the following:

1. Cannot write the data
2. No permission to write (e.g. BoardID was already written)
etc.

We also need to be able to print the values, of course.

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

commit b78c65d081b483260e218f0c69959bf91c7adf92
Author: Louis Collard <louiscollard@chromium.org>
Date: Fri Dec 07 06:06:42 2018

gsctool: Add commands to set sn bits.

Adds two commands to set sn bits, and increment sn rma count.
These commands will be used in factory and RMA flows.

'gsctool -S 0x123:0x456:0x789' can be used to set sn bits
'gsctool -R <0-7>' can be used to increment rma count

BUG=chromium:905408
BRANCH=none
TEST=local manual tests on soraka

Change-Id: Iefb2076d5f53105ab36e84973d68f571b9626501
Signed-off-by: Louis Collard <louiscollard@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1347831
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/b78c65d081b483260e218f0c69959bf91c7adf92/common/extension.c
[modify] https://crrev.com/b78c65d081b483260e218f0c69959bf91c7adf92/extra/usb_updater/gsctool.c

Remind me please, where are we on this - will read operation be added to gsctool, or we already have all we wanted?

IIRC we were discussing what the use case for reading the values through gsctool was - I'm not sure we reached a consensus but my preference was for using a compile-time flag to determine ZTE support and not adding read support to gsctool. 

I remember the flag discussion now (and we also discussed other methods to read NVRAM).

Even if we do a flag (which we might), I am worried that there is no easy way on the factory floor to check that the bits were indeed written and look right, while there is for the BoardID. Maybe I am paranoid, but writing data into what may look like a black hole to OEMs seems a bit non standard?

One of my use cases too was to allow gooftool to check whether SN Bits had been written before writing a BoardID that then prevents SN Bits to ever be written. We can use the tpm_manager_client (probably not the right name) but gsctool seems like the obvious place for both read and write, at least from a user's perspective.

Yea I do agree that from the user's perspective it would be the obvious/simple thing to be able to both read and write from gsctool. 

If consensus is to add reads to gsctool then I'm fine with that, though I don't have time to work on it right now.

I do think that if usability is the main concern, then it is also worth considering just adding a small 'sn_bits' script that would call gsctool for writes and tpmc/etc for reads. 

For the record, my thinking is:
- AFAICT gsctool currently only contains cr50-specific things
- 'read sn bits' is actually just generic TPM 'read nv space'
- we have several tools that provide generic TPM functionality, and that can read sn bits
- ideally wouldn't be a factor, but the gsctool code is already rather large

For simplicity, let me add a "read sn" option to gsctool, it should break the Gordian knot here :) Don't promise until the end of the next week.
The original "write sn" part is done, I believe, so changing the title and assigning to myself.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.