Varshit B Pandya has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/35015 )
Change subject: Documentation/soc/intel: Add documentation for MCU update ......................................................................
Documentation/soc/intel: Add documentation for MCU update
Change-Id: Ia1a9e77e44344dd2483fa88c8a51a25403267a13 Signed-off-by: Pandya, Varshit B varshit.b.pandya@intel.com --- M Documentation/soc/intel/index.md D Documentation/soc/intel/ucode_update/Flash_Layout.PNG M Documentation/soc/intel/ucode_update/microcode_update_model.md 3 files changed, 50 insertions(+), 15 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/15/35015/1
diff --git a/Documentation/soc/intel/index.md b/Documentation/soc/intel/index.md index f30ff9a..0cc4cc1 100644 --- a/Documentation/soc/intel/index.md +++ b/Documentation/soc/intel/index.md @@ -10,3 +10,4 @@ - [MP Initialization](mp_init/mp_init.md) - [Firmware Interface Table](fit.md) - [Apollolake](apollolake/index.md) +- [Microcode Update](ucode_update/microcode_update_model.md) diff --git a/Documentation/soc/intel/ucode_update/Flash_Layout.PNG b/Documentation/soc/intel/ucode_update/Flash_Layout.PNG deleted file mode 100644 index ac18977..0000000 --- a/Documentation/soc/intel/ucode_update/Flash_Layout.PNG +++ /dev/null Binary files differ diff --git a/Documentation/soc/intel/ucode_update/microcode_update_model.md b/Documentation/soc/intel/ucode_update/microcode_update_model.md index c7bcc74..9fe3c3b 100644 --- a/Documentation/soc/intel/ucode_update/microcode_update_model.md +++ b/Documentation/soc/intel/ucode_update/microcode_update_model.md @@ -2,42 +2,76 @@
## Introduction
-Processor microcode (MCU) is akin to processor firmware. Processors may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups. +Processor microcode (MCU) is akin to processor firmware. Processors may +need updates to their microcode to operate correctly. These updates fix +bugs/errata that can cause anything from incorrect processing, to code +and data corruption, and system lockups.
##Problem Statement
-As per chrome design, any field updatable FW has to be first verified by vboot (chrome root of trust - CROT) before it is allowed to run on the system. CROT executes on the CPU, hence FW such as MCU loaded before the CPU reset cannot be verified before it actually gets loaded. As a result today Chromebooks are not able to apply MCU in the field. This proposal tries to address the issue +As per chrome design, any field updatable FW has to be first verified +by vboot (chrome root of trust - CROT) before it is allowed to run on +the system. CROT executes on the CPU, hence FW such as MCU loaded before +the CPU reset cannot be verified before it actually gets loaded. As a +result today Chromebooks are not able to apply MCU in the field. This +proposal tries to address the issue
-Prior to CPU reset, the CPU HW locates the FIT table from the storage, walks over the FIT table and picks-up the MCU that matches the CPU Family, Model, Stepping and PLATFORM ID with the highest revision ID. CPU verifies that MCU is signed by Intel and once verification is successful, it attempts to load the MCU. +Prior to CPU reset, the CPU HW locates the FIT table from the storage, +walks over the FIT table and picks-up the MCU that matches the CPU +Family, Model, Stepping and PLATFORM ID with the highest revision ID. +CPU verifies that MCU is signed by Intel and once verification is +successful, it attempts to load the MCU.
-However FIT does not contain any fall back mechanism. If one MCU loading fails for whatever reason, it drops the further loading process and moves on to CPU reset. While it is fairly a remote chance, in case of any failure to load MCU which cause hang like situations before CPU reset, a platform based mechanism can be put in place to enter recovery mode. As detailed below, if we are using BUC register based top swap implementation, then an RTC reset may be required to clear top swap bit. +However FIT does not contain any fall back mechanism. If one MCU +loading fails for whatever reason, it drops the further loading process +and moves on to CPU reset. While it is fairly a remote chance, in case +of any failure to load MCU which cause hang like situations before CPU +reset, a platform based mechanism can be put in place to enter recovery +mode. As detailed below, if we are using BUC register based top swap +implementation, then an RTC reset may be required to clear top swap bit.
## Design Proposal
The proposal relies on the following Intel SoC features:
-1. Top swap, which enables the BIOS to have 2 bootblocks and bot from either using a RTC backed Top swap control bit in BUC register. +1. Top swap, which enables the BIOS to have 2 bootblocks and bot from +either using a RTC backed Top swap control bit in BUC register. 2. Firmware Interface Table (FIT) based MCU loading.
-The idea is to have 2 bootblocks, each having its own FIT table. The FIT in one of them will be configured to point to an MCU in RO firmware, and the FIT in other one will point to a fixed flash region (aka MCU staging area), which will contain an MCU from RW firmware. +The idea is to have 2 bootblocks, each having its own FIT table. The FIT +in one of them will be configured to point to an MCU in RO firmware, and +the FIT in other one will point to a fixed flash region (aka MCU staging +area), which will contain an MCU from RW firmware.
-Top-swap feature of Intel CPUs, will be used to switch between 2 bootblocks, based on the bootmode i.e., recovery or normal/developer mode. +Top-swap feature of Intel CPUs, will be used to switch between 2 +bootblocks, based on the bootmode i.e., recovery or normal/developer +mode.
-coreboot will keep the MCU staging area updated with the MCU from the currently selected RW firmware. +coreboot will keep the MCU staging area updated with the MCU from the +currently selected RW firmware.
## Implementation Details
-1. Create 2 BBs (bb_ro_ucode and bb_staged_ucode) each containing their own FIT tables. Both bootblocks will be in the RO section. - a. bb_ro_ucode contains a FIT which has pointer to MCU (microcode_blob.bin) which resides in RO section. This is will be used in the recovery scenario. - b. bb_staged_ucode is identical to bb_ro_ucode but contains a FIT which has pointer to a MCU that will reside in a staging area. +1. Create 2 BBs (bb_ro_ucode and bb_staged_ucode) each containing their +own FIT tables. Both bootblocks will be in the RO section. + a. bb_ro_ucode contains a FIT which has pointer to MCU + (microcode_blob.bin) which resides in RO section. This is will + be used in the recovery scenario. + b. bb_staged_ucode is identical to bb_ro_ucode but contains a + FIT which has pointer to a MCU that will reside in a staging + area. 2. Create a MCU staging area - a. Reserve a region in the FMAP which is equal to or greater than the MCU size specified in the BWG for that SoC. This is a RW region just lke the RW_MRC_CACHE. - b. MCU from RW-A/RW-B will be copied to this region during boot. - c. A Flash Protected Range (FPR) should be configured to write protect this MCU Staging area. + a. Reserve a region in the FMAP which is equal to or greater + than the MCU size specified in the BWG for that SoC. This is a + RW region just lke the RW_MRC_CACHE. + b. MCU from RW-A/RW-B will be copied to this region during + boot. + c. A Flash Protected Range (FPR) should be configured to write + protect this MCU Staging area. d. bb_staged_ucode FIT points to the MCU in this staging area. 3. The resulting flash layout is shown below, **Flash Layout** ![Flash Layout][flash_layout] -[flash_layout]: Flash_Layout.PNG +[flash_layout]: flash_layout.png
4. The proposed design uses the PCR register based control for top-swap
Varshit B Pandya has abandoned this change. ( https://review.coreboot.org/c/coreboot/+/35015 )
Change subject: Documentation/soc/intel: Add documentation for MCU update ......................................................................
Abandoned
pushed by mistake
-
Varshit B Pandya (Code Review)