Hi Paul,
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)?
Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and experiencing a similar issue. With just two UDIMMs, the boot times are *much* faster. Also, the vendor BIOS is faster from the time you press the poweron button to the time the monitor gets a signal.
Cheers, Daniel
Dear Daniel,
Am Freitag, den 03.03.2017, 10:52 +0100 schrieb Daniel Kulesz:
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)?
Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and experiencing a similar issue. With just two UDIMMs, the boot times are *much* faster.
That’s good to hear. Do you have concrete numbers?
Also, the vendor BIOS is faster from the time you press the poweron button to the time the monitor gets a signal.
I believe that’s a design decision in coreboot, that the display can only be initialized after RAM has been initialized. The vendor firmware seems to be able to do it beforehand. (If I am wrong, the vendor firmware is really fast in configuring the memory.)
Thanks,
Paul
PS: Please note, your messages is not threaded correctly, as the mail header fields *In-Reply-To* and References are not set.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2017 04:14 PM, Paul Menzel via coreboot wrote:
Dear Daniel,
Am Freitag, den 03.03.2017, 10:52 +0100 schrieb Daniel Kulesz:
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)?
Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and experiencing a similar issue. With just two UDIMMs, the boot times are *much* faster.
That’s good to hear. Do you have concrete numbers?
Also, the vendor BIOS is faster from the time you press the poweron button to the time the monitor gets a signal.
I believe that’s a design decision in coreboot, that the display can only be initialized after RAM has been initialized. The vendor firmware seems to be able to do it beforehand. (If I am wrong, the vendor firmware is really fast in configuring the memory.)
The vendor firmware starts up the display while memory is still being configured. As far as I can tell, the graphical ASUS logo is loaded as part of the proprietary BIOS's romstage-equivalent component, while RAM is not initialized until that logo is removed from the display. You can test this for yourself by noting that the keyboard numlock will not respond while that logo is displayed, whereas it does respond afterward.
The proprietary BIOS likely uses a proprietary variant of the open AGESA code in the coreboot tree, and I see no reason its RAM initialization will be any faster (or slower) than the native RAM initialization currently used for the KGPE-D16 as both are based on the same BKDG and use the same general algorithms.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
-
Daniel Kulesz -
Paul Menzel -
Timothy Pearson