summaryrefslogtreecommitdiff
path: root/src/include/smp/atomic.h
diff options
context:
space:
mode:
authorShelley Chen <shchen@google.com>2020-05-01 17:00:31 -0700
committerShelley Chen <shchen@google.com>2020-10-02 23:11:39 +0000
commitb4a4f59dd2cbec1cb891ea1e537591e9800df02b (patch)
tree718dd24cb47d2ec6596e73dd86e8712c23e19eae /src/include/smp/atomic.h
parent156bc6f47a7c4536649f79ee037c7eed063d1805 (diff)
mrc_cache: Update mrc_cache data in romstage
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>
Diffstat (limited to 'src/include/smp/atomic.h')
0 files changed, 0 insertions, 0 deletions