Intel to remedy heat for Apple’s new iMac Pro with special Xeon W SKU’s…

Previously I assumed that Apple was going to use one of these Xeon W models, but it turns out that I was wrong – based on new data that I found. Intel apparently makes special (OEM) SKU’s for Apple’s new iMac Pro, and here are the first two known models:

Intel Xeon W-2140B @ 3.2GHz ( 8 cores / 16 threads, CPUID 0x050654)
Intel Xeon W-2150B @ 3.0GHz (10 cores / 20 threads, CPUID 0x050654)

Both running with a lower base frequency than the W-2145 (3.7GHz) and W-2155 (3.3GHz). And there can only be one reason for this. Heat!

Source: Geekbench OpenCL Score 1 and 2
Note: Don’t you worry about the results. Apple isn’t showing it’s hand just yet – the used GPU’s were running at a lower frequency.

Additional data

The board-id that I found in the (assumed) firmware of the iMac Pro is: Mac-7BA5B2D9E42DDD94 and some of the data that I found earlier may be an indication that the new B serie processors include support for processor graphics (IGPU). Another key factor that contributes to the need for a lower base frequency.

Intel Speed Shift Technology

I disassembled the first High Sierra Beta XNU Kernel, months ago, and I found out that Intel Speed Shift Technology aka HWP is set to enabled for processors with CPUID 0x05065X. Like the Intel Xeon W-21NN series processors.

Internal Graphics

Back in June I was surprised to find a reference to “Integrated Video Controller” in the leaked firmware for the iMac Pro. Some time later I also found data in the info.plist of AppleGraphicsDevicePolicy.kext that shows us that Apple disables – note the unload key – the IGPU (the internal GPU). Look here:

<key>ConfigMap</key>
<dict>
    <key>Mac-77EB7D7DAF985301</key>
    <string>none</string>

That coupled with this snippet:

<key>Config4</key>
<dict>
    <key>GFX0</key>
    <dict>
        <key>EDID</key>
        <dict>
            <key>index</key>
            <integer>0</integer>
        </dict>
        <key>FeatureControl</key>
        <integer>12</integer>
        <key>unload</key>
        <false/>
    </dict>
    <key>IGPU</key>
    <dict>
        <key>unload</key>
        <true/>
    </dict>
    <key>display</key>
    <dict>
        <key>EDID</key>
        <dict>
            <key>index</key>
            <integer>0</integer>
        </dict>
        <key>FeatureControl</key>
        <integer>12</integer>
        <key>unload</key>
        <false/>
    </dict>
</dict>

This may well be an indication that the new Intel Xeon’s do in fact support processor graphics, but we will have to wait until the actually release of the iMac Pro, or macOS High Sierra 10.13.2 (which Apple appears to be using internally already) before we really know what is going on here.

Edit: If you use my blog article as source, then please be so kind to add a link/reference. Thank you.

Don’t be an ass. Like mac4ever.com for the lack of reference (shame on you) because seriously guys… as a die hard Googler, nobody else blogged about it before I did!

Advertisements

31 thoughts on “Intel to remedy heat for Apple’s new iMac Pro with special Xeon W SKU’s…

  1. Hi Piker, im using now 10.13.1 (17B35A)
    Still not able to boot with 0x050654 (Thats my native CPUID of 7900x)
    (It hangs on Aptiofix… Nvram…)
    Just for the Info 🙂

    Cheers 🙂

      • yes, 0x0506E4
        Everything else I tried so far, doesn’t boot… doesn’t pass nvram… or kernel init?
        Something at the very beginning of booting…

        Cheers 🙂

      • Your i9-7900X does not support Intel® Speed Shift Technology aka HWP, but that will be set to enabled for processors with CPUID 0x05065X. Look here:

        loc_ffffff80003a6a3c:
        ffffff80003a6a3c         mov        dword [_xcpm_cpu_model], 0x4000             ; case 25, CODE XREF=_xcpm_bootstrap+124
        ffffff80003a6a46         mov        dword [_xcpm_config+204], 0x0
        ffffff80003a6a50         mov        qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b         mov        dword [_xcpm_config+560], 0x1
        ffffff80003a6a65         mov        dword [_xcpm_hwp_enabled], 0x1
        ffffff80003a6a6f         jmp        loc_ffffff80003a6a85
        

        Try NOP’ing out that last move, or use 0.

      • Piker, you mean to replace that in the kernel?
        Like:

        Name: _xcpm_hwp_enabled (disable)
        Find: ffffff80003a6a65
        Replace: ffffff8000909090

        Do i understood you right?

        If yes, i will test later and report 🙂
        Thank you very much!

      • Hi again,
        I can pass OsxAptioFixDrv (Nvram),
        which I normally can’t with 0x050654

        But it hangs on:
        Macos is not supported on this System, Reason:
        Mac-7BA5B2D9E42DDD94

        So I can’t boot with iMacPro SMBIOS… on 10.13.1 Update 2

        With the HWP,
        I don’t get you, why do I need to NOP out, if its supported on 7900x?
        I need to look inside the bios files of the rampage with amibcp for speed shift and CSR 0xE2 entrys…

        The other thing is, ive searched in the Kernel for ffffff80003a6a65…
        I can’t find the entry in the 10.13.1 kernel…
        The only thing I found is at offset 11654232 (_xcpm_hwp_enabled) the text only…

        Cheers Piker 🙂

      • Ah ok so you are using an unsupported board-id (Mac-7BA5B2D9E42DDD94). That won’t work. Not yet. For now. Install with a different board-id.

        About the HWP issue. I didn’t know the exact board-id/model that you were using, and the former turns out to be a problem for the actual installation – not for HWP.

        Now. The problem, for certain board-id’s, is that HWP is also enabled by a setting in the Mac-XXXXXXXXXXXXXXXX.plist and since HWP may only be enabled once, you should not use a board-id that also enables HWP. The one you are using is fine.

        p.s. The latter can be checked with help of: sudo freqVectorsEdit.sh -d 1

      • Thanks Piker for the tip.
        Ive tryed now different board ids with and without HWP, doesnt matter i cant boot with 0x050654…
        The whole idea for me was in first place to get rid of voodootscsync kext and in second place, to get a more similar cpuid for the Skylake-X CPUs.
        The 0x0506E4 works good, especially if you enable HWP, you get the same performance as in windows.

        With HWP i get in cinebench r15 for the 7900x 2420-2450 points and 183-185 single core points.
        Without HWP, i get 1700-1900 and ~160 points.
        (All cores synched and 4,5ghz oc)

        As far i can tell, the difference comes not from HWP itself.
        If HWP is disabled, my CPU gets max ~82 degrees and throttle.
        With HWP, my CPU reach 95 degrees and doesn’t throttle.

        However, seems like we are stuck with 0x0506E4 and voodootsc…

        Thanks piker:-)
        Cheers 🙂

      • The fact that you get a lower Geekbench score. Well. That is a power management related SSDT problem. It has nothing to do with HWP. Both should work.

        Also. I did actually test an engineering sample of the Intel i9-7900X with RevoBoot, and never used a fake CPUID so something strange is going on. I’ll have another look at my notes and will report back to you when I find something, but I received tho new processors that I like to test before I will need to return them.

  2. Pingback: Nuovi iMac Pro, primi indizi sui processori Intel Xeon ideali per Apple - Macitynet.it

  3. Pike, we found it out.
    Or better to say, one other guy in the tonymac forums… (TheOfficialGypsy)

    We need the XCPM Bootstrap Patch, then we are able to boot with 0x050654…
    Or any other cpuid that we want…

    That means in 10.13.1 17B35a, there is no kernel or xcpm support for Xeon-W or Skylake-X.
    or at least not for the iMac17,1 smbios…

    That means for me, there is nothing more to experiment.

    Cheers.

      • Thanks, but that basically does the same thing as using a fake CPUID. A stupid work around to just not a fake CPUID. Not good.

        What you really want is to look at this snippet in _xcpm_bootstrp:
        ffffff80003a6a3c mov dword [_xcpm_cpu_model], 0x4000
        ffffff80003a6a46 mov dword [_xcpm_config+204], 0x0
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        now look at this line:
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        That line is used to select the MSR to write to (IA32_HWP_REQUEST_PKG or IA32_HWP_REQUEST) but that MSR may not be supported by your processor. What I would do is change it to zero (0). And if that still doesn’t work, then take a look at this line:
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        Change that to 0x7a120 or nop it our completely.

      • Piker, you are giving me good advices, the problem is, you are looking in to the disassembled kernel and I am looking into the working/compiled kernel.

        I don’t know how to disassemble the kernel, or where to look in the running kernel with your infos.
        Cheers Pike.

      • 1.) Open the kernel in Hopper
        2.) Search for “_xcpm_bootstrap”.
        3.) Click on “_xcpm_bootstrap” in the symbols and string panel (at the left).
        4.) Scroll down to loc_ffffff80003a6a3c.

        There you have it. It’s there right in front of you 😉

        You can then open the kernel in a Hex Editor and search for the address or pattern and path it (in Clover if you like).

      • Ive disassembled the kernel and found the entrys!!!

        Thank you very much!

        Now I need just to find out how to translate that code into the compiled kernel, for clover patching… xD

        Cheers 🙂

      • Example: mov dword [_xcpm_config+560], 0x1

        That is (in hex code)..: C7 05 13 96 68 00 01 00 00 00
        You want to change I to: C7 05 13 96 68 00 00 00 00 00

        I don’t know if Clover wants it in reverse, but that is easy for you to find out. If not. Then you can use this:

        echo -n “C7051396680001000000″|xxd -r -p|base64
        echo -n “C7051396680000000000″|xxd -r -p|base64

        Otherwise just flip the bytes 😉

      • awesome!

        I’ve got it!
        I understand now your infos xD

        Thank you very much!
        Now I know what I need to look for, where, and how to translate that!

        Going to try now! Thanks!!!

        Cheers!

      • Nothing works:-)
        Ive tryed
        _xcpm_config+560 (with changing to 0)
        _xcpm_config+120 (to 0x7a120 and 0x000000)
        _xcpm_hwp_enabled (with changing to 0)
        Nothing of them or any combination of them worked.

        And ive tryed 0x050654, 0x050652 and 0x050650 as cpuid…

        Cheers pike:-)

      • You should first patch the kernel file and verify the changes in Hopper. Only use Clover patches afterwards, when everything works. Also. don’t use a fake CPUID.

        You should also make a combination of all patches. Also change 0x4000 to 0x2000 or any other value that is used. Like 0x1000 and 0x200.

      • Piker, is there a way to verify the cpuid?
        Because without fake cpuid i think clover injects automatically 0x0506E4…
        Tools like geekbench, cinebench, your appleintelinfo kext reports 0x050654, even if i set the xeon fake id…

        Had no time yesterday to patch the kernel directly… Because im upgrading my pc… And this can take a bit longer, because im working very much in my company 😦

        And i didnt got what you meant with combination of patches. 0x4000… 0x2000…

        Cheers:-)

      • 1.) You need to take the fake CPUID injection thing up with slice and other Clover coders/users.

        2.) Let’s take a look at that snippet:

        ffffff80003a6a3c mov dword [_xcpm_cpu_model], 0x4000
        ffffff80003a6a46 mov dword [_xcpm_config+204], 0x0
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        There you have the 0x4000. It’s another value for other CPU models. Hence the suggested use of 0x2000 and the other values. Look at the values in: xnu/osfmk/i386/cpuid.h:

        0x3c => 0x4.   (CPU_MODEL_HASWELL)
        0x3d => 0x80.  (CPU_MODEL_BROADWELL/CPU_MODEL_BROADWELL_ULX/CPU_MODEL_BROADWELL_ULT)
        0x45 => 0x10   (CPU_MODEL_HASWELL_ULT)
        0x46 => 0x8.   (CPU_MODEL_CRYSTALWELL)
        0x47 => 0x40   (CPU_MODEL_BROADWELL_H)
        0x4e => 0x200  (CPU_MODEL_SKYLAKE/CPU_MODEL_SKYLAKE_ULT/CPU_MODEL_SKYLAKE_ULX)
        0x55 => 0x4000 (CPU_MODEL_SKYLAKE_W)
        0x5e => 0x2000 (CPU_MODEL_SKYLAKE_DT)
        0x5d => 0x0    (not there)
        0x8e => 0x200  (CPU_MODEL_KABYLAKE/CPU_MODEL_KABYLAKE_ULT/CPU_MODEL_KABYLAKE_ULX)
        0x9e => 0x1000 (CPU_MODEL_KABYLAKE_DT)
        0x9e => 0x2000 (CPU_MODEL_KABYLAKE_DT)
        

        Only two processor models (0x3d and 0x45) set this to one:
        mov dword [_xcpm_config+204], 0x1
        You don’t want that. But that’s ok for your processor model (CPUID).

        Only one processor models (0x55) set this to one:
        mov dword [_xcpm_hwp_enabled], 0x1
        That will match with your processor (CPUID). And that may be a problem as the bit in this MSR can only be set once. Like I said earlier. Some resource plist will also try to enable it. That won’t work. Hence the tip to NOP it out. Ot at least make sure that the plist that matches with your board-id won’t also try to enable HWP. Or Clover!

        What I would do is use 0x1000 or 0x2000 instead of the 0x4000 and NOP this block out:
        ffffff80003a6a50 mov qword [_xcpm_config+120], 0x989680
        ffffff80003a6a5b mov dword [_xcpm_config+560], 0x1
        ffffff80003a6a65 mov dword [_xcpm_hwp_enabled], 0x1

        If that works, then you know where to look for the problem.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s