Patch Set 6:
Patch Set 5:
Patch Set 5:
Patch Set 5:
Patch Set 4:
My test results for KBL:
memsetting 1GiB of memory with different MTRR settings in NEM right after raminit:do_fsp_post_memory_init: took 9180 msec to clear 1GiB UC
do_fsp_post_memory_init: took 9179 msec to clear 1GiB WPROT
do_fsp_post_memory_init: took 39 msec to clear 1GiB WRCOMB
do_fsp_post_memory_init: took 76 msec to clear 1GiB WRBACKThe use of WRBACK in NEM causes postcar stage loading to fail. The use of WRCOMB seems fine, it still boots.
HI Patrick, are you really sure that WC took least time between all MTRR types. As per SDM, WC is not for read/write cacheable. btw, which address range you tried ?
Yes WC was the fastest, it's measured using timer_monotonic_get(). I memset memory from 32MiB to 1GiB+32MiB.
I guess WC is best for writing large chunks of memory. For postcar caching it might not be the best choice.I'll do more tests on older platforms as I remember that those behave in a different way.
Thanks for prompt reply.
>> For postcar caching it might not be the best choice.
This is my understanding as well. i could see WP is more applicable in terms of savings than WC. Best optimization is with WB.
boot time numbers are
romstage -> ramstage [with intermediate caching as WB] = ~810ms
romstage -> ramstage [with intermediate caching as WP] = ~820ms
romstage -> ramstage [with intermediate caching as WC] = ~880ms
We are able to make WB working as intermediate caching with some code changes and assumptions. (without those hang as you might have seen earlier with WB). But we (me and Aaron) are not 100% sure if we should make those changes by the assumptions to make WB work.I have made intermediate DRAM caching range as WP based on our experiments. Although i will still submit the require changes to enable DRAM ranges WB as well.
https://review.coreboot.org/q/topic:%22dram_cache_wb%22+(status:open%20OR%20status:merged) approach to make WB work
To view, visit change 34805. To unsubscribe, or for help writing mail filters, visit settings.