[coreboot] How to improve the boot time of the Asus KGPE-D16?

[Timothy Pearson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
>>>>
>>>>    1. Do board owners with similar amount of memory (independent of the
>>>>       board) have similar numbers?
>>>>    2. 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.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYuIB4AAoJEK+E3vEXDOFb4JUH+wQU4BjxwRZ0+DhI1z9yIQEU
A5dyWhWWEjEkDkk58haEHKi3F4XkKUtaOFkA8GD4M+Zdmscu6ntBKw8MrjqhQKPS
zFlru8/pN9zVRDBo6nnPyY0AJTr3sUTqFiQYP7BbMPvl/B5soGP/Fz/mPeBBeb6e
NLhFK9rkjY2mnj2r5HySCxyeY0Es+SQYVQoCfZbxBY/tMrMWKn9gEXKasmj7hRn7
6QSOq4TisZGQ9S1uQ4iAjgLJ+dK1WHweGrO0qew7AEoeGK1v+uHRomsDhXj78T2k
23Q2CZGnXZhwJAx31YeunxviKa+4j14FywE+vHLVY8sMkVHV+KXCOqFIqFFlm7I=
=9nkJ
-----END PGP SIGNATURE-----