Edward O'Callaghan has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40517 )
Change subject: mb/google/hatch: Toggle on EC_ENABLE_LID_SWITCH
......................................................................
mb/google/hatch: Toggle on EC_ENABLE_LID_SWITCH
Unfortunately EC_ENABLE_LID_SWITCH needs to be toggled on
to enable the 'PNP0C0D' ASL device on otherwise the wake
pin will not be noticed by the kernel. This patch works
around that issue for Puff and Puff variants.
BUG=b:152913653
BRANCH=none
TEST=builds
Change-Id: I2f40afb7aa62510312164d3a62d44f4b2b911700
Signed-off-by: Edward O'Callaghan <quasisec(a)google.com>
---
M src/mainboard/google/hatch/variants/duffy/include/variant/ec.h
M src/mainboard/google/hatch/variants/kaisa/include/variant/ec.h
M src/mainboard/google/hatch/variants/puff/include/variant/ec.h
3 files changed, 6 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/17/40517/1
diff --git a/src/mainboard/google/hatch/variants/duffy/include/variant/ec.h b/src/mainboard/google/hatch/variants/duffy/include/variant/ec.h
index 5e2043f..9f9b4a9 100644
--- a/src/mainboard/google/hatch/variants/duffy/include/variant/ec.h
+++ b/src/mainboard/google/hatch/variants/duffy/include/variant/ec.h
@@ -49,6 +49,8 @@
* Note that GPE_EC_WAKE is defined, confusingly, as GPE_LAN_WAK which is GPD2/LAN_WAKE#
* on the PCH or as the line EC_PCH_WAKE_ODL on the schematic.
*/
+/* Enable LID switch such that the wake pin works for the EC */
+#define EC_ENABLE_LID_SWITCH
#define EC_ENABLE_WAKE_PIN GPE_EC_WAKE
#define SIO_EC_MEMMAP_ENABLE /* EC Memory Map Resources */
diff --git a/src/mainboard/google/hatch/variants/kaisa/include/variant/ec.h b/src/mainboard/google/hatch/variants/kaisa/include/variant/ec.h
index 5e2043f..9f9b4a9 100644
--- a/src/mainboard/google/hatch/variants/kaisa/include/variant/ec.h
+++ b/src/mainboard/google/hatch/variants/kaisa/include/variant/ec.h
@@ -49,6 +49,8 @@
* Note that GPE_EC_WAKE is defined, confusingly, as GPE_LAN_WAK which is GPD2/LAN_WAKE#
* on the PCH or as the line EC_PCH_WAKE_ODL on the schematic.
*/
+/* Enable LID switch such that the wake pin works for the EC */
+#define EC_ENABLE_LID_SWITCH
#define EC_ENABLE_WAKE_PIN GPE_EC_WAKE
#define SIO_EC_MEMMAP_ENABLE /* EC Memory Map Resources */
diff --git a/src/mainboard/google/hatch/variants/puff/include/variant/ec.h b/src/mainboard/google/hatch/variants/puff/include/variant/ec.h
index 5e2043f..9f9b4a9 100644
--- a/src/mainboard/google/hatch/variants/puff/include/variant/ec.h
+++ b/src/mainboard/google/hatch/variants/puff/include/variant/ec.h
@@ -49,6 +49,8 @@
* Note that GPE_EC_WAKE is defined, confusingly, as GPE_LAN_WAK which is GPD2/LAN_WAKE#
* on the PCH or as the line EC_PCH_WAKE_ODL on the schematic.
*/
+/* Enable LID switch such that the wake pin works for the EC */
+#define EC_ENABLE_LID_SWITCH
#define EC_ENABLE_WAKE_PIN GPE_EC_WAKE
#define SIO_EC_MEMMAP_ENABLE /* EC Memory Map Resources */
--
To view, visit https://review.coreboot.org/c/coreboot/+/40517
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I2f40afb7aa62510312164d3a62d44f4b2b911700
Gerrit-Change-Number: 40517
Gerrit-PatchSet: 1
Gerrit-Owner: Edward O'Callaghan <quasisec(a)chromium.org>
Gerrit-MessageType: newchange
Anil Kumar K has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40537 )
Change subject: mb/google/deltaur: Update ISH firmware name
......................................................................
mb/google/deltaur: Update ISH firmware name
Bug=b:153847811
Branch=master
Test=make build successfull
Signed-off-by: Anil Kumar <anil.kumar.k(a)intel.com>
Change-Id: Ic701f224452731e43207836882d649580b76db3a
---
M src/mainboard/google/deltaur/variants/baseboard/devicetree.cb
1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/37/40537/1
diff --git a/src/mainboard/google/deltaur/variants/baseboard/devicetree.cb b/src/mainboard/google/deltaur/variants/baseboard/devicetree.cb
index e0b3d50..831c1c4 100644
--- a/src/mainboard/google/deltaur/variants/baseboard/devicetree.cb
+++ b/src/mainboard/google/deltaur/variants/baseboard/devicetree.cb
@@ -175,7 +175,13 @@
device pci 11.2 off end # UART5
device pci 11.3 off end # UART6
- device pci 12.0 on end # ISH
+ device pci 12.0 on
+ chip drivers/intel/ish
+ register "firmware_name" = ""deltaur_ish.bin""
+ device generic 0 on end
+ end
+ end # ISH
+
device pci 12.6 off end # GSPI #2
device pci 13.0 off end # GSPI #3
device pci 13.1 off end # GSPI #4
--
To view, visit https://review.coreboot.org/c/coreboot/+/40537
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ic701f224452731e43207836882d649580b76db3a
Gerrit-Change-Number: 40537
Gerrit-PatchSet: 1
Gerrit-Owner: Anil Kumar K <anil.kumar.k(a)intel.com>
Gerrit-MessageType: newchange
Varshit B Pandya has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/34657 )
Change subject: Documentation/soc/intel: Add documentation for MCU update
......................................................................
Documentation/soc/intel: Add documentation for MCU update
Change-Id: I3deb24550c1f1cd4c7b8082af75115ca174c295a
Signed-off-by: Pandya, Varshit B <varshit.b.pandya(a)intel.com>
---
A Documentation/soc/intel/ucode_update/Flash_Layout.PNG
A Documentation/soc/intel/ucode_update/microcode_update_model.md
2 files changed, 43 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/57/34657/1
diff --git a/Documentation/soc/intel/ucode_update/Flash_Layout.PNG b/Documentation/soc/intel/ucode_update/Flash_Layout.PNG
new file mode 100644
index 0000000..ac18977
--- /dev/null
+++ b/Documentation/soc/intel/ucode_update/Flash_Layout.PNG
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
new file mode 100644
index 0000000..e2d7f35
--- /dev/null
+++ b/Documentation/soc/intel/ucode_update/microcode_update_model.md
@@ -0,0 +1,43 @@
+# Microcode update mechanism for devices in field
+
+## 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.
+
+##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
+
+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.
+
+## 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.
+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.
+
+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.
+
+## 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.
+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.
+ 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
+
+4. The proposed design uses the PCR register based control for top-swap
--
To view, visit https://review.coreboot.org/c/coreboot/+/34657
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I3deb24550c1f1cd4c7b8082af75115ca174c295a
Gerrit-Change-Number: 34657
Gerrit-PatchSet: 1
Gerrit-Owner: Varshit B Pandya <varshit.b.pandya(a)intel.com>
Gerrit-MessageType: newchange
Hello Kyösti Mälkki, Aaron Durbin, Arthur Heymans, cedarhouse1(a)comcast.net,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/38768
to review the following change.
Change subject: [UNTESTED] intel/stm: Introduce stm_update_smm_info()
......................................................................
[UNTESTED] intel/stm: Introduce stm_update_smm_info()
Add a helper that will be called from `mp_init.c`. This allows to keep
SMRAM allocations local to STM code.
Call it after validation of the original numbers.
Change-Id: I2c29a4adfc78f21126122caefffa27a4d6d8c5df
Signed-off-by: Nico Huber <nico.h(a)gmx.de>
---
M src/cpu/x86/mp_init.c
M src/security/intel/stm/SmmStm.h
M src/security/intel/stm/StmPlatformSmm.c
3 files changed, 26 insertions(+), 21 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/68/38768/1
diff --git a/src/cpu/x86/mp_init.c b/src/cpu/x86/mp_init.c
index 9bc4aab..5b34d4b 100644
--- a/src/cpu/x86/mp_init.c
+++ b/src/cpu/x86/mp_init.c
@@ -1042,26 +1042,6 @@
&state->smm_save_state_size);
/*
- * Make sure there is enough room for the SMM descriptor
- */
- if (CONFIG(STM)) {
- state->smm_save_state_size +=
- sizeof(TXT_PROCESSOR_SMM_DESCRIPTOR);
-
- /* Currently, the CPU SMM save state size is based on a simplistic
- * algorithm. (align on 4K)
- * note: In the future, this will need to handle newer x86 processors
- * that require alignment of the save state on 32K boundaries.
- * The alignment is done here because coreboot has a hard coded
- * value of 0x400 for this value.
- * Also, this alignment only works on CPUs less than 5 threads
- */
- if (CONFIG(STM))
- state->smm_save_state_size =
- ALIGN_UP(state->smm_save_state_size, 0x1000);
- }
-
- /*
* Default to smm_initiate_relocation() if trigger callback isn't
* provided.
*/
@@ -1093,8 +1073,11 @@
mp_state.ops.relocation_handler != NULL)
smm_enable();
- if (is_smm_enabled())
+ if (is_smm_enabled()) {
printk(BIOS_INFO, "Will perform SMM setup.\n");
+ stm_update_smm_info(&mp_state.perm_smbase, &mp_state.perm_smsize,
+ &mp_state.smm_save_state_size);
+ }
mp_params.num_cpus = mp_state.cpu_count;
/* Gather microcode information. */
diff --git a/src/security/intel/stm/SmmStm.h b/src/security/intel/stm/SmmStm.h
index 1690255..f6ab0bf 100644
--- a/src/security/intel/stm/SmmStm.h
+++ b/src/security/intel/stm/SmmStm.h
@@ -27,6 +27,13 @@
*/
int load_stm_image(uintptr_t mseg);
+#if CONFIG(STM)
+void stm_update_smm_info(
+ uintptr_t *perm_smbase, size_t *perm_smsize, size_t *smm_save_state_size);
+#else
+static inline void stm_update_smm_info(uintptr_t *, size_t *, size_t *) {}
+#endif
+
void stm_setup(
uintptr_t mseg, int cpu, uintptr_t smbase,
uintptr_t smbase_base, uint32_t offset32);
diff --git a/src/security/intel/stm/StmPlatformSmm.c b/src/security/intel/stm/StmPlatformSmm.c
index 5be6ee7..c389afa 100644
--- a/src/security/intel/stm/StmPlatformSmm.c
+++ b/src/security/intel/stm/StmPlatformSmm.c
@@ -154,6 +154,21 @@
static int stm_load_status = 0;
+void stm_update_smm_info(
+ uintptr_t *const perm_smbase, size_t *const perm_smsize,
+ size_t *const smm_save_state_size)
+{
+ *smm_save_state_size += sizeof(TXT_PROCESSOR_SMM_DESCRIPTOR);
+
+ /*
+ * Currently, the CPU SMM save state size is based on a simplistic
+ * algorithm. (align on 4K)
+ * note: In the future, this will need to handle newer x86 processors
+ * that require alignment of the save state on 32K boundaries.
+ */
+ *smm_save_state_size = ALIGN_UP(*smm_save_state_size, 0x1000);
+}
+
void stm_setup(uintptr_t mseg, int cpu, uintptr_t smbase,
uintptr_t base_smbase, uint32_t offset32)
{
--
To view, visit https://review.coreboot.org/c/coreboot/+/38768
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I2c29a4adfc78f21126122caefffa27a4d6d8c5df
Gerrit-Change-Number: 38768
Gerrit-PatchSet: 1
Gerrit-Owner: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
Gerrit-Reviewer: cedarhouse1(a)comcast.net
Gerrit-MessageType: newchange