XMPDetection <key> produces no output in boot log?

[mackonsti]

Hi everyone, thanks again for your commitment and hard work! I have a rather strange question as I cannot see if something works or not.

In my config (currently running Clover r5107 but also on r5118 on another hackintosh) the parameter <key>XMPDetection</key> if set to </true> or <string>Yes</string> does not produce any debug output at all in the Clover boot-log that I can quickly access via Hackintool.

On my Intel NUC8i7BEH there are no BIOS options to check for, or select XMP Profiles like there is on my MSI Z97i-AC board, for example, but I know that my HyperX RAM does have an XMP Profile.

Am I supposed to get logs if the BIOS firmware doesn't bother about XMP Profiles?

Is it normal to get absolutely no XMPDetection results in the boot log? Can you please comment on this, or kindly check if it's broken? I am not expecting with </false> or <string>No</string> to show something obviously, but at least enabling it would allow me to see what is the result.

Unless you suggest I set it as <integer>1</integer> or 2 instead? What's the difference between setting the <integer> and <true> ? Force-detect versus auto-detect?

Thanks in advance!

[jief666]

I know almost nothing about that, but looking at the code, I can say : "<true>" is invalid value. It should be "<true/>"; but in both case it should use detected profile 1 or 2 depending of the frequency. A message "Using XMP Profile[1 or 2] instead of standard frequency..." should displayed.

If no profile, you should see "Not using XMP because it is not present".

Value 1 will force using profile 1, 2 use profile 2. A message should also being displayed.

Anyway you should see a message. I can send you a version with more debug messages to understand what's going on. But first, please send a debug.log file and your config.plist.

[mackonsti]

Hi @jief666 thanks for replying. I am sorry the <true/> value was mis-typed by hand above, the config.plist was validated with your validator tool so this was not an issue (and still is not, as I checked the value myself).

I am running Clover r5131 master (commit 949da631b) and on Hackintool boot logs, that are easy to access, I can only see this as XMP reference:

0:739  0:000  === [ ScanSPD ] =================================
0:739  0:000  Scanning SMBus [8086:9DA3], mmio: 0x4A116004, ioport: 0xEFA0, hostc: 0x11
0:757  0:018  Found module with XMP version 2.0
0:757  0:000  Slot: 0 Type 26 8192MB 2400MHz Vendor=Kingston PartNo=KHX2400C14S48G SerialNo=XXXXXXXX
0:775  0:018  Found module with XMP version 2.0
0:775  0:000  Slot: 2 Type 26 8192MB 2400MHz Vendor=Kingston PartNo=KHX2400C14S48G SerialNo=XXXXXXXX
0:776  0:000  === [ GetAcpiTablesList ] =======================

My concern was that it seems only detected and nothing else happens. Nothing reported of having changed or used etc. So not sure if XMP is enabled eventually... or the use of this Clover feature.

Also, there's no trace of the message you wrote, to be honest. Let me know what I can do to help, I can post post the preboot.log too if needed or use the test-version of Clover with more debug output. Thanks!

EDIT: Updated with your test-build of Clover and now I get the following result:

=== [ ScanSPD ] =================================
Scanning SMBus [8086:9DA3], mmio: 0x4A116004, ioport: 0xEFA0, hostc: 0x11
Found module with XMP version 2.0
Using XMP Profile1 instead of standard frequency 2400MHz
Slot: 0 Type 26 8192MB 2400MHz Vendor=Kingston PartNo=KHX2400C14S48G SerialNo=XXXXXXXX
Found module with XMP version 2.0
Using XMP Profile1 instead of standard frequency 2400MHz
Slot: 2 Type 26 8192MB 2400MHz Vendor=Kingston PartNo=KHX2400C14S48G SerialNo=XXXXXXXX
=== [ GetAcpiTablesList ] =======================

Is this expected behaviour? My NUC as platform accepts 2400MHz RAM modules so not sure if the use of XMP Profile(s) changes anything, as it is still reported as 2400MHz in System Information. But at least now it seems Clover does indeed do something.

[jief666]

Conclusion is that it was working, but without any trace. I've restored some trace in the log.