Re-assign to yhong.

reassign to petershih. 

As suggested, what we need to do is:
1. Read back GBB flags to see if we're butting to dev mode
2. Only if dev mode is off, remove .developer_mode file

To read back GBB flags, at least I see two methods:

1. Use 'flashrom' to read image, then use 'futility' to get gbb flags
$ flashrom -p host -i GBB -r /home/root/tmp1
$ futility gbb --get --flags /home/root/tmp1
flags: 0x00000000

2. Use our 'crosfw' python module
import factory_common
from cros.factory.gooftool import crosfw
main_fw_file = crosfw.LoadMainFirmware().GetFileName()
raw_image = open(main_fw_file, 'rb').read()
image = crosfw.FirmwareImage(raw_image)
gbb = image.get_section('GBB')

But the GBB section data 'gbb' contains other information like hwid, digest, root key, recovery key, etc. And we need to write a parser to extract out the GBB flags.

So I'm thinking to use method 1. Any concern or other ideas?

To decide if we're going to boot into dev mode in the next boot, it seems the flag GBB_FLAG_FORCE_DEV_SWICH_ON is what we're interested here.

Do we need to check other flags as well? All GBB flags are listed below:
(defined in gbb_header.h from vboot_reference)

/* Flags for .flags field */
/* Reduce the dev screen delay to 2 sec from 30 sec to speedup factory. */
#define GBB_FLAG_DEV_SCREEN_SHORT_DELAY		0x00000001
/*
 * BIOS should load option ROMs from arbitrary PCI devices. We'll never enable
 * this ourselves because it executes non-verified code, but if a customer
 * wants to void their warranty and set this flag in the read-only flash, they
 * should be able to do so.
 */
#define GBB_FLAG_LOAD_OPTION_ROMS			0x00000002
/*
 * The factory flow may need the BIOS to boot a non-ChromeOS kernel if the
 * dev-switch is on. This flag allows that.
 */
#define GBB_FLAG_ENABLE_ALTERNATE_OS			0x00000004
/* Force dev switch on, regardless of physical/keyboard dev switch position. */
#define GBB_FLAG_FORCE_DEV_SWITCH_ON			0x00000008
/* Allow booting from USB in dev mode even if dev_boot_usb=0. */
#define GBB_FLAG_FORCE_DEV_BOOT_USB			0x00000010
/* Disable firmware rollback protection. */
#define GBB_FLAG_DISABLE_FW_ROLLBACK_CHECK		0x00000020
/* Allow Enter key to trigger dev->tonorm screen transition */
#define GBB_FLAG_ENTER_TRIGGERS_TONORM			0x00000040
/* Allow booting Legacy OSes in dev mode even if dev_boot_legacy=0. */
#define GBB_FLAG_FORCE_DEV_BOOT_LEGACY			0x00000080
/* Allow booting using alternate keys for FAFT servo testing */
#define GBB_FLAG_FAFT_KEY_OVERIDE			0x00000100
/* Disable EC software sync */
#define GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC		0x00000200
/* Default to booting legacy OS when dev screen times out */
#define GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY		0x00000400
/* Disable PD software sync */
#define GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC		0x00000800
/* Disable shutdown on lid closed */
#define GBB_FLAG_DISABLE_LID_SHUTDOWN			0x00001000
/*
 * Allow full fastboot capability in firmware even if
 * dev_boot_fastboot_full_cap=0.
 */
#define GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP	0x00002000
/* Enable serial console */
#define GBB_FLAG_ENABLE_SERIAL				0x00004000
/* Disable using FWMP */
#define GBB_FLAG_DISABLE_FWMP                           0x00008000

there's only one flag controlling developer mode in GBB flags, but there are other mechanism to control "if your next boot is developer mode or not".

For example, if TPM has virtual_dev set and we didn't do disable_dev_request=1, then next boot will still be in DEV due to TPM dev.

But well, it's true you can try to determine that by reading GBB flags + disable_dev_request- that should give us 90% correct result I think.

Calling flashrom takes longer time and is  sometimes painful, but I agree there's probably no better way so far; so yes, adding a gbb call may be easier.

Re-assign to fshao, since fshao was recently working on shutdown issues etc.

Some draft CLs made by petershih@:

https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/668342
https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/668341