Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35026 )
Change subject: soc/intel/{cnl, icl}: Cache the TSEG region ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
#2 With POSTCAR_STAGE=y and (CB:34995 + CB: 35026) [romstage -> postcar -> ramstage]
Aug 23
Total Time: 818,078
Total Time till picking kernel: 818,078 Total Time till picking payload: 639,809
For this commit 36b7091 exactly, I want to see full 'cbmem -t' data as I am trying to figure out the mystery of timestamp 1100, where we seem to consistently loose 10ms if we gained 7ms earlier.
0:1st timestamp 12,859 4:end of romstage 306,148 (1,829) 10:start of ramstage 333,225 (338) 30:device enumeration 378,839 (45,614) 99:selfboot jump 652,668 (469) 1100:finished vboot kernel verification 828,455 (147,282) 1101:jumping to kernel 830,962 (2,506)
Total Time: 818,078
As expected, and this is the mystery: Howcome entry 1100 in payload is increased by 10ms with an MTRR change we made in postcar? MTRRs are reprogrammed around timestamp 30 and there is cacheline invalidation (wbinvd call) at about the same time. Maybe some cachelines are stuck in non-evict mode and not available while executing 1100.
This would become the fastest approach we have seen so far if you solve 1100. Top of dram as WC/WP instead of WB? If that worked this would also be the simplest approach in comparison to any intermediate caching or POSTCAR_STAGE=n commits. And sorry, no, I have not had time to dig deeper into why you want to choose WP over WB, but definetly worth testing those. Just don't get any set_var_mtrr() calls involved yet if you experiment with it.