summaryrefslogtreecommitdiff
path: root/src/drivers/mrc_cache/Kconfig
AgeCommit message (Collapse)Author
2023-09-01drivers/mrc_cache: Fix extra space at the beginning of lineSubrata Banik
Change-Id: Ic49cb6c67aa707efa6495788137b550683008868 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77594 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-26vc/intel: Remove unnecessary Kconfig optionsMartin Roth
These Kconfig options were being used basically as #define statements, which is unnecessary. This isn't a good use of Kconfig options and would be better just as #defines if actually needed. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: If987b50d8ec3bb2ab99096e5e3c325e4d90a67a9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77419 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-06-23driver/intel/fsp2_0: Add support to store MRC cache using MRC versionSubrata Banik
This patch uses the "generic" variable name as "version" while storing the MRC cache data instead referring to the FSP-M version or MRC version. Hence, updated all the instances of `fsp_version/fspm_version` with `version`. Also introduces the new option to the MRC cache version that allows SoC users to store the MRC cache version based on the supported EDK2 version. Intel FSP built with EDK2 version 202302 onwards has support to retrieve the MRC version by directly parsing the binary. Additionally, added the helper function `fsp_mrc_version()` and corresponding header file to read the MRC version from the FSP binary. BUG=b:261689642 TEST=Able to build and boot google/rex and google/omnigul. Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: Ia8af53aed674ad4a3b426264706264df91d9c6b0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75920 Reviewed-by: Tarun Tuli <taruntuli@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Kapil Porwal <kapilporwal@google.com>
2022-06-24drivers/mrc_cache: Do not verify TPM MRC hash if secdata is mockedMichał Żygowski
Having PTT means mocking secdata, so saving/reading the hash always succeeds, but there is no data stored/read from/to TPM. The code comparing MRC hashes did not care if secdata mocking was enabled and failed during hash comparison with invalid data. This broke the fastboot even if the MRC cache data was filled and correctly checksummed. If mocking is enabled simply fallback to checksum computing to proceed with fastboot. TEST=Boot MSI PRO Z690-A WIFI DDR4 in fastboot mode with PTT and vboot enabled. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Change-Id: Ic0cf04b129fe1c5e94cd8a803bb21aa350c3f8da Reviewed-on: https://review.coreboot.org/c/coreboot/+/64221 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-11-13mrc_cache: Move code for triggering memory training into mrc_cacheShelley Chen
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>
2020-10-20mrc_cache: Add config MRC_SAVE_HASH_IN_TPMShelley Chen
Use this config to specify whether we want to save a hash of the MRC_CACHE in the TPM NVRAM space. Replace all uses of FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have recovery MRC_CACHE. BUG=b:150502246 BRANCH=None TEST=emerge-nami coreboot chromeos-bootimage Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-02mrc_cache: Update mrc_cache data in romstageShelley Chen
Previously, we were writing to cbmem after memory training and then writing the training data from cbmem to mrc_cache in ramstage. We were doing this because we were unable to read/write to SPI simultaneously on older x86 chips. Now that newer chips allow for simultaneously reads and writes, we can move the mrc_cache update into romstage. This is beneficial if there is a reboot for some reason after memory training but before the previous mrc_cache_stash_data call originally in ramstage. If this happens, we would lose all the mrc_cache training data in the next boot even though we've already performed the memory training. Added new config BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to accomodate older x86 platforms that don't do mmapping but still want to use the cbmem to store the mrc_cache data in order to write the mrc_cache data back at a later time. We are maintaining the use of cbmem for these older platforms because we have no way of validating the earlier write back to mrc_cache at this time. BUG=b:150502246 BRANCH=None TEST=reboot from ec console. Make sure memory training happens. reboot from ec console. Make sure that we don't do training again. Signed-off-by: Shelley Chen <shchen@google.com> Change-Id: I3430bda45484cb8c2b01ab9614508039dfaac9a3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44196 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-09vboot: Clean up pre-RAM use of vboot_recovery_mode_enabled()Julius Werner
vboot_recovery_mode_enabled() was recently changed to assert() when it is called before vboot logic has run, because we cannot determine whether we're going to be in recovery mode at that point and we wanted to flush out existing uses that pretended that we could. Turns out there are a bunch of uses like that, and there is some code that is shared across configurations that can and those that can't. This patch cleans them up to either remove checks that cannot return true, or add explicit Kconfig guards to clarify that the code is shared. This means that using a separate recovery MRC cache is no longer supported on boards that use VBOOT_STARTS_IN_ROMSTAGE (this has already been broken with CB:38780, but with this patch those boards will boot again using their normal MRC caches rather than just die). Skipping the MRC cache and always regenerating from scratch in recovery mode is likewise no longer supported for VBOOT_STARTS_IN_ROMSTAGE. For FSP1.1 boards, none of them support VBOOT_STARTS_IN_BOOTBLOCK and that is unlikely to change in the future so we will just hardcode that fact in Kconfig (otherwise, fsp1.1 raminit would also have to be fixed to work around this issue). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I31bfc7663724fdacab9955224dcaf650d1ec1c3c Reviewed-on: https://review.coreboot.org/c/coreboot/+/39221 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-01-20drivers/mrc_cache: Always generate an FMAP regionArthur Heymans
This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-19drivers/mrc_cache: Make bootstate for SPI writes variableMarshall Dawson
The default time for writing MRC data to flash is at the exit of BS_DEV_ENUMERATE but this is too early for some implementations. Add an option to Kconfig for allowing a late option to be selected. The timing of the late option is at the entry of BS_OS_RESUME_CHECK. TEST=Select option and inspect console log on Kahlee BUG=b:69614064 Change-Id: Ie7ba9070829d98414ee788e14d1a768145d742ea Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/22937 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-24drivers/mrc_cache: Make CACHE_MRC_SETTINGS not selectableArthur Heymans
Don't allow the user to select this manually, since it doesn't build on platforms that don't use it. Don't set the bool value so that it doesn't show as not selected in the .config file of platforms that don't use this. Change-Id: Icf026a297204868d485be270ccee7e0bec0ac73b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/22933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-12-17drivers/mrc_cache: move mrc_cache support to driversAaron Durbin
There's nothing intel-specific about the current mrc_cache support. It's logic manages saving non-volatile areas into the boot media. Therefore, expose it to the rest of the system for any and all to use. BUG=b:69614064 Change-Id: I3b331c82a102f88912a3e10507a70207fb20aecc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/22901 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 03:27:55 +0000