Shit hey. I need to leave right away. Grandma is really going backwards with her health. Later folks!
Update
We are going to bring grandma home, to Holland, for the last time. It is over and out for her, she’s too old and too sick to stay behind. Mom is going to take care of her now.
Now that we have a patch to stop XCPM in the Mavericks mach_kernel rebooting your hack, thanks to RehabMan for all testing, I now like to propose something entirely different. This time I am on slippery ice… because we promised not to work on SMC code/hacks. And I won’t break this promise, but I hope that the FakeSMC developers will see the light. That what they have been saying all these years. That this error is a non-issue… is not true:
SMC::smcInitHelper ERROR: MMIO regMap == NULL – fall back to old SMC mode
My understanding of things is that you see this error just because something is not right. Something need to be done differently. First. Have a look at the following ACPI snippet from a late 2013 iMac (iMac14,2):
Device (SMC)
{
Name (_HID, EisaId ("APP0001")) // _HID: Hardware ID
Name (_CID, "smc-huronriver") // _CID: Compatible ID
Name (_STA, 0x0B) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0300, // Range Minimum
0x0300, // Range Maximum
0x01, // Alignment
0x20, // Length
)
Memory32Fixed (ReadWrite,
0xFEF00000, // Address Base
0x00010000, // Address Length
)
IRQNoFlags () {6}
})
}
Now look at this ACPI snippet:
OperationRegion (PLMT, SystemIO, 0x0310, 0x0A)
Field (PLMT, WordAcc, Lock, Preserve)
{
CPLT, 8,
IGPS, 8,
MPLT, 8,
CFIL, 8,
EGPS, 8
}
Who here remembers Samantha’s blog article about it? Right. These are the CPU, IGPU, Memory and EGPU P-State limits. Oh and sorry because I can’t recall the meaning of CFIL right now, thus I will have to dig it up for you at a later time.
Anyway. Note the Memory32Fixed in the first ACPI snippet, because that part is missing in FakeSMC. This 64 KB data window is empty in your hack. But why don’t we use what Apple is providing?
Never wondered what’s inside of all these SMC updates? I tell you this; I certainly looked at them. That is also where the blog title is coming from, because that is literally part of the SMC update PKG’s.
Sure. I first had to write a script to convert the data to a binary format and then I opened it with HexEdit. Hmmm. Ok. So the file is longer than the 64 KW address space defined in the DSDT, but look at the EFI binary that writes the data. Right. Another problem. Nobody ever disassembled the EFI binary, of course, otherwise this would have been a real non-issue… instead of telling people that the error is DUST 🙂
Some people are experiencing a reboot with Mavericks, because XCPM (read: mach_kernel power management) writes to a locked register (bit 15 of MSR 0xE2 is set) and that is why I looked at the disassembled code of the mach_kernel (the XCPM source code is still not released by Apple) and I found a routine that we might have to change a little. Here it is:
_wrmsr_carefully:
+0 ffffff80002d5ad0 89f9 movl %edi, %ecx
+2 ffffff80002d5ad2 89f0 movl %esi, %eax
+4 ffffff80002d5ad4 48c1ee20 shrq $0x20, %rsi
+8 ffffff80002d5ad8 89f2 movl %esi, %edx
+10 ffffff80002d5ada 0f30 wrmsr
+12 ffffff80002d5adc 31c0 xorl %eax, %eax
+14 ffffff80002d5ade c3 ret
+15 ffffff80002d5adf b801000000 movl $0x1, %eax
+20 ffffff80002d5ae4 c3 ret
This routine might be used by calls to wrmsr and thus I like to propose a small change to see if I am right. Or not of course. Anyway. Change the 0f30 into 9090 and see if that stops it from rebooting.
If this change stops it from rebooting, then we can come up with something that filters out MSR 0xE2 (_xcpm_core_scope_msrs) and do what we want it to do. Otherwise we may try to change the value of _xcpm_core_scope_msrs (0xE2) into something like 0xC3 (for example). For this you have to search for:
E2 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 07 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E2 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 05 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E2 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 08 00 00 7E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Then you change the value E2 (in red) into C3. Let me know if this works or not. Thanks!
Notes:
I did not mention the assembler code that uses this data, simply because if I have to tell people that then they probably don’t even know what to do with it, but trust me… I certainly know what is calling it.
Update-4
The values in blue are stored into the MSR (0xE2) but only one is used and the value depends on the SKU (processor model). We know this because the output of AppleIntelCPUPowerManagementInfo.kext of a MacBookAir6,2 shows us that it is set to 0x7E000008 and my desktop processor uses the second block, which I know because I changed the value from 0x1E000005 to 0x1E000007 and that now shows up in the output of AppleIntelCPUPowerManagementInfo.kext In other words. We should only have to change one block. Not all three.
Update
I did some more testing and have tried setting bit-1 of MSR 0x1AA (MSR_MISC_PWR_MGMT) with RevoBoot, but then even my Gigabyte desktop board reboots. Pretty interesting.
Also. _xcpm_cpu_model_get is called from _xcpm_perf_bias_set (jmpq 0xffffff80002f9ba0) and thus you can eliminate the initialisation altogether by nop’ing it out (falling back to AppleIntelCPUPowerManagement.kext for supported processors) but I would much rather have a patch that only skips the MSR that triggers the reboot. In short: Is this bit (1) the problematic one?
Update-2
Cool. This is no longer an issue. RehabMan confirmed that the first patch will not work, but my second proposal does – he worked out a patch so now people with a locked (UEFI) BIOS can boot Mavericks… with the vanilla stock mach_kernel. All you need now is a boot loader that can patch the kernel, or patch the mach_kernel manually.
Thanks to RehabMan for all testing and coming up with a patch, even if I would have done it a little differently – see comments (there are many roads to Rome, but as long as one brings you to Rome… then I am fine with it 😉
Update-3
Just for the record; You only need to patch the mach_kernel when it reboots due to a locked MSR (0xE2) and if PMPatch (by CodeRush) isn’t working for you or when you don’t want to/can use it, but all other people should check this out.
Pike's Universum 