I have configured RevoBoot to match a 2013 MacBook Air model and noticed a couple of oddities after the first boot. Let me start by adding a first screenshot.

One with the MacBook Air serial number removed, of course. And when everything is configured correctly, then you shouldn’t see this error:

[AGPM Controller] unknownPlatform

Usually the result of using unknown/unsupported board-id’s. No problem here. I also have my AppleIntelCPUPowerManagementInfo.kext installed and thus I looked for the relevant processor data in /var/log/system.log:

AICPUPMI: Low Frequency Mode : 800 MHz
AICPUPMI: Clock Speed : 3400 MHz
AICPUPMI: Max Turbo Frequency: 3800 MHz

The lowest supported processor frequency for desktop processors is now also 800 MHz so we should get a lot lower P-States. Not here. Not now at least. The clock speed and maximum turbo frequency are ok. This tells me that the UEFI BIOS bug I see here – discussed later on – is a cosmetic only one (I think). Next up. iGPU data:

AICPUPMI: IGPU Current Freq..: 200 MHz
AICPUPMI: IGPU Max Frequency.: 350 MHz
AICPUPMI: IGPU Max Turbo Freq: 1200 MHz

This is also fine. How do I know this you ask? Well. You may not be aware of it – not so strange since there isn’t a single Google search result for it – but we actually have a debug boot flag for it. Try this:

debug=0x100 igdebug=0xff

Reboot and look for the following output (example):

IG:: updateTableEntry:NN entry = 5
IG:: updateTableEntry:NN frequency = 950
IG:: updateTableEntry:NN upTimer = 31250
IG:: updateTableEntry:NN upThresholdlimit = 25000
IG:: updateTableEntry:NN upStep = 1
IG:: updateTableEntry:NN downTimer = 31250
IG:: updateTableEntry:NN downThresholdlimit = 18750
IG:: updateTableEntry:NN downStep = 1

You should see one of these blocks for every supported frequency. I checked mine and they are all there. Oh and it supports Ivy Bridge as well.

Time to take a closer look at the P-State and iGPU P-State results:

AICPUPMI: CPU P-States [ (8) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 (34) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (36) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (35) 36 ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 35 36 (37) ] GPU P-States [ (4) ]

Not exactly what I hoped for, but it is a start. The first thing that you’ll notice is that CPU power management isn’t working. Apparently that is, since every P-State between 9 and 33 is missing. CPU power management however is correctly registered, and that in the correct (XCPM) mode, since I found these two in system.log:

XCPM: registered
IOPPF: XCPM mode

Please note that the (4) means 4 x 50 MHz aka 200 MHz. Which happens to be the lowest possible frequency for the iGPU. A deep sleep/wake cycle gave me this:

AICPUPMI: CPU P-States [ 8 34 35 36 (37) 38 ] GPU P-States [ 4 (9) 22 23 24 ]

Seems to be working, but I do seem to miss the top multiplier (38) for a single-core process at boot time – only showed up after a deep sleep/wake cycle. Weird. Possible due to this UEFI BIOS error:

Here the multipliers are dead wrong. Some of them are for the i7-4770K but the top multiplier is a duplication of the one below it. And even when I set the correct values manually, even then it doesn’t solve this problem. Not that I really care about it – seems to be a cosmetic only problem – since I see this in system.log:

MSR_TURBO_RATIO_LIMIT……(0x1AD) : 0x23242526

In layman terms: The MSR is initialised correctly, with the correct value, but you may want to check it when you use the default settings. Anyway. I also found this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300000800
MSR_IA32_PERF_CONTROL……(0x199) : 0x800

Meaning that my system boots in 800 MHz mode, this instead of using the top multiplier. I believe this to be another UEFI BIOS error because normally it would have been something like this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300002600
MSR_IA32_PERF_CONTROL……(0x199) : 0x2600

Maybe Gigabyte fixed this in the UEFI BIOS updates they have avilable for download on their website, but since I don’t have MS Windows… I cannot update mine. Still using F4 here.

Now. I have used/checked several different values for AAPL,ig-platform-id but here is the one that I am using right now (unmodified):

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

The reason I highlighted the two values above is simply because I figured out what they are. Note the values of fBacklightFrequency and fBacklightMax in the output (example) below:

IG:: getPlatformID: 1455 AAPL,ig-platform-id = 0x0a160000
IG:: getOSInformation: NNNN [NFB] ————————————————————————
IG:: getOSInformation: NNNN [NFB] PlatformInformation
IG:: getOSInformation: NNNN [NFB] fPipeCount : 3
IG:: getOSInformation: NNNN [NFB] fPortCount : 3
IG:: getOSInformation: NNNN [NFB] fNumFramebuffer : 3
IG:: getOSInformation: NNNN [NFB] fStolenMemorySize : 64 MB
IG:: getOSInformation: NNNN [NFB] fFramebufferMemorySize : 16 MB
IG:: getOSInformation: NNNN [NFB] fFBMemoryCount : 3
IG:: getOSInformation: NNNN [NFB] fCursorBytes : 1572864
IG:: getOSInformation: NNNN [NFB] fBacklightFrequency : 2777
IG:: getOSInformation: NNNN [NFB] fBacklightEnable : 1
IG:: getOSInformation: NNNN [NFB] fBacklightMax : 2777
IG:: getOSInformation: NNNN [NFB] Port[0]: 00000000 / 00000000 / 00000002 / 00000048
IG:: getOSInformation: NNNN [NFB] Port[1]: 00000001 / 00000005 / 00000004 / 00000004
IG:: getOSInformation: NNNN [NFB] Port[2]: 00000002 / 00000004 / 00002048 / 00000130
IG:: getOSInformation: NNNN [NFB] Port[3]: 00000255 / 00000000 / 00000001 / 00000064

Then we convert the decimal value (2777) into a hexadecimal value. Resulting in: 0xAD9. Yes. This shows you how much fun debugging boot flags can be. Oh and let’s go back to CPU power management again.

Native PM without a ssdtPRGen generated SSDT results in:

ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3c
— power management may be incomplete or unsupported

Using Ivy Bridge like P-States (with one extra P-State) results in:

XCPM: P-state table mismatch (error:0x4)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x4
X86PlatformShim::start – Failed to send PStates

Setting Name (APLN, NN) greater than Zero results in:

XCPM: P-state table mismatch (error:0x8)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x8
X86PlatformShim::start – Failed to send PStates

p.s. I have a few more items that I like to discuss here, but I was running out of time. Maybe later. Maybe tomorrow. Don’t forget. I am getting married and we need to do a lot of shopping – need to fill the sailboat with food for our honeymoon trip 🙂

Update:

Ok. Let’s start with the changed PBlockAddress providing the system I/O address for the processors register block. Each processor can supply a different address, but from now on I’ll be using 0x1810:

Processor (CPUn, 0x01, 0x00001810, 0x06) {}

Here is the one that we have been using with previous generation motherboards:

Processor (CPUn, 0x01, 0x00000410, 0x06) {}

As a reminder. Then I looked at some of the other values I get from my AppleIntelCPUPowerManagementInfo.kext

MSR_PMG_CST_CONFIG_CONTROL.(0xE2) : 0x1E000005

Not the value I expected and thus I looked in the Intel datasheet. Just to be sure. Nope. Bit-10 (0x400) isn’t set. The lowest three bits are also set to a reserved value (0x05) but it should have been 0x04 to signal C7 package C-State limit. But it isn’t. Which is strange because if you look at this:

MSR_PMG_IO_CAPTURE_BASE….(0xE4) : 0x21814

Here we not only see the new LVL_2 Base Address (0x1814) but also that bit-17 (0x20000) is set. This specifies the encoding value of the maximum C-State code (C7) name to be included when IO read to MWAIT redirection is enabled by bit-10 of MSR_PMG_CST_CONFIG_CONTROL.

The question is why this value isn’t matching up with the other MSR’s but I guess that this is something that we need to figure out later on.

p.s. I have updated ssdtPRGen already, but since it is getting late already… I haven’t pushed it out to the Git repository. Want to verify a couple of things before I do. Not going to happen today. Need my sleep or bad things may happen during our trip…