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

[Timothy Pearson]

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

On 03/02/2017 01:18 PM, Paul Menzel via coreboot wrote:
> Dear coreboot folks,
> 
> 
> With 128 GB of RAM consisting of eight 16 GB modules, coreboot takes
> over a minute to get to the payload on the Asus KGPE-D16 even without
> serial console enabled [1]. This is not much faster than the vendor
> firmware.
> 
> Please note that the timings below are incorrect. Comparing it with the
> timings from SeaBIOS’ `script/read_serial.py`, I’d say the time values
> need to be multiplied by two. (Somebody mentioned, that the reason
> might be `cbmem -t` using some scaling factor to convert the time
> stamps to seconds, and that might be wrong on the board.)
> 
> ```
> $ more asus/kgpe-d16/4.5-1093-g308aeff/2017-03-01T16_03_07Z/coreboot_timestamps.txt
> 21 entries total:
> 
>    0:1st timestamp                                     24,384
>    1:start of rom stage                                25,061 (676)
>    2:before ram initialization                         913,502 (888,441)
>    3:after ram initialization                          35,548,889 (34,635,386)
>    4:end of romstage                                   35,642,960 (94,070)
>    8:starting to load ramstage                         35,647,351 (4,391)
>   15:starting LZMA decompress (ignore for x86)         35,647,872 (520)
>   16:finished LZMA decompress (ignore for x86)         35,695,864 (47,991)
>    9:finished loading ramstage                         35,696,312 (447)
>   10:start of ramstage                                 35,696,893 (581)
>   30:device enumeration                                35,696,897 (3)
>   40:device configuration                              36,639,627 (942,730)
>   50:device enable                                     36,644,848 (5,221)
>   60:device initialization                             36,646,012 (1,163)
>   70:device setup done                                 37,044,848 (398,836)
>   75:cbmem post                                        37,044,850 (1)
>   80:write tables                                      37,044,851 (1)
>   85:finalize chips                                    37,053,950 (9,099)
>   90:load payload                                      37,324,647 (270,697)
>   15:starting LZMA decompress (ignore for x86)         37,325,042 (395)
>   16:finished LZMA decompress (ignore for x86)         37,349,321 (24,278)
>   99:selfboot jump                                     37,349,328 (7)
> ```
> 
> 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)?
> 
> 
> Thanks,
> 
> Paul
> 
> 
> [1] https://review.coreboot.org/cgit/board-status.git/commit/?id=4b4b7ab5865b15ae7caa43f0a99a80772818090f
> 

The issue isn't probing; the delays are introduced in both DRAM training
(DDR3 training is quite complex and involves repeatedly streaming
pseudorandom data to/from the modules at full speed) and in the
mandatory clearing of the ECC check bits.

The only way to feasibly decrease boot time would be to run the DRAM
training on each CPU package (and possibly memory controller, though I
don't think that's a good idea) in parallel.  This, in turn, couples
with previous discussions on whether coreboot, and in particular
coreboot's romstage, should even be attempting to provide a
multi-tasking environment; i.e. does the added complexity provide a
significant enough benefit to justify the maintenance overhead?

- -- 
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/

iQEcBAEBAgAGBQJYuHIzAAoJEK+E3vEXDOFbr4YH/2c74mr+eTlSM63yfBF9DbSX
aTy795FQ+aKeJdAe+UUlIM25L+HxNbbsctH3fRNA1OgmFrrXtIenpQZlVItBE09l
YZUp/+WDgDOkuIxJ8+2NKnU8i3cOHN2uIFKs1fyEenrTMXZBvOcXbV+tnJ54VJJ5
ISCKAlJcvZGs4HGdVhkx1RoN3S77kTrLkRhi6+2Zj1HN8KcawGfl99qOfXQ3TY1A
9+n3K8PjtRcQXN23OI2DdO+Vc9JFuVA7uyIXJdmWDV35dcc1p9wK1QZRyn5vMU9p
l9fvpNxn1Emf7p30L01Anx0m/ihlP0Qfx8QC11L4YpQMaDloAjOy3IAdt3v87LU=
=Dzfn
-----END PGP SIGNATURE-----