Aaron Durbin (adurbin@chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/10880
-gerrit
commit 859f5ba16727fdffdea12cb3ad7c3f627ffbf978 Author: Aaron Durbin adurbin@chromium.org Date: Fri Jul 10 01:51:14 2015 -0500
timestamps: don't drop ramstage timestamps with EARLY_CBMEM_INIT
While running ramstage with the EARLY_CBMEM_INIT config the timestamp cache was re-initialized and subsequently used. The result was that the ramstage timestamps would be dropped from cbmem. The reason is that the ramstage timestamps perpetually lived in ramstage BSS never getting sync'd back into cbmem. The fix is to honor the cache state in ramstage in the timestamp_init() path.
TEST=Used qemu-armv7 as a test harness with debugging info.
Change-Id: Ibb276e513278e81cb741b1e1f6dbd1e8051cc907 Signed-off-by: Aaron Durbin adurbin@chromium.org --- src/lib/timestamp.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/lib/timestamp.c b/src/lib/timestamp.c index 51e63b2..7ead383 100644 --- a/src/lib/timestamp.c +++ b/src/lib/timestamp.c @@ -34,7 +34,7 @@ #define MAX_TIMESTAMP_CACHE 16
struct __attribute__((__packed__)) timestamp_cache { - int cache_state; + uint32_t cache_state; struct timestamp_table table; /* The struct timestamp_table has a 0 length array as its last field. * The following 'entries' array serves as the storage space for the @@ -199,6 +199,13 @@ void timestamp_init(uint64_t base) return; }
+ /* In the EARLY_CBMEM_INIT case timestamps could have already been + * recovered. In those circumstances honor the cache which sits in BSS + * as it has already been initialized. */ + if (ENV_RAMSTAGE && + ts_cache->cache_state != TIMESTAMP_CACHE_UNINITIALIZED) + return; + timestamp_cache_init(ts_cache, base); }