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!