Hi,
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Cheers, Daniel
P.S. Hope this time I've set the Reply-To header correctly.
On 03/02/2017 02:17 PM, Paul Menzel wrote:
Dear Arthur, dear Timothy,
Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
On 03/02/2017 01:30 PM, Arthur Heymans wrote:
Paul Menzel writes:
I think most of the time is spent in RAM initialization.
- Do board owners with similar amount of memory (independent of the board) have similar numbers?
- What are the ways to improve that? Is it possible? For example, can the modules be probed in parallel (if that isn?t done already)?
I'm not the right person to answer this since I don't know this code/hardware that well, but on modern Intel hardware native code uses the MRC cache to store dram training results and restore those on next boots (and resume from suspend) if no change in dimm configuration was detected.
Maybe something like this could also be applied here (or maybe it's already the case since it includes code to access spi flash)?
Yes, this is already implemented as an option, and it does a fairly decent job of reducing training overhead to almost nothing,
Interesting. What option is that?
Also, besides the file `s3nv` I don?t see anything else in CBFS. Where is the training data cached?
That's it. The cache is mandatory for S3 resume, and optional at boot.
That being said, the pathways are present but are deactivated due to historical instability and are not tied in to an nvram variable at this time. If you want to test, you'll need to edit the source file "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see a FIXME comment and this line:
allow_config_restore = 0;
Comment that line out and recompile to test. I strongly suggest running memtest across multiple warm and cold boots (and reboots) before determining the functionality is stable enough for use.
On 03/15/2017 04:09 PM, Daniel Kulesz via coreboot wrote:
Hi,
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Cheers, Daniel
You will need NVRAM enabled for this setting to work. Additionally, there is some instability when this line is uncommented; when I have some free time available I'll take another look at why.
Thanks!
On Wed, 15 Mar 2017 16:17:31 -0500 Timothy Pearson tpearson@raptorengineering.com wrote:
On 03/15/2017 04:09 PM, Daniel Kulesz via coreboot wrote:
Hi,
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Cheers, Daniel
You will need NVRAM enabled for this setting to work. Additionally, there is some instability when this line is uncommented; when I have some free time available I'll take another look at why.
Many thanks - this did the trick! Boot time decreased from 71s to 30s now. Finally, coreboot boots up twice as fast as the vendor bios on the KGPE-D16!
@Timothy: Regarding the mentioned instability: Have you tested for its presence after we applied this "revert fix" for the MCT failures? I've been running "memtester 10G" + "stress-ng --cpu 0" for around 20 minutes now but could not observe any failures, instabilities or dmesg entries so far.
@Paul: Have you tried this setting as well? If yes - would you like to share your experience?
Cheers, Daniel
Dear Daniel,
Am Mittwoch, den 15.03.2017, 22:09 +0100 schrieb Daniel Kulesz:
[…]
P.S. Hope this time I've set the Reply-To header correctly.
Note, that you need to set the *In-Reply-To* header field. The field *Reply-To* contains the address used as recipient, when you reply to the message.
Thanks,
Paul
Hello! I'd like to ask if there will be any libreboot install event soon in Berlin (or any in the planning). I'm looking for help to install libreboot on my computer. thank you all!