summaryrefslogtreecommitdiff
path: root/src/mainboard/google/eve
diff options
context:
space:
mode:
authorShelley Chen <shchen@google.com>2020-10-27 15:58:31 -0700
committerShelley Chen <shchen@google.com>2020-11-13 22:57:50 +0000
commit6615c6eaf798556b94ecc44d241222d6b19cd119 (patch)
tree1af1cb5e14a37f1156c4e2cc3dffd3d2a7303802 /src/mainboard/google/eve
parent0c3845d2ee5e582937f65f488e15055fe49464b0 (diff)
downloadcoreboot-6615c6eaf798556b94ecc44d241222d6b19cd119.tar.xz
mrc_cache: Move code for triggering memory training into mrc_cache
Currently the decision of whether or not to use mrc_cache in recovery mode is made within the individual platforms' drivers (ie: fsp2.0, fsp1.1, etc.). As this is not platform specific, but uses common vboot infrastructure, the code can be unified and moved into mrc_cache. The conditions are as follows: 1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain switch is true) 2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this means that memory training will occur after verified boot, meaning that mrc_cache will be filled with data from executing RW code. So in this case, we never want to use the training data in the mrc_cache for recovery mode. 3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this means that memory training happens before verfied boot, meaning that the mrc_cache data is generated by RO code, so it is safe to use for a recovery boot. 4. Any platform that does not use vboot should be unaffected. Additionally, we have removed the MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the mrc_cache driver takes care of invalidating the mrc_cache data for normal mode. If the platform: 1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data 2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set BUG=b:150502246 BRANCH=None TEST=1. run dut-control power_state:rec_force_mrc twice on lazor ensure that memory retraining happens both times run dut-control power_state:rec twice on lazor ensure that memory retraining happens only first time 2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig boot twice to ensure caching of memory training occurred on each boot. Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/mainboard/google/eve')
-rw-r--r--src/mainboard/google/eve/Kconfig1
1 files changed, 0 insertions, 1 deletions
diff --git a/src/mainboard/google/eve/Kconfig b/src/mainboard/google/eve/Kconfig
index 9316c7f213..ece0119a3e 100644
--- a/src/mainboard/google/eve/Kconfig
+++ b/src/mainboard/google/eve/Kconfig
@@ -28,7 +28,6 @@ config VBOOT
select EC_GOOGLE_CHROMEEC_SWITCHES
select HAS_RECOVERY_MRC_CACHE
select VBOOT_LID_SWITCH
- select MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN
config CHROMEOS
select DSAR_ENABLE