Shelley Chen has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 SIP chips. Now that newer chips allow for simultaneously reads and writes, we can move the mrc_cache update into romstage.
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 --- M src/drivers/elog/Makefile.inc M src/drivers/mrc_cache/mrc_cache.c M src/include/region_file.h M src/lib/region_file.c 4 files changed, 137 insertions(+), 53 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/1
diff --git a/src/drivers/elog/Makefile.inc b/src/drivers/elog/Makefile.inc index cce1c3d..a1c14ff 100644 --- a/src/drivers/elog/Makefile.inc +++ b/src/drivers/elog/Makefile.inc @@ -1,6 +1,7 @@ bootblock-$(CONFIG_ELOG_PRERAM) += elog.c verstage-$(CONFIG_ELOG_PRERAM) += elog.c romstage-$(CONFIG_ELOG_PRERAM) += elog.c +romstage-$(CONFIG_ELOG) += elog.c postcar-$(CONFIG_ELOG_PRERAM) += elog.c ramstage-$(CONFIG_ELOG) += elog.c
diff --git a/src/drivers/mrc_cache/mrc_cache.c b/src/drivers/mrc_cache/mrc_cache.c index 0e42120..2dc6ee8 100644 --- a/src/drivers/mrc_cache/mrc_cache.c +++ b/src/drivers/mrc_cache/mrc_cache.c @@ -311,18 +311,26 @@ }
static bool mrc_cache_needs_update(const struct region_device *rdev, - const struct cbmem_entry *to_be_updated) + struct mrc_metadata *new_md, + const void *new_data, size_t new_data_size) { - void *mapping; + void *mapping, *data_mapping; size_t size = region_device_sz(rdev); bool need_update = false;
- if (cbmem_entry_size(to_be_updated) != size) + if (new_data_size != size) return true;
mapping = rdev_mmap_full(rdev); + data_mapping = mapping + sizeof(struct mrc_metadata);
- if (memcmp(cbmem_entry_start(to_be_updated), mapping, size)) + // we need to compare the md and the data separately + // check the mrc_metadata + if (memcmp(new_md, mapping, sizeof(struct mrc_metadata))) + need_update = true; + + // check the data + if (memcmp(new_data, data_mapping, new_data_size)) need_update = true;
rdev_munmap(rdev, mapping); @@ -357,7 +365,10 @@ * read and write. The read assumes a memory-mapped boot device that can be used * to quickly locate and compare the up-to-date data. However, when an update * is required it uses the writeable region access to perform the update. */ -static void update_mrc_cache_by_type(int type) +static void update_mrc_cache_by_type(int type, + struct mrc_metadata *new_md, + const void *new_data, + size_t new_data_size) { const struct cache_region *cr; struct region region; @@ -365,7 +376,6 @@ struct region_device write_rdev; struct region_file cache_file; struct mrc_metadata md; - const struct cbmem_entry *to_be_updated; struct incoherent_rdev backing_irdev; const struct region_device *backing_rdev; struct region_device latest_rdev; @@ -376,13 +386,6 @@ if (cr == NULL) return;
- to_be_updated = cbmem_entry_find(cr->cbmem_id); - if (to_be_updated == NULL) { - printk(BIOS_ERR, "MRC: No data in cbmem for '%s'.\n", - cr->name); - return; - } - printk(BIOS_DEBUG, "MRC: Checking cached data update for '%s'.\n", cr->name);
@@ -411,8 +414,9 @@
return;
- if (!mrc_cache_needs_update(&latest_rdev, to_be_updated)) { - printk(BIOS_DEBUG, "MRC: '%s' does not need update.\n", cr->name); + if (!mrc_cache_needs_update(&latest_rdev, + new_md, + new_data, new_data_size)) { log_event_cache_update(cr->elog_slot, ALREADY_UPTODATE); return; } @@ -420,9 +424,10 @@ printk(BIOS_DEBUG, "MRC: cache data '%s' needs update.\n", cr->name);
if (region_file_update_data(&cache_file, - cbmem_entry_start(to_be_updated), - cbmem_entry_size(to_be_updated)) < 0) { - printk(BIOS_DEBUG, "MRC: failed to update '%s'.\n", cr->name); + new_md, + sizeof(struct mrc_metadata), + new_data, + new_data_size) < 0) { log_event_cache_update(cr->elog_slot, UPDATE_FAILURE); } else { printk(BIOS_DEBUG, "MRC: updated '%s'.\n", cr->name); @@ -544,16 +549,59 @@
/* Push an update that consists of 4 bytes that is smaller than the * MRC metadata as well as an invalid signature. */ - if (region_file_update_data(&cache_file, &invalid, sizeof(invalid)) < 0) + if (region_file_update_data(&cache_file, NULL, 0, + &invalid, sizeof(invalid)) < 0) printk(BIOS_ERR, "MRC: invalidation failed for '%s'.\n", name); }
-static void update_mrc_cache(void *unused) +static void update_mrc_cache(struct mrc_metadata *md, + const void *data, + size_t size) { - update_mrc_cache_by_type(MRC_TRAINING_DATA); + update_mrc_cache_by_type(MRC_TRAINING_DATA, md, data, size);
if (CONFIG(MRC_SETTINGS_VARIABLE_DATA)) - update_mrc_cache_by_type(MRC_VARIABLE_DATA); + update_mrc_cache_by_type(MRC_VARIABLE_DATA, + md, data, size); + + if (CONFIG(MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN)) + invalidate_normal_cache(); + + protect_mrc_region(); +} + +static void update_mrc_cache_from_cbmem(int type) +{ + const struct cache_region *cr; + struct region region; + struct mrc_metadata md; + const struct cbmem_entry *to_be_updated; + + cr = lookup_region(®ion, type); + + if (cr == NULL) + return; + + to_be_updated = cbmem_entry_find(cr->cbmem_id); + + if (to_be_updated == NULL) { + printk(BIOS_ERR, "MRC: No data in cbmem for '%s'.\n", + cr->name); + return; + } + + update_mrc_cache(&md, + cbmem_entry_start(to_be_updated), + cbmem_entry_size(to_be_updated)); +} + +static void finalize_mrc_cache(void *unused) +{ + if (CONFIG(MRC_WRITE_NV_LATE)) + update_mrc_cache_from_cbmem(MRC_TRAINING_DATA); + + if (CONFIG(MRC_SETTINGS_VARIABLE_DATA)) + update_mrc_cache_from_cbmem(MRC_VARIABLE_DATA);
if (CONFIG(MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN)) invalidate_normal_cache(); @@ -562,11 +610,9 @@ }
int mrc_cache_stash_data(int type, uint32_t version, const void *data, - size_t size) + size_t size) { const struct cache_region *cr; - size_t cbmem_size; - struct mrc_metadata *md;
cr = lookup_region_type(type); if (cr == NULL) { @@ -575,24 +621,41 @@ return -1; }
- cbmem_size = sizeof(*md) + size; + if (CONFIG(MRC_WRITE_NV_LATE)) { + /* Store data in cbmem for use in ramstage */ + struct mrc_metadata *md; + size_t cbmem_size; + cbmem_size = sizeof(*md) + size;
- md = cbmem_add(cr->cbmem_id, cbmem_size); + md = cbmem_add(cr->cbmem_id, cbmem_size);
- if (md == NULL) { - printk(BIOS_ERR, "MRC: failed to add '%s' to cbmem.\n", - cr->name); - return -1; + if (md == NULL) { + printk(BIOS_ERR, "MRC: failed to add '%s' to cbmem.\n", + cr->name); + return -1; + } + + memset(md, 0, sizeof(*md)); + md->signature = MRC_DATA_SIGNATURE; + md->data_size = size; + md->version = version; + md->data_checksum = compute_ip_checksum(data, size); + md->header_checksum = compute_ip_checksum(md, sizeof(*md)); + memcpy(&md[1], data, size); + } else { + /* Otherwise store to mrc_cache right away */ + struct mrc_metadata md; + + memset(&md, 0, sizeof(struct mrc_metadata)); + md.signature = MRC_DATA_SIGNATURE; + md.data_size = size; + md.version = version; + md.data_checksum = compute_ip_checksum(data, size); + md.header_checksum = + compute_ip_checksum(&md, sizeof(struct mrc_metadata)); + + update_mrc_cache(&md, data, size); } - - memset(md, 0, sizeof(*md)); - md->signature = MRC_DATA_SIGNATURE; - md->data_size = size; - md->version = version; - md->data_checksum = compute_ip_checksum(data, size); - md->header_checksum = compute_ip_checksum(md, sizeof(*md)); - memcpy(&md[1], data, size); - return 0; }
@@ -602,7 +665,7 @@ */
#if CONFIG(MRC_WRITE_NV_LATE) -BOOT_STATE_INIT_ENTRY(BS_OS_RESUME_CHECK, BS_ON_ENTRY, update_mrc_cache, NULL); +BOOT_STATE_INIT_ENTRY(BS_OS_RESUME_CHECK, BS_ON_ENTRY, finalize_mrc_cache, NULL); #else -BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_EXIT, update_mrc_cache, NULL); +BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_EXIT, finalize_mrc_cache, NULL); #endif diff --git a/src/include/region_file.h b/src/include/region_file.h index 063e0e0..068e147 100644 --- a/src/include/region_file.h +++ b/src/include/region_file.h @@ -32,8 +32,11 @@ int region_file_data(const struct region_file *f, struct region_device *rdev);
/* Update region file with latest data. Returns < 0 on error, 0 on success. */ -int region_file_update_data(struct region_file *f, const void *buf, - size_t size); +int region_file_update_data(struct region_file *f, + const void *metadata, + size_t metadata_size, + const void *data, + size_t data_size);
/* Declared here for easy object allocation. */ struct region_file { diff --git a/src/lib/region_file.c b/src/lib/region_file.c index ce2ed30..3f47b28 100644 --- a/src/lib/region_file.c +++ b/src/lib/region_file.c @@ -365,11 +365,17 @@ return 0; }
-static int commit_data(const struct region_file *f, const void *buf, - size_t size) +static int commit_data(const struct region_file *f, + const void *metadata, + size_t metadata_size, + const void *data_buf, + size_t data_size) { size_t offset = block_to_bytes(region_file_data_begin(f)); - if (rdev_writeat(&f->rdev, buf, offset, size) < 0) + if (rdev_writeat(&f->rdev, metadata, offset, metadata_size) < 0) + return -1; + offset += metadata_size; + if (rdev_writeat(&f->rdev, data_buf, offset, data_size) < 0) return -1; return 0; } @@ -399,8 +405,12 @@ return 0; }
-static int handle_update(struct region_file *f, size_t blocks, const void *buf, - size_t size) +static int handle_update(struct region_file *f, + size_t blocks, + const void *metadata, + size_t metadata_size, + const void *data, + size_t data_size) { if (!update_can_fit(f, blocks)) { printk(BIOS_INFO, "REGF update can't fit. Will empty.\n"); @@ -413,7 +423,7 @@ return -1; }
- if (commit_data(f, buf, size)) { + if (commit_data(f, metadata, metadata_size, data, data_size)) { printk(BIOS_ERR, "REGF failed to commit data.\n"); return -1; } @@ -421,12 +431,18 @@ return 0; }
-int region_file_update_data(struct region_file *f, const void *buf, size_t size) +int region_file_update_data(struct region_file *f, + const void *metadata, + size_t metadata_size, + const void *data, + size_t data_size) { int ret; size_t blocks;
- blocks = bytes_to_block(ALIGN_UP(size, REGF_BLOCK_GRANULARITY)); + blocks = bytes_to_block(ALIGN_UP(data_size + + metadata_size, + REGF_BLOCK_GRANULARITY));
while (1) { int prev_slot = f->slot; @@ -442,7 +458,8 @@ ret = -1; break; default: - ret = handle_update(f, blocks, buf, size); + ret = handle_update(f, blocks, metadata, + metadata_size, data, data_size); break; }
Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 1:
This change is ready for review.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 7:
(2 comments)
To get the strago boards building properly, I set CONFIG_MRC_WRITE_NV_LATE=y due to a problem with the CAR overflowing. I am not sure if this is the right call though because I think that it pushes the writing back of the mrc_cache data further back than it was originally.
https://review.coreboot.org/c/coreboot/+/44196/3/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/3/src/drivers/mrc_cache/mrc_c... PS3, Line 327: // we need to compare the md and the data separately
Other comments in this file use C-style comments
Done
https://review.coreboot.org/c/coreboot/+/44196/3/src/drivers/mrc_cache/mrc_c... PS3, Line 419: new_data, new_data_size)) {
Are the printk's dropped here redundant?
Done
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 7:
(10 comments)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/elog/Makefile.i... File src/drivers/elog/Makefile.inc:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/elog/Makefile.i... PS7, Line 4: romstage-$(CONFIG_ELOG) += elog.c No, if we do this there's no point in having an ELOG_PRERAM option. Either we choose to get rid of ELOG_PRERAM completely or the accesses done by the MRC code need to be guarded with that option.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 384: cr = lookup_region(®ion, type); nit: might be easier to just pass in *cr instead of type because all the callers already have that.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 562: update_mrc_cache_by_type(MRC_TRAINING_DATA, md, data, size); I don't think you're treating `type` quite right throughout this. In mrc_cache_stash_data(), you already have a `type` parameter, so that function already handles only a single type (and if there are multiple types, platform code will call that function more than once). That means the function called from that should also just handle a single type. In the same way, update_mrc_cache_from_cbmem() is already only dealing with a single type.
So, long story short, I think both of those functions should probably just call update_mrc_cache_by_type() directly and you should get rid of this function.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 569: invalidate_normal_cache(); This and the protect_mrc_region() should probably just go in finalize, then.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 589: printk(BIOS_ERR, "MRC: No data in cbmem for '%s'.\n", Should this really be an ERR... isn't this the most common case, where we just didn't need to retrain and thus are also not updating anything? (I know the existing code already does this but it feels like INFO would be more appropriate... maybe Furquan understands what happens here better?)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 605: update_mrc_cache_from_cbmem(MRC_VARIABLE_DATA); Pretty sure this should also only happen for NV_LATE.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 644: md->header_checksum = compute_ip_checksum(md, sizeof(*md)); Let's try to factor out some of the code duplication here. For example:
struct mrc_metadata md;
...fill `md` like in the else-path...
if (CONFIG(MRC_WRITE_NV_LATE)) { struct mrc_metadata *cbmem = cbmem_add(...); if (!cbmem) ... memcpy(cbmem, &md, sizeof(*cbmem)); memcpy(&cbmem[1], data, size); } else { update_mrc_cache(&md, data, size); }
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 668: #if CONFIG(MRC_WRITE_NV_LATE) Is there still a reason to differentiate this or can we just always call finalize in RESUME_CHECK? (Sorry, I feel like this may have been discussed before but I forgot the result.)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/spi/Kconfig File src/drivers/spi/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/spi/Kconfig@47 PS7, Line 47: default y if BOOT_DEVICE_SPI_FLASH_RW_NOMMAP && BOOT_DEVICE_SPI_FLASH If this is required to use the MRC cache code you probably also need to add a depends on to some MRC cache option. This is just a default, users are free to change it (and it shouldn't be possible for them to change options through menuconfig into a configuration that doesn't build).
https://review.coreboot.org/c/coreboot/+/44196/7/src/lib/region_file.c File src/lib/region_file.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/lib/region_file.c@438 PS7, Line 438: size_t data_size) This API seems to be designed to handle arbitrary files, so encoding details of the MRC use case here doesn't seem great. Although I'm not sure how to do it better either, and since this is only used for MRC maybe we also just don't care.
I guess the more "correct" and generic way of doing this would be to support arbitrary scatter-gather writes (basically make the function take an array of pointers and an array of sizes). Not sure how much we care.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 7:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 668: #if CONFIG(MRC_WRITE_NV_LATE)
Is there still a reason to differentiate this or can we just always call finalize in RESUME_CHECK? ( […]
Yes, it was discussed. Here's your comment:
I would suggest organizing it like this:
mrc_cache_stash_data(type, version, data, size): if WRITE_NV_LATE: add stuff to cbmem for type else: update_mrc_cache_by_type(type, data, size) update_mrc_cache_from_cbmem(type): cr = lookup_region(type) entry = cbmem_entry_find(cr->cbmem_id) ...error handling as appropriate... update_mrc_cache_by_type(type, cbmem_entry_start(entry), cbmem_entry_size(entry)) BOOT_STATE_INIT_ENTRY(finalize_mrc_cache) finalize_mrc_cache(void *unused): if WRITE_NV_LATE: update_mrc_cache_from_cbmem(MRC_TRAINING_DATA) if VARIABLE_DATA: update_mrc_cache_from_cbmem(MRC_VARIABLE_DATA) if CLEAR_ON_RETRAIN: invalidate_normal_cache() protect_mrc_region() So basically, I would leave the BOOT_STATE callback in there for all configs, but it would only take the stash from CBMEM if WRITE_NV_LATE is set. In the other case all it does is handle the CLEAR_ON_RETRAIN and the protection stuff. The reason for that is that mrc_cache_stash_data() may be called multiple times in romstage (for multiple types of MRC cache), so you can't really be sure at what point you're done writing MRC caches and ready to enable the flash protection. Pushing that to ramstage is an easy solution (and shouldn't really cost anything... I'm just trying to get rid of all this copying through and reserving memory in CBMEM, having a boot stage callback that does basically nothing in ramstage doesn't really hurt).
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 7:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 668: #if CONFIG(MRC_WRITE_NV_LATE)
Yes, it was discussed. Here's your comment: […]
No, but that doesn't discuss which boot state the new finalize is executing in? All I'm saying is you might get away with just writing this as
BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_EXIT, finalize_mrc_cache, NULL);
without the #if to make it simpler. That depends on whether the non-NV_LATE platforms have any restrictions on when exactly the flash protection needs to happen in ramstage. Furquan can probably chime in on this.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 7:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 668: #if CONFIG(MRC_WRITE_NV_LATE)
No, but that doesn't discuss which boot state the new finalize is executing in? All I'm saying is yo […]
Oh gotcha. Sorry, I misunderstood your previous comment.
Hello build bot (Jenkins), Furquan Shaikh, Patrick Georgi, Martin Roth, Julius Werner,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#8).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 SIP chips. Now that newer chips allow for simultaneously reads and writes, we can move the mrc_cache update into romstage.
Updating spi driver Kconfig to set BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring the appropriate libraries into romstage.
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 --- M src/drivers/elog/Makefile.inc M src/drivers/mrc_cache/mrc_cache.c M src/drivers/spi/Kconfig M src/include/region_file.h M src/lib/region_file.c M src/mainboard/google/cyan/Kconfig M src/mainboard/google/deltaur/variants/baseboard/Makefile.inc M src/mainboard/intel/strago/Kconfig 8 files changed, 122 insertions(+), 54 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/8
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 8:
(6 comments)
So, just updated mrc_cache.c for now. I need to think about how to do the config options properly.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 562: update_mrc_cache_by_type(MRC_TRAINING_DATA, md, data, size);
I don't think you're treating `type` quite right throughout this. […]
Done
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 569: invalidate_normal_cache();
This and the protect_mrc_region() should probably just go in finalize, then.
This function has been removed.
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 589: printk(BIOS_ERR, "MRC: No data in cbmem for '%s'.\n",
Should this really be an ERR... […]
Done
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 605: update_mrc_cache_from_cbmem(MRC_VARIABLE_DATA);
Pretty sure this should also only happen for NV_LATE.
Done
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 644: md->header_checksum = compute_ip_checksum(md, sizeof(*md));
Let's try to factor out some of the code duplication here. For example: […]
Done
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 668: #if CONFIG(MRC_WRITE_NV_LATE)
Oh gotcha. Sorry, I misunderstood your previous comment.
removed the else condition for now and still using the conditional NV_LATE for now unless Furquan says otherwise.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
This change is ready for review.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22: Code-Review+1
(5 comments)
Thanks, this looks good to me in general now. Just a couple of nits, and I'm not quite sure why those Kconfigs need to go there but that's more of an x86-internal matter of opinion. I'll leave the +2 to Furquan.
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
This has been removed and put in the individual cpu Kconfig files.
Why? I think in general it's better to make the thing you normally want be the default and not push the burden on every single platform to select a bunch of boilerplate options.
Does anyone know why this is a separate Kconfig at all? Doesn't it just enable code that would be eliminated by the linker if it isn't used anyway? For those cases I usually don't see why there needs to be a Kconfig... either the platform has code that does RW flash accesses and then it needs to have that code, or it doesn't and the code is automatically eliminated. Why bother the user with that decision if it can be done automatically?
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 326: BIOS_INFO nit: still not BIOS_ERR... (and actually, on second thought, might be a good idea to start the line with "ERROR: MRC: " or something for visibility, because this is something that can happen when CBFS_CACHE size isn't big enough and we'd want people to notice that problem)
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 442: BIOS_DEBUG Here too, errors like these should really all use BIOS_ERR.
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 593: (void *) nit: unnecessary cast, cbmem_entry_start() already returns (void *)
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 594: nit: bad alignment? (don't use spaces unless you're aligning it to something specific, which I don't think you are here?)
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Why? I think in general it's better to make the thing you normally want be the default and not push […]
My understanding is that the config BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY was added to identify platforms that support writing to SPI flash in early CAR stages. There are some legacy Intel platforms which when executing out of memory mapped SPI flash did not allow writing back to it. Hence, we cannot just set BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY for all Intel platforms. Most of these platforms predate my involvement in coreboot. So, I am not really sure which platforms have this limitation.
Shelley - when we talked earlier this week I thought it was just Haswell and Broadwell boards that you needed BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY option for(based on the new boards where you selected MRC_WRITE_NV_LATE). But from your latest patchset, it looks like there are many more platforms for which this config is being added. I don't think it is possible to test out each of these platforms unless some one in the community has one of the boards and can do the testing.
In order to move forward with minimal regression, I think we should add a new Kconfig (I know we really wanted to avoid this, but it seems necessary) MRC_STASH_TO_CBMEM which will be auto-selected if MRC_WRITE_NV_LATE or !BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY. Then, in mrc_cache.c you can write back to flash immediately if !MRC_STASH_TO_CBMEM, else save the MRC data to CBMEM.
And, in finalize_mrc, you will have to write back to flash if MRC_STASH_TO_CBMEM is set (No need to check for MRC_WRITE_NV_LATE since it auto-selects MRC_STASH_TO_CBMEM).
Thoughts?
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(6 comments)
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 120: nit: irrelevant change.
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 314: struct const struct
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 337: ( If need_update is set to true above, there is no need to compare the data.
if (!need_update && memcmp(new_data, data_mapping, new_data_size)) need_update = true;
Or you can just extract the comparison into a function of its own:
mapping = rdev_mmap_full(rdev); if (mapping == NULL) { ... } need_update = mrc_compare(mapping, new_md, new_data, new_data_size);
rdev_munmap(rdev, mapping);
return need_update;
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 422: new_md, : new_data, new_data_size) nit: I think this might fit on a single line with 96-column limit?
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 602: MRC_WRITE_NV_LATE As per the latest comment, this will have to be MRC_STASH_TO_CBMEM
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 636: MRC_WRITE_NV_LATE MRC_STASH_TO_CBMEM
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Shelley - when we talked earlier this week I thought it was just Haswell and Broadwell boards that you needed
BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY option for
No, Haswell and Broadwell were the ones that I knew off the top of my head. There were 100+ boards failing overall when I removed the BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY config. Honestly the number of configs I ended up changing was far fewer than I expected :).
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Shelley - when we talked earlier this week I thought it was just Haswell and Broadwell boards that […]
Aah okay. Sorry I had misunderstood earlier. In that case, I think what I suggested above with MRC_STASH_TO_CBMEM should be the safest path forward with minimum change to platforms that we cannot really test.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22: Code-Review+1
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Aah okay. Sorry I had misunderstood earlier. […]
If possible, I'd prefer if older platforms with native raminit would continue to update the mrc cache in ramstage. That would be Sandy Bridge and earlier (cpu/intel/model_206ax, cpu/intel/model_2065x, nb/intel/x4x).
The reason is that native raminit can be rather quirky. If for some reason the resulting timings aren't good enough, the boards might hang randomly. If the board hangs in ramstage, it's best to try initializing the memory from scratch again. If these settings already got saved to flash, then they will be used instead and most likely results in a soft brick. Yes, one can temporarily remove a DIMM to force a full training, but not everyone brings a screwdriver with their laptop 😊
FWIW, I'm currently reinforcing the emergency mode for Sandy Bridge raminit, so that it can recover from more situations. I've had DIMMs on the Asus P8Z77-V LX2 (my best Sandy Bridge board) start failing just because I've moved the board around, and I'd say laptops would have the same (if not worse) problems.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
MRC_STASH_TO_CBMEM which will be auto-selected if MRC_WRITE_NV_LATE or !BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY.
Let's be careful not to create a situation where a new SoC generation could accidentally fall into the ramstage path just because it doesn't select BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY. So adding that option sounds okay and MRC_WRITE_NV_LATE can select it, but it shouldn't be automatic from !NOMMAP_EARLY.
Or, alternatively, how about flipping NOMMAP_EARLY around into BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES? Then we could make all those old chipsets select that, make the MRC cache behavior auto-select based on that, and all newly added SoCs would get the early write ability (for MRC cache and whatever else they may need) automatically without needing another boilerplate config line. I always think it's better to build these things so the stuff that you expect everything going forward to support is the default.
If for some reason the resulting timings aren't good enough, the boards might hang randomly. If the board hangs in ramstage, it's best to try initializing the memory from scratch again.
Yikes, that sounds... terrifying. ^^ Can't we come up with a better way to detect if the trained values are actually good than "let's see if ramstage crashes" (like primitive_memtest() or something)? But okay, sounds like we need to special case those boards anyway because of the issue Furquan mentioned.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
MRC_STASH_TO_CBMEM which will be auto-selected if MRC_WRITE_NV_LATE or !BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY.
Let's be careful not to create a situation where a new SoC generation could accidentally fall into the ramstage path just because it doesn't select BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY. So adding that option sounds okay and MRC_WRITE_NV_LATE can select it, but it shouldn't be automatic from !NOMMAP_EARLY.
Or, alternatively, how about flipping NOMMAP_EARLY around into BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES? Then we could make all those old chipsets select that, make the MRC cache behavior auto-select based on that, and all newly added SoCs would get the early write ability (for MRC cache and whatever else they may need) automatically without needing another boilerplate config line. I always think it's better to build these things so the stuff that you expect everything going forward to support is the default.
Sounds good to me. Having sane defaults for future platforms is always a good idea. Plus, `NO_EARLY_WRITES` is much more explicit than `NOMMAP_EARLY`.
If for some reason the resulting timings aren't good enough, the boards might hang randomly. If the board hangs in ramstage, it's best to try initializing the memory from scratch again.
Yikes, that sounds... terrifying. ^^ Can't we come up with a better way to detect if the trained values are actually good than "let's see if ramstage crashes" (like primitive_memtest() or something)? But okay, sounds like we need to special case those boards anyway because of the issue Furquan mentioned.
I personally haven't seen a board crash in ramstage because of bad raminit, but random hangs and failure to resume from S3 can happen sometimes. But I'll eventually fix these problems. I'm cursed enough to understand the arcane magic of memory initialization ^^
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 22:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Or, alternatively, how about flipping NOMMAP_EARLY around into BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES?
+1. That makes sense. I think most future platforms would be okay with writes in early stages and so having that as default makes sense.
Hello build bot (Jenkins), Furquan Shaikh, Damien Zammit, Patrick Georgi, Martin Roth, Angel Pons, Julius Werner, Patrick Rudolph,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#23).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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.
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 --- M src/cpu/intel/haswell/Kconfig M src/cpu/intel/model_2065x/Kconfig M src/cpu/intel/model_206ax/Kconfig M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c M src/drivers/spi/Kconfig M src/northbridge/intel/x4x/Kconfig M src/soc/amd/picasso/Kconfig M src/soc/amd/stoneyridge/Kconfig M src/soc/intel/alderlake/Kconfig M src/soc/intel/apollolake/Kconfig M src/soc/intel/baytrail/Kconfig M src/soc/intel/braswell/Kconfig M src/soc/intel/broadwell/Kconfig M src/soc/intel/cannonlake/Kconfig M src/soc/intel/denverton_ns/Kconfig M src/soc/intel/elkhartlake/Kconfig M src/soc/intel/icelake/Kconfig M src/soc/intel/jasperlake/Kconfig M src/soc/intel/skylake/Kconfig M src/soc/intel/tigerlake/Kconfig M src/soc/intel/xeon_sp/Kconfig 22 files changed, 128 insertions(+), 57 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/23
Hello build bot (Jenkins), David Guckian, Furquan Shaikh, Damien Zammit, Patrick Georgi, Martin Roth, Vanessa Eusebio, Angel Pons, Julius Werner, Andrey Petrov, Patrick Rudolph,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#24).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 --- M src/cpu/intel/haswell/Kconfig M src/cpu/intel/model_2065x/Kconfig M src/cpu/intel/model_206ax/Kconfig M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c M src/drivers/spi/Kconfig M src/northbridge/intel/x4x/Kconfig M src/soc/amd/picasso/Kconfig M src/soc/amd/stoneyridge/Kconfig M src/soc/intel/alderlake/Kconfig M src/soc/intel/apollolake/Kconfig M src/soc/intel/baytrail/Kconfig M src/soc/intel/braswell/Kconfig M src/soc/intel/broadwell/Kconfig M src/soc/intel/cannonlake/Kconfig M src/soc/intel/denverton_ns/Kconfig M src/soc/intel/elkhartlake/Kconfig M src/soc/intel/icelake/Kconfig M src/soc/intel/jasperlake/Kconfig M src/soc/intel/skylake/Kconfig M src/soc/intel/tigerlake/Kconfig M src/soc/intel/xeon_sp/Kconfig 22 files changed, 128 insertions(+), 57 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/24
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 24:
(2 comments)
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/mrc_cache/Kcon... File src/drivers/mrc_cache/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/mrc_cache/Kcon... PS24, Line 45: later to MRC_CACHE. Probably we should add: This is selected for platforms which either do not support writes to SPI flash in early stages()BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES) or the platforms that need to write back the MRC data in late ramstage boot states(MRC_WRITE_NV_LATE).
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig File src/drivers/spi/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig@45 PS24, Line 45: BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES Addition of this Kconfig should be its own separate CL along with selecting it for platforms that need it.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 24:
(2 comments)
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 120:
nit: irrelevant change.
This was not aligned before and now it's aligned.
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig File src/drivers/spi/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig@45 PS24, Line 45: BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES
Addition of this Kconfig should be its own separate CL along with selecting it for platforms that ne […]
Do you just want a CL with the config and the platforms selecting it in a CL prior to the romstage writeback CL (basically a no-op)? Is it weird for platforms to be selecting a config that doesn't do anything?
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 24:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig File src/drivers/spi/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig@45 PS24, Line 45: BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES
Do you just want a CL with the config and the platforms selecting it in a CL prior to the romstage w […]
Yeah, basically a CL that adds the config BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES which is selected by platforms that need it so that BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY does not get selected for those platforms. You can drop the direct selection of BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY for other platforms in the same CL since the config selection would be redundant. This forms one logical unit.
And finally a CL for MRC changes. This is another logical unit.
It is not weird since the config being added must ensure that there are no functional changes. It is being done to make it easier going forward for platforms to have BOOT_DEVICE_SPI_FLASH_RW_NOMMAP enabled in early stages. So, it should be kept in a change of its own.
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 24:
(9 comments)
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 314: struct
const struct
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 326: BIOS_INFO
nit: still not BIOS_ERR... […]
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 337: (
If need_update is set to true above, there is no need to compare the data. […]
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 422: new_md, : new_data, new_data_size)
nit: I think this might fit on a single line with 96-column limit?
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 442: BIOS_DEBUG
Here too, errors like these should really all use BIOS_ERR.
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 593: (void *)
nit: unnecessary cast, cbmem_entry_start() already returns (void *)
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 594:
nit: bad alignment? (don't use spaces unless you're aligning it to something specific, which I don't […]
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 602: MRC_WRITE_NV_LATE
As per the latest comment, this will have to be MRC_STASH_TO_CBMEM
Done
https://review.coreboot.org/c/coreboot/+/44196/22/src/drivers/mrc_cache/mrc_... PS22, Line 636: MRC_WRITE_NV_LATE
MRC_STASH_TO_CBMEM
Done
Hello build bot (Jenkins), Furquan Shaikh, David Guckian, Damien Zammit, Patrick Georgi, Martin Roth, Vanessa Eusebio, Angel Pons, Julius Werner, Andrey Petrov, Patrick Rudolph,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#25).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 --- M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c M src/soc/intel/braswell/Kconfig 3 files changed, 118 insertions(+), 45 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/25
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(2 comments)
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/mrc_cache/Kcon... File src/drivers/mrc_cache/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/mrc_cache/Kcon... PS24, Line 45: later to MRC_CACHE.
Probably we should add: […]
Done
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig File src/drivers/spi/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/24/src/drivers/spi/Kconfig@45 PS24, Line 45: BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES
Yeah, basically a CL that adds the config BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES which is selected by […]
CL BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config here: https://review.coreboot.org/c/coreboot/+/45740/
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Or, alternatively, how about flipping NOMMAP_EARLY around into BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRIT […]
Done
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
There are some legacy Intel platforms which when executing out of memory mapped SPI flash did not allow writing back to it.
Does anybody know details about this? any reference? Was this with Chromebooks? We have CONSOLE_SPI_FLASH today and I haven't heard of any hardware issue with it on older platforms.
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
There are some legacy Intel platforms which when executing out of memory mapped SPI flash did not […]
+Duncan and +Subrata in case they remember.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
+Duncan and +Subrata in case they remember.
Thanks. In the meantime: tested flash console on ICH9-M, looks perfect from the bootblock :) SPI support doesn't go much further back, I'll try to get some feedback on ICH7.
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 25:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Thanks. In the meantime: tested flash console on ICH9-M, looks perfect […]
Thanks for testing this out Nico! This is very helpful.
If we don't really have problems with writing to flash in early stages on any platform, then I think we should deprecate BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY. We can also send out a PSA on the mailing list to indicate that this change is coming up and ensure it doesn't cause silent regressions for anyone.
Let's wait for feedback on ICH7 and also to hear back from Duncan/Subrata.
Hello build bot (Jenkins), Furquan Shaikh, Patrick Georgi, Duncan Laurie, Subrata Banik, Angel Pons, Julius Werner, Andrey Petrov, Patrick Rudolph, David Guckian, Damien Zammit, Martin Roth, Vanessa Eusebio,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#27).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 --- M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c M src/soc/intel/braswell/Kconfig 3 files changed, 118 insertions(+), 45 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/27
Duncan Laurie has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 27:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Thanks for testing this out Nico! This is very helpful. […]
It was more of a 'not documented/recommended' so not something we wanted to do in a shipping product back then. We aren't shipping these older chipsets anymore so coreboot can be more flexible.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 27:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
It was more of a 'not documented/recommended' so not something we wanted to do in a shipping product […]
Thanks. Is it documented for newer chipsets?
We theorized a bit on IRC about this. There is a potential race when the code of the loop that waits for the write to finish isn't cached. No idea if that is a problem, or if the CPU would just wait until the code can be delivered.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 27:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
Thanks. Is it documented for newer chipsets? […]
The problem is worse when one thinks about software sequencing which we used on some platforms (I guess until Intel shut it down with SKL), and have to use on pre-ME-enforced platforms. So there is definitely more to test.
I suggest that you go on with this and we bring older platforms up to speed one by one. We just have to make sure that the Kconfig changes don't break the flash console.
Duncan Laurie has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 27:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/44196/8//COMMIT_MSG@16 PS8, Line 16: Updating spi driver Kconfig to set : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y if both : BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y and BOOT_DEVICE_SPI_FLASH=y to bring : the appropriate libraries into romstage.
The problem is worse when one thinks about software sequencing […]
Ya I think it was when software sequencing disappeared that we got some sort of confirmation (might have just been in a meeting) that it should be safe. I can't seem find it documented in the usual suspects now but the documentation gets thinner each generation.
Hello build bot (Jenkins), Furquan Shaikh, Patrick Georgi, Duncan Laurie, Subrata Banik, Angel Pons, Julius Werner, Andrey Petrov, Patrick Rudolph, David Guckian, Damien Zammit, Martin Roth, Vanessa Eusebio,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/44196
to look at the new patch set (#28).
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 --- M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c M src/soc/intel/braswell/Kconfig 3 files changed, 118 insertions(+), 45 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/96/44196/28
Shelley Chen has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 29:
(2 comments)
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... File src/drivers/mrc_cache/mrc_cache.c:
https://review.coreboot.org/c/coreboot/+/44196/7/src/drivers/mrc_cache/mrc_c... PS7, Line 384: cr = lookup_region(®ion, type);
nit: might be easier to just pass in *cr instead of type because all the callers already have that.
I think that we can clean this up at a later time, but with the timeline now to get this completed in the next couple of week, I'd like to push this CL in sooner rather than later if you're ok with that.
https://review.coreboot.org/c/coreboot/+/44196/8/src/mainboard/google/cyan/K... File src/mainboard/google/cyan/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/8/src/mainboard/google/cyan/K... PS8, Line 15: MRC_WRITE_NV_LATE
Increased the DRAM cache ram size to 0x5000 and it compiled. I still need to test this out.
Moving DRAM cache ram size bump to: https://review.coreboot.org/c/coreboot/+/45827/
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 29: Code-Review+2
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 29:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... File src/drivers/mrc_cache/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... PS29, Line 29: MRC_WRITE_NV_LATE Does this option make sense to anyone? I find boot-state hooks already pretty hard to follow, this makes it even harder. It says some platforms may require to write it later... but do other platforms require it earlier?
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 29:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... File src/drivers/mrc_cache/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... PS29, Line 29: MRC_WRITE_NV_LATE
Does this option make sense to anyone? I find boot-state hooks already pretty […]
There is only one platform that is actually using this - Stoneyridge. And the change that added the Kconfig only says that the current boot state is too early: https://review.coreboot.org/c/coreboot/+/22937. From the comments on that and related CLs, it looks like probably the data is not really available by then. But, I don't really know if there are other issues as well.
As for other platforms - Intel, this needs to be done before the PRR lockdown happens. So, that is the reason for not moving Intel platforms to do these later.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
Patch Set 31:
(1 comment)
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... File src/drivers/mrc_cache/Kconfig:
https://review.coreboot.org/c/coreboot/+/44196/29/src/drivers/mrc_cache/Kcon... PS29, Line 29: MRC_WRITE_NV_LATE
There is only one platform that is actually using this - Stoneyridge. […]
Thanks :) I did not expect this. I could ask why we lock things down before the finalize phase, but I probably don't want to know oO
Shelley Chen has submitted this change. ( https://review.coreboot.org/c/coreboot/+/44196 )
Change subject: mrc_cache: Update mrc_cache data in romstage ......................................................................
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 --- M src/drivers/mrc_cache/Kconfig M src/drivers/mrc_cache/mrc_cache.c 2 files changed, 117 insertions(+), 44 deletions(-)
Approvals: build bot (Jenkins): Verified Furquan Shaikh: Looks good to me, approved
diff --git a/src/drivers/mrc_cache/Kconfig b/src/drivers/mrc_cache/Kconfig index 79cc205..e09c5d8 100644 --- a/src/drivers/mrc_cache/Kconfig +++ b/src/drivers/mrc_cache/Kconfig @@ -35,4 +35,18 @@ normal, select this item. This will cause the write to occur at BS_OS_RESUME_CHECK-ENTRY.
+config MRC_STASH_TO_CBMEM + bool + default y if MRC_WRITE_NV_LATE || BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES + default n + help + Instead of writing back MRC_CACHE training data back to the + MRC_CACHE right away, stash the data into cbmem. This data + will be written back later to MRC_CACHE. This is selected + for platforms which either do not support writes to SPI + flash in early stages + (BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES) or the platforms + that need to write back the MRC data in late ramstage boot + states (MRC_WRITE_NV_LATE). + endif # CACHE_MRC_SETTINGS diff --git a/src/drivers/mrc_cache/mrc_cache.c b/src/drivers/mrc_cache/mrc_cache.c index 00652ac..d2991ac 100644 --- a/src/drivers/mrc_cache/mrc_cache.c +++ b/src/drivers/mrc_cache/mrc_cache.c @@ -117,7 +117,7 @@
if (cr == NULL) { printk(BIOS_ERR, "MRC: failed to locate region type %d.\n", - type); + type); return NULL; }
@@ -311,18 +311,30 @@ }
static bool mrc_cache_needs_update(const struct region_device *rdev, - const struct cbmem_entry *to_be_updated) + const struct mrc_metadata *new_md, + const void *new_data, size_t new_data_size) { - void *mapping; + void *mapping, *data_mapping; size_t size = region_device_sz(rdev); bool need_update = false;
- if (cbmem_entry_size(to_be_updated) != size) + if (new_data_size != size) return true;
mapping = rdev_mmap_full(rdev); + if (mapping == NULL) { + printk(BIOS_ERR, "MRC: cannot mmap existing cache.\n"); + return true; + } + data_mapping = mapping + sizeof(struct mrc_metadata);
- if (memcmp(cbmem_entry_start(to_be_updated), mapping, size)) + /* we need to compare the md and the data separately */ + /* check the mrc_metadata */ + if (memcmp(new_md, mapping, sizeof(struct mrc_metadata))) + need_update = true; + + /* check the data */ + if (!need_update && memcmp(new_data, data_mapping, new_data_size)) need_update = true;
rdev_munmap(rdev, mapping); @@ -357,7 +369,10 @@ * read and write. The read assumes a memory-mapped boot device that can be used * to quickly locate and compare the up-to-date data. However, when an update * is required it uses the writeable region access to perform the update. */ -static void update_mrc_cache_by_type(int type) +static void update_mrc_cache_by_type(int type, + struct mrc_metadata *new_md, + const void *new_data, + size_t new_data_size) { const struct cache_region *cr; struct region region; @@ -365,7 +380,6 @@ struct region_device write_rdev; struct region_file cache_file; struct mrc_metadata md; - const struct cbmem_entry *to_be_updated; struct incoherent_rdev backing_irdev; const struct region_device *backing_rdev; struct region_device latest_rdev; @@ -376,13 +390,6 @@ if (cr == NULL) return;
- to_be_updated = cbmem_entry_find(cr->cbmem_id); - if (to_be_updated == NULL) { - printk(BIOS_ERR, "MRC: No data in cbmem for '%s'.\n", - cr->name); - return; - } - printk(BIOS_DEBUG, "MRC: Checking cached data update for '%s'.\n", cr->name);
@@ -411,7 +418,8 @@
return;
- if (!mrc_cache_needs_update(&latest_rdev, to_be_updated)) { + if (!mrc_cache_needs_update(&latest_rdev, + new_md, new_data, new_data_size)) { printk(BIOS_DEBUG, "MRC: '%s' does not need update.\n", cr->name); log_event_cache_update(cr->elog_slot, ALREADY_UPTODATE); return; @@ -419,10 +427,18 @@
printk(BIOS_DEBUG, "MRC: cache data '%s' needs update.\n", cr->name);
- if (region_file_update_data(&cache_file, - cbmem_entry_start(to_be_updated), - cbmem_entry_size(to_be_updated)) < 0) { - printk(BIOS_DEBUG, "MRC: failed to update '%s'.\n", cr->name); + struct update_region_file_entry entries[] = { + [0] = { + .size = sizeof(struct mrc_metadata), + .data = new_md, + }, + [1] = { + .size = new_data_size, + .data = new_data, + }, + }; + if (region_file_update_data_arr(&cache_file, entries, ARRAY_SIZE(entries)) < 0) { + printk(BIOS_ERR, "MRC: failed to update '%s'.\n", cr->name); log_event_cache_update(cr->elog_slot, UPDATE_FAILURE); } else { printk(BIOS_DEBUG, "MRC: updated '%s'.\n", cr->name); @@ -548,12 +564,46 @@ printk(BIOS_ERR, "MRC: invalidation failed for '%s'.\n", name); }
-static void update_mrc_cache(void *unused) +static void update_mrc_cache_from_cbmem(int type) { - update_mrc_cache_by_type(MRC_TRAINING_DATA); + const struct cache_region *cr; + struct region region; + const struct cbmem_entry *to_be_updated;
- if (CONFIG(MRC_SETTINGS_VARIABLE_DATA)) - update_mrc_cache_by_type(MRC_VARIABLE_DATA); + cr = lookup_region(®ion, type); + + if (cr == NULL) { + printk(BIOS_ERR, "MRC: could not find cache_region type %d\n", type); + return; + } + + to_be_updated = cbmem_entry_find(cr->cbmem_id); + + if (to_be_updated == NULL) { + printk(BIOS_INFO, "MRC: No data in cbmem for '%s'.\n", + cr->name); + return; + } + + update_mrc_cache_by_type(type, + /* pointer to mrc_cache entry metadata header */ + cbmem_entry_start(to_be_updated), + /* pointer to start of mrc_cache entry data */ + cbmem_entry_start(to_be_updated) + + sizeof(struct mrc_metadata), + /* size of just data portion of the entry */ + cbmem_entry_size(to_be_updated) - + sizeof(struct mrc_metadata)); +} + +static void finalize_mrc_cache(void *unused) +{ + if (CONFIG(MRC_STASH_TO_CBMEM)) { + update_mrc_cache_from_cbmem(MRC_TRAINING_DATA); + + if (CONFIG(MRC_SETTINGS_VARIABLE_DATA)) + update_mrc_cache_from_cbmem(MRC_VARIABLE_DATA); + }
if (CONFIG(MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN)) invalidate_normal_cache(); @@ -562,11 +612,9 @@ }
int mrc_cache_stash_data(int type, uint32_t version, const void *data, - size_t size) + size_t size) { const struct cache_region *cr; - size_t cbmem_size; - struct mrc_metadata *md;
cr = lookup_region_type(type); if (cr == NULL) { @@ -575,24 +623,36 @@ return -1; }
- cbmem_size = sizeof(*md) + size; + struct mrc_metadata md = { + .signature = MRC_DATA_SIGNATURE, + .data_size = size, + .version = version, + .data_checksum = compute_ip_checksum(data, size), + }; + md.header_checksum = + compute_ip_checksum(&md, sizeof(struct mrc_metadata));
- md = cbmem_add(cr->cbmem_id, cbmem_size); + if (CONFIG(MRC_STASH_TO_CBMEM)) { + /* Store data in cbmem for use in ramstage */ + struct mrc_metadata *cbmem_md; + size_t cbmem_size; + cbmem_size = sizeof(*cbmem_md) + size;
- if (md == NULL) { - printk(BIOS_ERR, "MRC: failed to add '%s' to cbmem.\n", - cr->name); - return -1; + cbmem_md = cbmem_add(cr->cbmem_id, cbmem_size); + + if (cbmem_md == NULL) { + printk(BIOS_ERR, "MRC: failed to add '%s' to cbmem.\n", + cr->name); + return -1; + } + + memcpy(cbmem_md, &md, sizeof(*cbmem_md)); + /* cbmem_md + 1 is the pointer to the mrc_cache data */ + memcpy(cbmem_md + 1, data, size); + } else { + /* Otherwise store to mrc_cache right away */ + update_mrc_cache_by_type(type, &md, data, size); } - - memset(md, 0, sizeof(*md)); - md->signature = MRC_DATA_SIGNATURE; - md->data_size = size; - md->version = version; - md->data_checksum = compute_ip_checksum(data, size); - md->header_checksum = compute_ip_checksum(md, sizeof(*md)); - memcpy(&md[1], data, size); - return 0; }
@@ -600,9 +660,8 @@ * Ensures MRC training data is stored into SPI after PCI enumeration is done. * Some implementations may require this to be later than others. */ - #if CONFIG(MRC_WRITE_NV_LATE) -BOOT_STATE_INIT_ENTRY(BS_OS_RESUME_CHECK, BS_ON_ENTRY, update_mrc_cache, NULL); +BOOT_STATE_INIT_ENTRY(BS_OS_RESUME_CHECK, BS_ON_ENTRY, finalize_mrc_cache, NULL); #else -BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_EXIT, update_mrc_cache, NULL); +BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_EXIT, finalize_mrc_cache, NULL); #endif