Provide a better (again) way to help partners and Google developers understanding and managing firmware updates.
Firmware updating process in ChromeOS AU is known to be complicated because it has to deal with different requests and different use cases. These were controlled by the logic in firmware updater scripts and the package setup (ebuild) files.
We had tried to simplify the process few times - and the latest one was http://go/cros-fw-update-simplified. From that design, the updating logic is primarily based on two things: write protection enabled or not, and a "stable version" setting in ebuild.
These rules worked pretty well and covered most of the scenarios that Chromebook projects needed, but since there are more new partners involved, the right way to use "stable version" seems obfuscating to them. Also we are seeing requests about making firmware root key change process more smooth. This should not be a problem if people only set "stable version" when the devices has reached MP, as recommended. On recent Intel systems we have needed to set the stable value to avoid dogfooders getting crashes during suspend due to MRC cache getting corrupted (it has been a while, maybe this is not an issue any more?).
To help dogfood process going more smoothly, and by the help from our recent work of "support different RO and RW in updater", we should consider to simplify the updater and ebuild files (again) to make it really easy to maintain and understood.
The goal is to deprecate the CROS_FIRMWARE_STABLE_MAIN_VERSION and CROS_FIRMWARE_STABLE_{EC,PD}_VERSION settings by using different RO & RW (CROS_FIRMWARE_MAIN_RW_IMAGE) with simplified logic - that we now always try to update RO if it's changed.
One important thing to address that is for recent x86 systems, suspend / resume after an update (especially RO) may not work, because:
- MRC cache may be invalid.
- ACPI tables may have been changed and existing pointers become invalid.
This is a known issue and no good solution yet except reducing RO updates unless it's really needed, and that's one of the reason we are proposing this new updater logic to avoid the magic STABLE version settings.
Complete design doc in https://goto.google.com/cros-fw-update-2017
