Hackintosh scene in apparent hibernation mode…

Hmm. There isn’t a lot going on in the Hackintosh scene right now is it? Almost like it entered hibernation mode. Too many lurkers. Little to none new developments. Next to a handful of people trying to solve issues that could have been solved months ago already.

Yeah. Isn’t it great when a hand full of big mouth loners kill off an entire community. I hope that you are not waiting for them to solve these issues, because it seems like they are going nowhere. Not a working solution. Not for anyone.

And by the time the first Beta of OS X 10.12 comes out… shocker! You won’t have to rely on any of them. I mean. Only one person helped me to solve the boot problems introduced by Yosemite, but nobody helped me to solve them for El Capitan. So guess what. If 10.12 comes out with what I have seen earlier today. Well. I must say this. Good luck to all of you! You are seriously going to need it, since I won’t be helping anyone anymore without you first stepping in and fix ‘issues’ like verbal abuse of a handful of suckers. First and foremost. Do not accept code theft – lack of credit – and please show some respect to me and my family! Hands off of family. Not just me and my family, but anyone else in our community too. Right. I am no longer accepting anything from anyone.

Take it or leave it. That is my final offer!

Edit: I blogged about this to reiterate what I said back in november which is that; I won’t return to the “IM Hackintosh Community” as it is. And I will not return.

The problem with some people on the Internet is that they lack reading comprehension (read, process and understand its meaning) and thus we also have to spell it out for them. Otherwise we end up with ill-thought-out posts, here and elsewhere, that pull my words out of context.

Ok. First. The IM part there refers to: insanelymac.com and thus when I said to sign off I clearly meant that I was singing out of the IM hack scene. I can, because I personally do not need IM. The people over at IM may need me/my help, but I much rather like to be productive and focus on what I do best. And we all know that I suck at helping end-users, but I won’t stay quiet when something bad happens.

Now. To the winers with their: “Grow up” and “You are a spoiled brat“. Right. That is the typical 13 year old approach, and thus your outburst won’t show up here. Feel free to come back, perhaps in a few years from now, when you are older, wiser and ready to address the issues that were brought forward. Don’t waste your time with meaningless posts here. That I will filter out anyway. Ah. So then they come with ‘censorship’. Really? Well. You may call it whatever you like, but once flagged as spam/trash… you won’t show up anymore. Not here anyway. So instead go fix something.

p.s. Don’t use services like sharklasers.com – already flagged as spam.

Beta v17.5 ssdtPRGen.sh released

We have a new update of ssdtPRGen.sh ready for download and this version (17.5) will show a notice when a file download occurs, includes a fix for an issue that I missed earlier, but more importantly. It will also fix for issue #192. Something that more people have been waiting for – for too long already – and simply because I missed the root cause of the bug.

Thanks to Tony for filing this bug report as a Github issue!

Beta v17.4 ssdtPRGen.sh released

We have a new update of ssdtPRGen.sh ready for download and this version (17.4) will show a notice for board-id’s with a restricted LFM frequency.

Notice: The LFM frequency in Mac-E43C1C25D4880AD6.plist is set to 1300MHz!
This problem can be fixed with help of freqVectorsEdit.sh from:
https://github.com/Piker-Alpha/freqVectorsEdit.sh

The affected board-id’s are:

Mac-E43C1C25D4880AD6:MacBookPro12,1
Mac-937CB26E2E02BB01:MacBookAir7,2
Mac-9F18E312C5C2BF0B:MacBookAir7,1
Mac-BE0E8AC46FE800CC:MacBook8,1
Mac-F305150B0C7DEEEF:MacBook8,2
Mac-A369DDC4E67F1C45:iMac16,1
Mac-FFE5EF870D7BA81A:iMac16,2

Edit: One of the iMac16,n models also has a CPUFloor value of 1000 MHz instead of 800 MHz so you may also want to change that. Just in cn case you want to do it manually.

One other thing that I like to share with you is that there is a “Frequencies” property in the plist, which is used by the binary of the X86PlatformShim.kext to select the FrequencyVectors data. For example. If you open /S*/L*/E*/IOPlatformPluginFamily.kext/C*/P*/X86PlatformPlugin.kext/C*/R*/Mac-BE0E8AC46FE800CC.plist then you will find three frequencies; 2400, 2600 and 2900 MHz aka the Max-Turbo frequencies of the available Mac models, but your Intel processor may run at a different Max-Turbo frequency (for a single thread load) so make sure to match it with your hardware.

All Broadwell based Macs. The problem can be traced back to the second value in the FrequencyVectors (0d000000) which equals 1300MHz. Anyway. Now you know what to do 😉

Have fun!

Thanks to ‘thePsguy’ for posting this idea on Github issues!

Oops…

Oops… I may have been sharing an e-mail address that I should not have been using for hack related stuff

VUmc.nl

Sorry, but don’t try to e-mail me – if you managed to figure it out. This is an internal one only. Of course 😉

Luckily mom is using her maiden name. Phew…

How did this end up in Vietnam?

You must have seen this picture by now

MyTableMyLampMyLivingRoom

So have I. Woke up early today and went looking for news… and then this picture showed up. Thing is. We happen to own a table and lamp shown in the reflection on that picture. Imagine my surprise. Nope. I did not post this on the Internet. Did not even made it, but I keep scratching my head. I’m so confused. Totally.

p.s. I have no comment on the phones.

Beta v17.2 ssdtPRGen.sh released

It seems like more and more people are using two processors in their hack, but the old versions of ssdtPRGen.sh were not really up to the task. Too many loose ends and hacks to keep it going. You also had to use a lot of arguments. That my friends is history. Well. In theory that is, because the problem with major code rewrites, of some of the scripts vital parts, is that I may have introduced bugs (regressions) that I have yet to catch.

Anyway. We now have a new version (17.2) available for download which should not only be easier to use, but the source is also a lot easier to read and understand. With lots of new comments.

In short. I need your help with testing!

Please download ssdtPRGen.sh and run it with as little arguments as possible. Then compare (diff -uw) the generated SSDT with the SSDT that you are using right now, and help me to make this the best release ever. So fire it up. Let’s start testing!

Start by entering ./ssdtPRGen.sh -h to find some of the changed arguments. My personal favourite is -mode custom. That combined with -p ‘E5-2680 v3’ -cpus 2 gives me what it should do for issue #179.

Notice: Custom mode enabled
Skipping ACPI table extraction from host computer!
Getting enabled Processors from…: /Users/Pike/Desktop/APIC.aml
Getting Processor declaration from: /Users/Pike/Desktop/DSDT.aml
Used ACPI processor labels:
– CP00 CP01 CP02 CP03 CP04 CP05 CP06 CP07 CP08 CP09 CP0A CP0B CP0C CP0D CP0E CP0F CP10 CP11 CP12 CP13 CP14 CP15 CP16 CP17
– CP00 CP01 CP02 CP03 CP04 CP05 CP06 CP07 CP08 CP09 CP0A CP0B CP0C CP0D CP0E CP0F CP10 CP11 CP12 CP13 CP14 CP15 CP16 CP17

Limiting the number of logical processors can be done, like before, with argument -l

Now it is up to you to confirm that it is working, or file bug reports 😉

Thank you all for your ongoing support!

Getting Safari to work with Intel® HD Graphics 530

Someone e-mailed me and asked me if Safari is working on my Skylake configuration with QE/CI and yes it is, but only with this Safari preference set:

defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIndentifier.WebKit2AcceleratedDrawingEnabled" 0

Without this setting, and a restart of Safari, it fails to even load a single page. Well. Only very, very slow perhaps, but here is the result after I set the above preference:
Safari on Intel HD Graphics 530
You can also enable the Debug menu in Safari with:

defaults write com.apple.Safari IncludeInternalDebugMenu 1

Giving you easy access to a whole lot more settings 😉

OS X 10.11.4 Build 15E27e comes without Skylake graphics drivers

Earlier today Apple seeded a new beta to registered developers of OS X 10.11.4 El Capitan (Build 15E27e) and the first things that I noticed was that the Skylake graphics drivers are missing. Apple may include the missing drivers in a future beta seed, but for now they not there anymore.

People without a Developer Program Membership can use one of the CatalogURL’s or simply download the latest beta by following this link (search for: OSXUpdCombo10.11.4DeveloperBeta.pkg).

New SMBIOS structure type 134

I haven’t seen anything about the new SMBIOS structures that Apple started to use in the late 2015 iMac’s, which I may have missed of course, but let’s look at the one that I decoded:

Handle 0x0023, DMI type 134, 20 bytes
OEM-specific Type
        Header and Data:
                86 14 23 00 32 2E 33 34 46 30 31 00 00 00 00 00
                00 00 00 00

Exactly the same version number that I get when I open System Information:

SMC Version (system): 2.34f1

But there is more. Look here:

Handle 0x0024, DMI type 221, 26 bytes
OEM-specific Type
        Header and Data:
                DD 1A 24 00 03 01 00 01 05 00 00 00 02 00 00 00
                00 39 00 03 00 00 05 00 00 00
        Strings:
                Reference Code - CPU
                uCode Version
                TXT ACM version

Handle 0x0025, DMI type 221, 26 bytes
OEM-specific Type
        Header and Data:
                DD 1A 25 00 03 01 00 01 05 00 00 00 02 00 01 05
                00 00 00 03 04 0B 00 00 95 04
        Strings:
                Reference Code - ME 11.0
                MEBx version
                ME Firmware Version
                Consumer SKU

Handle 0x0026, DMI type 221, 68 bytes
OEM-specific Type
        Header and Data:
                DD 44 26 00 09 01 00 01 05 00 00 00 02 03 FF FF
                FF FF FF 04 00 FF FF FF 31 00 05 00 FF FF FF 31
                00 06 00 FF FF FF FF FF 07 00 3E 00 00 00 00 08
                00 34 00 00 00 00 09 00 3E 00 00 00 00 0A 00 34
                00 00 00 00
        Strings:
                Reference Code - SKL PCH
                PCH-CRID Status
                Disabled
                PCH-CRID Original Value
                PCH-CRID New Value
                OPROM - RST - RAID
                SKL PCH H Bx Hsio Version
                SKL PCH H Dx Hsio Version
                SKL PCH LP Bx Hsio Version
                SKL PCH LP Cx Hsio Version

Handle 0x0027, DMI type 221, 54 bytes
OEM-specific Type
        Header and Data:
                DD 36 27 00 07 01 00 01 05 00 00 00 02 00 01 05
                00 00 00 03 00 01 05 00 00 00 04 05 FF FF FF FF
                FF 06 00 FF FF FF 07 00 07 00 FF FF FF 07 00 08
                00 FF FF FF FF FF
        Strings:
                Reference Code - SA - System Agent
                Reference Code - MRC
                SA - PCIe Version
                SA-CRID Status
                Disabled
                SA-CRID Original Value
                SA-CRID New Value
                OPROM - VBIOS

Handle 0x0028, DMI type 14, 8 bytes
Group Associations
        Name: $MEI
        Items: 1
                0x0000 (OEM-specific)

Handle 0x0029, DMI type 219, 81 bytes
OEM-specific Type
        Header and Data:
                DB 51 29 00 01 03 01 55 02 00 90 06 01 10 80 00
                00 00 00 00 40 00 00 00 00 00 00 00 00 00 40 02
                FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                00
        Strings:
                MEI1
                MEI2
                MEI3

The importance of it has yet to be discovered.

Edit: I committed a first update of SMBIOS.h for RevoBoot so that we can start using it.

By the way. Ryan Armstrong aka cavaliercoder has a Github fork of dmidecode which deserves to be forked and stared. An apparent requirement for upstream to accept his changes.

I will also update smbios2struct so that dmidecode –from-dump SMBIOS.bin can be used to read the binary data. Which is handy when you want to run dmidecode on another computer or use data that you extracted from IORegistry dumps.

Update: The source code of smbiosXtract.c is now available for download and you can compile it with:

cc smbiosXtract.c -o smbiosXtract -Wall -framework IOKit -framework CoreFoundation