Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
I just ran Intel® Processor Identification Utility from Windows:
Code:
Version : 6.1.0731
TimeStamp : 2019/12/30 11:01:26
Operating System : Microsoft Windows NT 10.0.17134.0
Number of processors in system: 2
Current processor: 1
Active cores per processor: 6
Disabled cores per processor: 0
Processor Name: Intel(R) Xeon(R) X5690 CPU @ 3.47GHz
Type : 0
Family : 6
Model : 44
Stepping : 2
Revision: 31
Maximum CPUID Level: 11
L1 Instruction Cache: 6 x 32 KB
L1 Data Cache: 6 x 32 KB
L2 Cache: 6 x 256 KB
L3 Cache: 12 MB
Packaging: LGA1366
Enhanced Intel SpeedStep® Technology: Yes
MMX(TM): Yes
Intel® SSE: Yes
Intel® SSE2: Yes
Intel® SSE3: Yes
Intel® SSE4: Yes
Intel® AES-NI: Yes
Intel® AVX: No
Enhanced Halt State: Yes
Execute Disable Bit: Yes
Intel® Hyper-Threading Technology: Yes
Intel® 64 Architecture: Yes
Intel® virtualization technology: Yes
Intel® vt-x with extended page tables: Yes
System Graphics: Add-in Graphics
Expected Processor Frequency: 3.47 GHz
Reported Processor Frequency: 3.69 GHz
Expected System Bus Frequency: 133 MHz
Reported System Bus Frequency: 129 MHz
*************************************************************
Code:
Version : 6.1.0731
TimeStamp : 2019/12/30 10:59:26
Operating System : Microsoft Windows NT 10.0.17134.0
Number of processors in system: 2
Current processor: 2
Active cores per processor: 6
Disabled cores per processor: 0
Processor Name: Intel(R) Xeon(R) X5690 CPU @ 3.47GHz
Type : 0
Family : 6
Model : 44
Stepping : 2
Revision: 31
Maximum CPUID Level: 11
L1 Instruction Cache: 6 x 32 KB
L1 Data Cache: 6 x 32 KB
L2 Cache: 6 x 256 KB
L3 Cache: 12 MB
Packaging: LGA1366
Enhanced Intel SpeedStep® Technology: Yes
MMX(TM): Yes
Intel® SSE: Yes
Intel® SSE2: Yes
Intel® SSE3: Yes
Intel® SSE4: Yes
Intel® AES-NI: Yes
Intel® AVX: No
Enhanced Halt State: Yes
Execute Disable Bit: Yes
Intel® Hyper-Threading Technology: Yes
Intel® 64 Architecture: Yes
Intel® virtualization technology: Yes
Intel® vt-x with extended page tables: Yes
System Graphics: Add-in Graphics
Expected Processor Frequency: 3.47 GHz
Reported Processor Frequency: 3.70 GHz
Expected System Bus Frequency: 133 MHz
Reported System Bus Frequency: 137 MHz
*************************************************************
I don't know what to think now? Has OC modified SMBIOS or is this normal? This was booting without OC.
[automerge]1577732828[/automerge]
Plus why AVX is reported as not supported?
 
HWINFO:
Code:
Processor Name:    Intel Xeon X5690
    Original Processor Frequency:    3466.7 MHz
    Original Processor Frequency [MHz]:    3467
        
    CPU ID:    000206C2
    CPU Brand Name:    Intel(R) Xeon(R) CPU X5690 @ 3.47GHz
    CPU Vendor:    GenuineIntel
    CPU Stepping:    B1
    CPU Code Name:    Westmere-EP
    CPU Technology:    32 nm
    CPU S-Spec:    SLBVX
    CPU Thermal Design Power (TDP):    130.0 W
    CPU Thermal Design Current (TDC):    110.0 A
    CPU Max. Case Temperature (Tcase_max):    78.5 °C
    CPU Max. Junction Temperature (Tj,max):    101 °C
    CPU Type:    Production Unit
    CPU Platform:    Socket B1 (LGA1366 FC-LGA6)
    Microcode Update Revision:    1F
        
    Number of CPU Cores:    6
    Number of Logical CPUs:    12
        
[Operating Points]
    CPU LFM (Minimum):    1600.0 MHz = 12 x 133.3 MHz
    CPU HFM (Base):    3466.7 MHz = 26 x 133.3 MHz
    CPU Turbo Max:    3733.3 MHz = 28 x 133.3 MHz [Locked]
    CPU Current:    1596.1 MHz = 12 x 133.0 MHz
        
    CPU Bus Type:    FSB (QDR)
 
Here are some readings from the IoRegistry unmodified boot:
Code:
"processor-lapic" = 0x0
    | | |   "clock-frequency" = <00693bce>=3460000000
    | | |   "processor-number" = 0x0
    | | |   "timebase-frequency" = <00ca9a3b>=1000000000
    | | |   "processor-id" = 0x0
    | | |   "bus-frequency" = <ffffffff>=4294967295   ?????? Weird?
    | | |   "cpu-type" = <0105>
    | | |   "device_type" = <70726f636573736f7200>
    | | |   "name" = <4350553000>
    | | |   "processor-index" = 0x0
OC boot:
Code:
"processor-lapic" = 0x0
    | | |   "clock-frequency" = <00c39dd0> =3500000000
    | | |   "processor-number" = 0x0
    | | |   "timebase-frequency" = <00ca9a3b>=1000000000
    | | |   "processor-id" = 0x0
    | | |   "bus-frequency" = <00e1f505> =1000000000
    | | |   "cpu-type" = <0105>
    | | |   "device_type" = <70726f636573736f7200>
    | | |   "name" = <4350553000>
    | | |   "processor-index" = 0x0
Seems like the clock-frequency and the bus-frequency are different. But why the bus-frequency=4294967295 in the original I/O?

It looks like the Dec number is meaningless, but just coming from the Hex FFFFFFFF

Plus why AVX is reported as not supported?

Because our Xeons doesn't have AVX.
 
It looks like the Dec number is meaningless, but just coming from the Hex FFFFFFFF
Yes but the bus frequency is supposed to be 133 according to Intel Utility, or 133.33 according to HWINFO and the Intel ADM. Apparently that info is not written anywhere, but it is a constant based on the Nehalem processor type.
 
Another thing I noticed is that the CPU current ratio is detected=0 in OC. In Windows minimum was 12. That is why probably CPU Power management does not work.
So to summarize:
1. Microcode revision- Incorrect status: Bug review in Github
2. CPU Frequency incorrect- Opened issue in GitHub- Nobody replied yet
3. Current multiplier ratio improperly set.
 
  • Like
Reactions: w1z and h9826790
Yes but the bus frequency is supposed to be 133 according to Intel Utility, or 133.33 according to HWINFO and the Intel ADM. Apparently that info is not written anywhere, but it is a constant based on the Nehalem processor type.

I am not sure if that bus frequency is really identical to external clock.
[automerge]1577737927[/automerge]
Another thing I noticed is that the CPU current ratio is detected=0 in OC. In Windows minimum was 12. That is why probably CPU Power management does not work.

This is my understanding as well. It cause the CPU stay at a fixed clock speed (it seems my W3690 still stay at 3.46GHz actual speed), and unable to downclock to 1.6GHz. So, 5W higher when in idle.
 
Last edited:
It looks like OC readings are more inline with the Intel reporting utility. As you can see it improperly detects overclocked CPU whereas the clock multiplier was at minimum (12). And OC is based on Intel's tianocore edk2. They both share the same library and techniques, which apparently are incorrect for our CPU.
 
Has anyone been successful in blessing OC on an NVMe disk on PCIe card? I somehow can't get open core to boot from NVMe with my RX580 card. On the GTX980 with modified MAC bootrom it does work.

disk0s1 is my NVMe SSD, can it be that the "Preferred system partitions disk1s1 and disk2s1 are causing trouble?
 

Attachments

  • bless.txt
    1.7 KB · Views: 174
  • diskutil.txt
    3.7 KB · Views: 182
Has anyone been successful in blessing OC on an NVMe disk on PCIe card? I somehow can't get open core to boot from NVMe with my RX580 card. On the GTX980 with modified MAC bootrom it does work.

disk0s1 is my NVMe SSD, can it be that the "Preferred system partitions disk1s1 and disk2s1 are causing trouble?
You may omit sudo if blessing from recovery partition.
Code:
sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/OC/OpenCore.efi  --verbose
 
You may omit sudo if blessing from recovery partition.
Code:
sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/OC/OpenCore.efi  --verbose

Thanks, I think this was one of the causes! During my 3 day course in "Mac Pro booting" ;) I also installed OC on one of the internal SATA drives which probably messed things up trying to boot from that SATA drive. Removed all but the one on my Catalina SSD now and blessed with above --file option and now it works! :)

Also on boot order, it looks like the internal SATA slots go first from 4 - 1 then my internal mSATA PCIe card also from slot 3 - 0.

Anyhow thanks for the help, and everyone all the best for 2020.🍾
 
Does somebody have issues with the Audio? I lost my device:
Code:
system_profiler SPAudioDataType
Audio:
    Devices:
        USB Microphone:
          Default Input Device: Yes
          Input Channels: 1
          Manufacturer: Sonix Technology Co., Ltd.
          Current SampleRate: 48000
          Transport: USB
          Input Source: Default

gfxutil -f HDEF
DevicePath = PciRoot(0x0)/Pci(0x1b,0x0)
gfxutil -f HDAS
DevicePath not found!
I can only see the microphone. No output audio. Without OC everything is fine.
1577889378819.png
 
Very normal on my cMP.
Screenshot 2020-01-01 at 10.40.27 PM.png


It's now booted with iMac Pro board-id spoofing via OC. But I never have audio issue with OC (just VMM flag, auto iMac Pro / 7,1 SMBIOS spoofing, or manual iMac Pro / 7,1 board-id spoofing, etc...)
 
I got all these with OC.
View attachment 886065

Is your Catalina a clean one? Did you even install anything like AppleALC.kext?
I think I got it. When I inspected my OC config file I saw some settings which I experimented with and I forgot about them. These were enabled:
1577893108428.png

Apparently what they do is restore Apple device policy and break the Pikera mod. Pikera reattaches the devices under different trees and above settings break Pikera.
 
Last edited:
  • Like
Reactions: h9826790
Has anyone gotten Open Core to work on the MP3,1?

I can't seem to get it to work at all.
What seems to be the problem? Can you see the boot screen?
[automerge]1577978309[/automerge]
I saw someone on Reddit chainloaded from refind. So you should be able to see the boot screen.
 
Last edited:
Using CHIPSEC I was able to read register 8b and the revision number with OC boot loader:
Code:
sudo ./chipsec_util.py msr 0x8b                    
Password:

################################################################
##                                                            ##
##  CHIPSEC: Platform Hardware Security Assessment Framework  ##
##                                                            ##
################################################################
[CHIPSEC] Version : 1.4.5
[CHIPSEC] OS      : Darwin 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
[CHIPSEC] Python  : 2.7.16 (64-bit)
[CHIPSEC] API mode: using CHIPSEC kernel module API
ERROR: Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22
WARNING: *******************************************************************
WARNING: * Unknown platform!
WARNING: * Platform dependent functionality will likely be incorrect
WARNING: * Error Message: "Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22"
WARNING: *******************************************************************
[CHIPSEC] Helper  : OSXHelper (/Users/g5/Downloads/chipsec-1.4-2.5/chipsec/helper/osx/chipsec.kext)
[CHIPSEC] Platform: UnknownPlatform
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3406
[CHIPSEC]      RID: 22
[CHIPSEC] PCH     : Default PCH
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3A18
[CHIPSEC]      RID: 00
[CHIPSEC] Executing command 'msr' with args ['0x8b']

[CHIPSEC] CPU0: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU1: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU2: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU3: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU4: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU5: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU6: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU7: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU8: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU9: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU10: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU11: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU12: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU13: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU14: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU15: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU16: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU17: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU18: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU19: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU20: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU21: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU22: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
[CHIPSEC] CPU23: RDMSR( 0x8b ) = 0000001F00000000 (EAX=00000000, EDX=0000001F)
It does not identify the processor correctly because it is not in the code. But it reads the register. OC developers may look in that code and see why theirs fails.
 
Code:
Constant x86_64::registers::msr::IA32_APERF
pub const IA32_APERF: u32 = 232
Actual Performance Frequency Clock Count (RW) See Table 35-2.

[CHIPSEC] Executing command 'msr' with args ['0xe8']

[CHIPSEC] CPU0: RDMSR( 0xe8 ) = 0000018C092C9C7E (EAX=092C9C7E, EDX=0000018C)
[CHIPSEC] CPU1: RDMSR( 0xe8 ) = 0000018C093A2D9A (EAX=093A2D9A, EDX=0000018C)
[CHIPSEC] CPU2: RDMSR( 0xe8 ) = 0000018C093F11A6 (EAX=093F11A6, EDX=0000018C)
[CHIPSEC] CPU3: RDMSR( 0xe8 ) = 0000018C0943D405 (EAX=0943D405, EDX=0000018C)
[CHIPSEC] CPU4: RDMSR( 0xe8 ) = 0000018C0948805A (EAX=0948805A, EDX=0000018C)
[CHIPSEC] CPU5: RDMSR( 0xe8 ) = 0000018C094D2CAA (EAX=094D2CAA, EDX=0000018C)
[CHIPSEC] CPU6: RDMSR( 0xe8 ) = 0000018C095218F0 (EAX=095218F0, EDX=0000018C)
[CHIPSEC] CPU7: RDMSR( 0xe8 ) = 0000018C0956D789 (EAX=0956D789, EDX=0000018C)
[CHIPSEC] CPU8: RDMSR( 0xe8 ) = 0000018C095B8EB0 (EAX=095B8EB0, EDX=0000018C)
[CHIPSEC] CPU9: RDMSR( 0xe8 ) = 0000018C096043A0 (EAX=096043A0, EDX=0000018C)
[CHIPSEC] CPU10: RDMSR( 0xe8 ) = 0000018C0965386E (EAX=0965386E, EDX=0000018C)
[CHIPSEC] CPU11: RDMSR( 0xe8 ) = 0000018C0969F932 (EAX=0969F932, EDX=0000018C)
[CHIPSEC] CPU12: RDMSR( 0xe8 ) = 0000018C096EB400 (EAX=096EB400, EDX=0000018C)
[CHIPSEC] CPU13: RDMSR( 0xe8 ) = 0000018C0973BE40 (EAX=0973BE40, EDX=0000018C)
[CHIPSEC] CPU14: RDMSR( 0xe8 ) = 0000018C0978B50F (EAX=0978B50F, EDX=0000018C)
[CHIPSEC] CPU15: RDMSR( 0xe8 ) = 0000018C097D9F49 (EAX=097D9F49, EDX=0000018C)
[CHIPSEC] CPU16: RDMSR( 0xe8 ) = 0000018C09829607 (EAX=09829607, EDX=0000018C)
[CHIPSEC] CPU17: RDMSR( 0xe8 ) = 0000018C0987806E (EAX=0987806E, EDX=0000018C)
[CHIPSEC] CPU18: RDMSR( 0xe8 ) = 0000018C098CDA2D (EAX=098CDA2D, EDX=0000018C)
[CHIPSEC] CPU19: RDMSR( 0xe8 ) = 0000018C09920461 (EAX=09920461, EDX=0000018C)
[CHIPSEC] CPU20: RDMSR( 0xe8 ) = 0000018C099707B0 (EAX=099707B0, EDX=0000018C)
[CHIPSEC] CPU21: RDMSR( 0xe8 ) = 0000018C099C0993 (EAX=099C0993, EDX=0000018C)
[CHIPSEC] CPU22: RDMSR( 0xe8 ) = 0000018C09A0F4A5 (EAX=09A0F4A5, EDX=0000018C)
[CHIPSEC] CPU23: RDMSR( 0xe8 ) = 0000018C09A5DA09 (EAX=09A5DA09, EDX=0000018C)

OC boot [CHIPSEC] Executing command 'msr' with args ['0xe8']

[CHIPSEC] CPU0: RDMSR( 0xe8 ) = 00000020A892FBBC (EAX=A892FBBC, EDX=00000020)
[CHIPSEC] CPU1: RDMSR( 0xe8 ) = 00000020A8A21CFB (EAX=A8A21CFB, EDX=00000020)
[CHIPSEC] CPU2: RDMSR( 0xe8 ) = 00000020A8A71787 (EAX=A8A71787, EDX=00000020)
[CHIPSEC] CPU3: RDMSR( 0xe8 ) = 00000020A8ABBE41 (EAX=A8ABBE41, EDX=00000020)
[CHIPSEC] CPU4: RDMSR( 0xe8 ) = 00000020A8B07EF8 (EAX=A8B07EF8, EDX=00000020)
[CHIPSEC] CPU5: RDMSR( 0xe8 ) = 00000020A8B518CE (EAX=A8B518CE, EDX=00000020)
[CHIPSEC] CPU6: RDMSR( 0xe8 ) = 00000020A8B9E22A (EAX=A8B9E22A, EDX=00000020)
[CHIPSEC] CPU7: RDMSR( 0xe8 ) = 00000020A8BE6AB1 (EAX=A8BE6AB1, EDX=00000020)
[CHIPSEC] CPU8: RDMSR( 0xe8 ) = 00000020A8C33A74 (EAX=A8C33A74, EDX=00000020)
[CHIPSEC] CPU9: RDMSR( 0xe8 ) = 00000020A8C7C837 (EAX=A8C7C837, EDX=00000020)
[CHIPSEC] CPU10: RDMSR( 0xe8 ) = 00000020A8CC9E7C (EAX=A8CC9E7C, EDX=00000020)
[CHIPSEC] CPU11: RDMSR( 0xe8 ) = 00000020A8D1313A (EAX=A8D1313A, EDX=00000020)
[CHIPSEC] CPU12: RDMSR( 0xe8 ) = 00000020A8D5BC78 (EAX=A8D5BC78, EDX=00000020)
[CHIPSEC] CPU13: RDMSR( 0xe8 ) = 00000020A8DA4030 (EAX=A8DA4030, EDX=00000020)
[CHIPSEC] CPU14: RDMSR( 0xe8 ) = 00000020A8DECDB5 (EAX=A8DECDB5, EDX=00000020)
[CHIPSEC] CPU15: RDMSR( 0xe8 ) = 00000020A8E397A4 (EAX=A8E397A4, EDX=00000020)
[CHIPSEC] CPU16: RDMSR( 0xe8 ) = 00000020A8E82601 (EAX=A8E82601, EDX=00000020)
[CHIPSEC] CPU17: RDMSR( 0xe8 ) = 00000020A8ECB05D (EAX=A8ECB05D, EDX=00000020)
[CHIPSEC] CPU18: RDMSR( 0xe8 ) = 00000020A8F139F3 (EAX=A8F139F3, EDX=00000020)
[CHIPSEC] CPU19: RDMSR( 0xe8 ) = 00000020A8F63EF4 (EAX=A8F63EF4, EDX=00000020)
[CHIPSEC] CPU20: RDMSR( 0xe8 ) = 00000020A8FB0D90 (EAX=A8FB0D90, EDX=00000020)
[CHIPSEC] CPU21: RDMSR( 0xe8 ) = 00000020A8FFA2B6 (EAX=A8FFA2B6, EDX=00000020)
[CHIPSEC] CPU22: RDMSR( 0xe8 ) = 00000020A9046BF7 (EAX=A9046BF7, EDX=00000020)
[CHIPSEC] CPU23: RDMSR( 0xe8 ) = 00000020A9091FE5 (EAX=A9091FE5, EDX=00000020)

Constant x86_64::registers::msr::IA32_MPERF
pub const IA32_MPERF: u32 = 231
Maximum Performance Frequency Clock Count (RW) See Table 35-2

[CHIPSEC] Executing command 'msr' with args ['0xe7']
[CHIPSEC] CPU0: RDMSR( 0xe7 ) = 0000004DE72BED3B (EAX=E72BED3B, EDX=0000004D)
[CHIPSEC] CPU1: RDMSR( 0xe7 ) = 0000004DE7370D11 (EAX=E7370D11, EDX=0000004D)
[CHIPSEC] CPU2: RDMSR( 0xe7 ) = 0000004DE73BA92B (EAX=E73BA92B, EDX=0000004D)
[CHIPSEC] CPU3: RDMSR( 0xe7 ) = 0000004DE74037F4 (EAX=E74037F4, EDX=0000004D)
[CHIPSEC] CPU4: RDMSR( 0xe7 ) = 0000004DE744AAD3 (EAX=E744AAD3, EDX=0000004D)
[CHIPSEC] CPU5: RDMSR( 0xe7 ) = 0000004DE7493F4C (EAX=E7493F4C, EDX=0000004D)
[CHIPSEC] CPU6: RDMSR( 0xe7 ) = 0000004DE74E0D72 (EAX=E74E0D72, EDX=0000004D)
[CHIPSEC] CPU7: RDMSR( 0xe7 ) = 0000004DE752B3FD (EAX=E752B3FD, EDX=0000004D)
[CHIPSEC] CPU8: RDMSR( 0xe7 ) = 0000004DE7575E8A (EAX=E7575E8A, EDX=0000004D)
[CHIPSEC] CPU9: RDMSR( 0xe7 ) = 0000004DE75BFA20 (EAX=E75BFA20, EDX=0000004D)
[CHIPSEC] CPU10: RDMSR( 0xe7 ) = 0000004DE760959C (EAX=E760959C, EDX=0000004D)
[CHIPSEC] CPU11: RDMSR( 0xe7 ) = 0000004DE7652B29 (EAX=E7652B29, EDX=0000004D)
[CHIPSEC] CPU12: RDMSR( 0xe7 ) = 0000004DE769C8E5 (EAX=E769C8E5, EDX=0000004D)
[CHIPSEC] CPU13: RDMSR( 0xe7 ) = 0000004DE76E64AB (EAX=E76E64AB, EDX=0000004D)
[CHIPSEC] CPU14: RDMSR( 0xe7 ) = 0000004DE772FFB0 (EAX=E772FFB0, EDX=0000004D)
[CHIPSEC] CPU15: RDMSR( 0xe7 ) = 0000004DE7779918 (EAX=E7779918, EDX=0000004D)
[CHIPSEC] CPU16: RDMSR( 0xe7 ) = 0000004DE77C8F2B (EAX=E77C8F2B, EDX=0000004D)
[CHIPSEC] CPU17: RDMSR( 0xe7 ) = 0000004DE7815E8C (EAX=E7815E8C, EDX=0000004D)
[CHIPSEC] CPU18: RDMSR( 0xe7 ) = 0000004DE78602AB (EAX=E78602AB, EDX=0000004D)
[CHIPSEC] CPU19: RDMSR( 0xe7 ) = 0000004DE78A9E3E (EAX=E78A9E3E, EDX=0000004D)
[CHIPSEC] CPU20: RDMSR( 0xe7 ) = 0000004DE78F36D9 (EAX=E78F36D9, EDX=0000004D)
[CHIPSEC] CPU21: RDMSR( 0xe7 ) = 0000004DE793D08B (EAX=E793D08B, EDX=0000004D)
[CHIPSEC] CPU22: RDMSR( 0xe7 ) = 0000004DE7986E9D (EAX=E7986E9D, EDX=0000004D)
[CHIPSEC] CPU23: RDMSR( 0xe7 ) = 0000004DE79D0164 (EAX=E79D0164, EDX=0000004D)

OC boot [CHIPSEC] Executing command 'msr' with args ['0xe7']

[CHIPSEC] CPU0: RDMSR( 0xe7 ) = 0000001AF8E789C0 (EAX=F8E789C0, EDX=0000001A)
[CHIPSEC] CPU1: RDMSR( 0xe7 ) = 0000001AF8F847F1 (EAX=F8F847F1, EDX=0000001A)
[CHIPSEC] CPU2: RDMSR( 0xe7 ) = 0000001D90E2DC60 (EAX=90E2DC60, EDX=0000001D)
[CHIPSEC] CPU3: RDMSR( 0xe7 ) = 0000001D90E823FE (EAX=90E823FE, EDX=0000001D)
[CHIPSEC] CPU4: RDMSR( 0xe7 ) = 0000001D90ED3435 (EAX=90ED3435, EDX=0000001D)
[CHIPSEC] CPU5: RDMSR( 0xe7 ) = 0000001D90F2158E (EAX=90F2158E, EDX=0000001D)
[CHIPSEC] CPU6: RDMSR( 0xe7 ) = 0000001D90F6ED47 (EAX=90F6ED47, EDX=0000001D)
[CHIPSEC] CPU7: RDMSR( 0xe7 ) = 0000001D90FB7379 (EAX=90FB7379, EDX=0000001D)
[CHIPSEC] CPU8: RDMSR( 0xe7 ) = 0000001D90FFFB7E (EAX=90FFFB7E, EDX=0000001D)
[CHIPSEC] CPU9: RDMSR( 0xe7 ) = 0000001D9104B407 (EAX=9104B407, EDX=0000001D)
[CHIPSEC] CPU10: RDMSR( 0xe7 ) = 0000001D91094E27 (EAX=91094E27, EDX=0000001D)
[CHIPSEC] CPU11: RDMSR( 0xe7 ) = 0000001D910DDE63 (EAX=910DDE63, EDX=0000001D)
[CHIPSEC] CPU12: RDMSR( 0xe7 ) = 0000001D9112A40D (EAX=9112A40D, EDX=0000001D)
[CHIPSEC] CPU13: RDMSR( 0xe7 ) = 0000001D91172B98 (EAX=91172B98, EDX=0000001D)
[CHIPSEC] CPU14: RDMSR( 0xe7 ) = 0000001D911BB4FB (EAX=911BB4FB, EDX=0000001D)
[CHIPSEC] CPU15: RDMSR( 0xe7 ) = 0000001D91206EA7 (EAX=91206EA7, EDX=0000001D)
[CHIPSEC] CPU16: RDMSR( 0xe7 ) = 0000001D912538E4 (EAX=912538E4, EDX=0000001D)
[CHIPSEC] CPU17: RDMSR( 0xe7 ) = 0000001D9129CD63 (EAX=9129CD63, EDX=0000001D)
[CHIPSEC] CPU18: RDMSR( 0xe7 ) = 0000001D912E6DBE (EAX=912E6DBE, EDX=0000001D)
[CHIPSEC] CPU19: RDMSR( 0xe7 ) = 0000001D9132FEA4 (EAX=9132FEA4, EDX=0000001D)
[CHIPSEC] CPU20: RDMSR( 0xe7 ) = 0000001D9137804F (EAX=9137804F, EDX=0000001D)
[CHIPSEC] CPU21: RDMSR( 0xe7 ) = 0000001D913C1996 (EAX=913C1996, EDX=0000001D)
[CHIPSEC] CPU22: RDMSR( 0xe7 ) = 0000001D91409EBA (EAX=91409EBA, EDX=0000001D)
[CHIPSEC] CPU23: RDMSR( 0xe7 ) = 0000001D91456850 (EAX=91456850, EDX=0000001D)
 
Open Core just never loads, seems to just hang, using a Mac EFI graphic card.
With processors earlier than Westmere, OpenCore can't use Apple Hypervisor and can't have VMM support at all. Westmere is the first Xeon that supports Apple Hypervisor.

For Nehalem and earlier processors, like MP3,1 Harpertown Xeons, OpenCore only works via SMBIOS spoofing.
 
From the Intel ADM Manual:
14.2 P-STATE HARDWARE COORDINATION
The Advanced Configuration and Power Interface (ACPI) defines performance states (P-states) that are used to facilitate system software’s ability to manage processor power consumption. Different P-states correspond to different performance levels that are applied while the processor is actively executing instructions. Enhanced Intel SpeedStep Technology supports P-states by providing software interfaces that control the operating frequency and voltage of a processor.
With multiple processor cores residing in the same physical package, hardware dependencies may exist for a subset of logical processors on a platform. These dependencies may impose requirements that impact the coordi- nation of P-state transitions. As a result, multi-core processors may require an OS to provide additional software support for coordinating P-state transitions for those subsets of logical processors.
ACPI firmware can choose to expose P-states as dependent and hardware-coordinated to OS power management (OSPM) policy. To support OSPMs, multi-core processors must have additional built-in support for P-state hardware coordination and feedback.
Intel 64 and IA-32 processors with dependent P-states amongst a subset of logical processors permit hardware coordination of P-states and provide a hardware-coordination feedback mechanism using IA32_MPERF MSR and
Vol. 3B 14-1
POWER AND THERMAL MANAGEMENT
IA32_APERF MSR. See Figure 14-1 for an overview of the two 64-bit MSRs and the bullets below for a detailed description:
Figure 14-1. IA32_MPERF MSR and IA32_APERF MSR for P-state Coordination
  • Use CPUID to check the P-State hardware coordination feedback capability bit. CPUID.06H.ECX[Bit 0] = 1 indicates IA32_MPERF MSR and IA32_APERF MSR are present.
  • IA32_MPERF MSR (E7H) increments in proportion to a fixed frequency, which is configured when the processor is booted.
  • IA32_APERF MSR (E8H) increments in proportion to actual performance, while accounting for hardware coordi- nation of P-state and TM1/TM2; or software initiated throttling.
  • The MSRs are per logical processor; they measure performance only when the targeted processor is in the C0 state.
  • Only the IA32_APERF/IA32_MPERF ratio is architecturally defined; software should not attach meaning to the content of the individual of IA32_APERF or IA32_MPERF MSRs.
  • When either MSR overflows, both MSRs are reset to zero and continue to increment.
  • Both MSRs are full 64-bits counters. Each MSR can be written to independently. However, software should
    follow the guidelines illustrated in Example 14-1.
    If P-states are exposed by the BIOS as hardware coordinated, software is expected to confirm processor support for P-state hardware coordination feedback and use the feedback mechanism to make P-state decisions. The OSPM is expected to either save away the current MSR values (for determination of the delta of the counter ratio at a later time) or reset both MSRs (execute WRMSR with 0 to these MSRs individually) at the start of the time window used for making the P-state decision. When not resetting the values, overflow of the MSRs can be detected by checking whether the new values read are less than the previously saved values.
    Example 14-1 demonstrates steps for using the hardware feedback mechanism provided by IA32_APERF MSR and IA32_MPERF MSR to determine a target P-state.
    Example 14-1. Determine Target P-state From Hardware Coordinated Feedback
    DWORD PercentBusy; // Percentage of processor time not idle.
    • // Measure “PercentBusy“ during previous sampling window.
    • // Typically, “PercentBusy“ is measure over a time scale suitable for
    • // power management decisions //
    • // RDMSR of MCNT and ACNT should be performed without delay.
    • // Software needs to exercise care to avoid delays between
    • // the two RDMSRs (for example, interrupts). MCNT = RDMSR(IA32_MPERF);
      ACNT = RDMSR(IA32_APERF);
      // PercentPerformance indicates the percentage of the processor // that is in use. The calculation is based on the PercentBusy,
      // that is the percentage of processor time not idle and the P-state // hardware coordinated feedback using the ACNT/MCNT ratio.
      // Note that both values need to be calculated over the same
63 063 0
IA32_MPERF (Addr: E7H)
IA32_APERF (Addr: E8H)
14-2 Vol. 3B
// time window.
PercentPerformance = PercentBusy * (ACNT/MCNT);
// This example does not cover the additional logic or algorithms
// necessary to coordinate multiple logical processors to a target P-state.
TargetPstate = FindPstate(PercentPerformance);
if (TargetPstate ≠ currentPstate) { SetPState(TargetPstate);
}
// WRMSR of MCNT and ACNT should be performed without delay. // Software needs to exercise care to avoid delays between
// the two WRMSRs (for example, interrupts).
WRMSR(IA32_MPERF, 0); WRMSR(IA32_APERF, 0);
[automerge]1578085373[/automerge]
From OC:
Code:
chipsec-1.4-2.5 % sudo ./chipsec_util.py cpu cpuid 0x15 0x8
Password:
Sorry, try again.
Password:

################################################################
##                                                            ##
##  CHIPSEC: Platform Hardware Security Assessment Framework  ##
##                                                            ##
################################################################
[CHIPSEC] Version : 1.4.5
[CHIPSEC] OS      : Darwin 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
[CHIPSEC] Python  : 2.7.16 (64-bit)
[CHIPSEC] API mode: using CHIPSEC kernel module API
ERROR: Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22
WARNING: *******************************************************************
WARNING: * Unknown platform!
WARNING: * Platform dependent functionality will likely be incorrect
WARNING: * Error Message: "Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22"
WARNING: *******************************************************************
[CHIPSEC] Helper  : OSXHelper (/Users/g5/Downloads/chipsec-1.4-2.5/chipsec/helper/osx/chipsec.kext)
[CHIPSEC] Platform: UnknownPlatform
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3406
[CHIPSEC]      RID: 22
[CHIPSEC] PCH     : Default PCH
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3A18
[CHIPSEC]      RID: 00
[CHIPSEC] Executing command 'cpu' with args ['cpuid', '0x15', '0x8']

[CHIPSEC] CPUID < EAX: 0x00000015
[CHIPSEC]         ECX: 0x00000008
[CHIPSEC] CPUID > EAX: 0x00000000
[CHIPSEC]         EBX: 0x00000000
[CHIPSEC]         ECX: 0x00000008
[CHIPSEC]         EDX: 0x00000020
[CHIPSEC] (cpu) time elapsed 0.000
Code:
chipsec-1.4-2.5 % sudo ./chipsec_util.py cpu cpuid 0x6 0x0

################################################################
##                                                            ##
##  CHIPSEC: Platform Hardware Security Assessment Framework  ##
##                                                            ##
################################################################
[CHIPSEC] Version : 1.4.5
[CHIPSEC] OS      : Darwin 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
[CHIPSEC] Python  : 2.7.16 (64-bit)
[CHIPSEC] API mode: using CHIPSEC kernel module API
ERROR: Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22
WARNING: *******************************************************************
WARNING: * Unknown platform!
WARNING: * Platform dependent functionality will likely be incorrect
WARNING: * Error Message: "Unsupported Platform: VID = 0x8086, DID = 0x3406, RID = 0x22"
WARNING: *******************************************************************
[CHIPSEC] Helper  : OSXHelper (/Users/g5/Downloads/chipsec-1.4-2.5/chipsec/helper/osx/chipsec.kext)
[CHIPSEC] Platform: UnknownPlatform
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3406
[CHIPSEC]      RID: 22
[CHIPSEC] PCH     : Default PCH
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 3A18
[CHIPSEC]      RID: 00
[CHIPSEC] Executing command 'cpu' with args ['cpuid', '0x6', '0x0']

[CHIPSEC] CPUID < EAX: 0x00000006
[CHIPSEC]         ECX: 0x00000000
[CHIPSEC] CPUID > EAX: 0x00000007
[CHIPSEC]         EBX: 0x00000002
[CHIPSEC]         ECX: 0x00000001
[CHIPSEC]         EDX: 0x00000000
[CHIPSEC] (cpu) time elapsed 0.000
 
Last edited:
I wish there was a
temperature controller application for Linux based on sensors temperature like MFC. This way I could have completely switched to KVM solution with open core inside passing the GPU trough. You can have Linux on the main machine and OSX and windows in the KVM machines using AMD and Nvidia at the same time.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.