xref: /aosp_15_r20/external/coreboot/Documentation/soc/intel/cse_fw_update/cse_fw_update.md (revision b9411a12aaaa7e1e6a6fb7c5e057f44ee179a49c) 
1# CSE FW update mechanism for devices in field
2
3## Introduction
4
5CSE Firmware and PMC Firmware are critical components of Intel SoCs.
6CSE and PMC cooperate by providing platform services during boot and other
7power transition flows.
8
9## Problem Statement
10
11Currently, on ChromiumOS Systems, CSE region is not updatable. So, new CSE FW
12versions that are released by Intel to address important functional and security
13bugs post-product launch will not be available to the end-user. Hence, the proposed
14solution allows in-field CSE FW update to propagate those bug fixes
15to end user platforms.
16
17## Design Proposal
18
19### CSE FW design Proposal:
20
21Key Elements:
22
23- CSE FW layout is composed of two bootable partitions (RO Recovery Partition
24  and RW Normal Partition).
25
26- Boot partition selection: An API-based mechanism is used to decide from which partition
27  CSE will boot.
28
29- The HECI APIs below will be supported in this CSE FW:
30
31    - HMRFPO_ENABLE: This command requests the CSE enter a mode in which writes to
32    the CSE region from the CSE are disabled. It also grants temporary write access
33    to the RW partition from the host (RO is still protected by GPR0).
34
35    - GET_PARTITION_INFO: The command retrieves information for each boot partition from CSE
36    like version, start/end offsets of a partition within CSE region, and boot
37    partition status. Also, it provides below information:
38	    - The current boot partition which was used during this boot,
39	    - The boot partition that will be used on the next CSE reset
40	    - The number of boot partitions available in the CSE region
41
42    - SET_BOOT_PARTITION_INFO: This command allows the firmware to request the
43    CSE to boot from either its RO or RW partition at its next reset.
44
45    - DATA_CLEAR: This command requests the CSE to reset its data partition back
46    to manufacturing defaults
47
48FW Layout, RW/RO Partitions:
49
50The CSE RO partition is the first in the CSE boot order, hence it will be used
51out of G3. RO partition contains minimum CSE code capable to boot platform and
52execute FW update of RW partition. In addition to CSE code, the RO partition also
53contains PMC FW patch and other CSE-loadable platform FW components.
54
55RW partition contains fully operational CSE FW, PMC FW, other CSE loadable
56platform FW components.
57
58Boot partition selection:
59
60CSE FW shall support 2 APIs to get boot partition info, and set boot partition
61info to notify CSE to select the partition on the next boot.
62
63### HOST FW Design proposal:
64
65Key Elements:
66
67- Build time artifacts:
68
69    CSE RW Version update binary - The FW shall pack CSE RW update blob and
70    corresponding version binary which contains version of the CSE RW blob.
71
72- FW Update:
73
74    coreboot will implement the logic to compare the CSE's FW version with CBFS
75    CSE RW binary's version in the firmware slot (FW_MAIN_A/FW_MAIN_B) and update
76    the CSE RW region if there is a version mismatch. If there is no version
77    mismatch, firmware skips CSE FW update.
78
79- Handling of CSE FW Downgrade:
80
81  coreboot will send DATA_CLEAR HECI command when there is a CSE FW downgrade.
82  This must be done to avoid data mismatch due to CSE FW downgrade. Further,
83  CSE will restore the data back to manufacturing defaults after data reset.
84
85
86## Implementation Details
87
88
89To enable CSE FW update flow the following changes are required in coreboot:
90
91* Descriptor change may be required to accommodate CSE binary. The CSE binary is tied with
92a platform. So CSE size may vary from one platform to another.
93* FMAP changes may be required to accommodate CSE binary and CSE RW blob in the RW CBFS region.
94Please check platform specific CSE kit for CSE binary information.
95* CSE Lite SKU binary and CSE RW blob
96* Makefile change to pack CSE RW binaries in the CBFS
97* Implementation of update flow:
98 - Get CSE boot partition info using GET_BOOT_PARTITION_INFO HECI command.
99 - Get the cbfs_me_rw.version from the currently selected RW slot.
100 - If the version from the above 2 locations don't match, then start CSE FW update.
101	 - If CSE is not booting from RO, then
102		- Set the CSE's next boot partition to RO using SET_BOOT_PARTITION_INFO
103        HECI command.
104		- Send GLOBAL_RESET HECI command to reset the system.
105	 - If RW update is a CSE FW downgrade, then coreboot has to send
106        DATA_CLEAR command to clear run time data of CSE.
107	 - Enable HMRFPO Mode (Host ME Region Flash Protection Override) by
108        sending HMRFPO_ENABLE HECI command to CSE.
109	 - Erase and Copy the CBFS CSE RW to CSE RW partition
110     - Set CSE's next boot partition to RW.
111	 - Trigger Global Reset which resets both CSE and Host.
112	Then system should boot with the updated CSE.
113
114* The resulting flash layout is shown below:
115
116![Flash Layout](./Layout_before.svg) ![FlashLayout](./Layout_after.svg)
117
118
119 - Typical boot flow
120
121   - Vboot selects the RW FW (FW_MAIN_A or FW_MAIN_B) to boot.
122   - coreboot skips CSE FW update flow if boot mode is recovery.
123   - If CSE RW blob is not locatable in the CBFS, then RW Firmware skips update flow
124     and sends SET_BOOT_PARTITION_INFO command to switch CSE to boot from RW
125     and issues Global Reset if CSE is already not booting from RW partition.
126   - The RW firmware will compare the CSE RW version with CSE RW blob in the slot.
127   - If there is a mismatch, then firmware will carry out update flow as explained before.
128