iMac14,N (late 2013) Released

A couple of days ago Apple refreshed the iMac’s (late 2013) with Haswell processors and faster WiFi so it was time for me to have a look at the data. A bit late due to work related stuff (still waiting for a new server to arrive) but luckily it is nothing spectacular.

The first thing that I noticed is the version of OS X, being Mac OS X 10.8.4 (build 12E4022) and thus OS X 10.8.4 can be used with Haswell processors. All you need is the correct version of the mach_kernel and a hand full of kexts. The IGPU requires a couple extra kexts to get it going, but more importantly is device-property AAPL,ig-platform-id to let AppleIntelAzulFramebuffer.kext select the correct frame buffer/connector data. By the way; Apple does not set this device-property in a _DSM (ACPI Device Specific Method) but from their EFI.

Shortly after the iMac refresh Apple made two updates available for new iMac owners. The first one was Mac OS X 10.8.5 (Build 12F37) and then there was this EFI Firmware update (for both models). Something that changed the SMBIOS version to IM141.88Z.0118.B00.1309031248 and IM141.88Z.0118.B00.1309031249 respectively.

We now also have the board-id for both models, being Mac-031B6874CF7F642A and Mac-27ADBB7B4CEE8E61. The only thing that I cannot share with you are the serial numbers, but the rest should help you to change your SMBIOS settings to that of an iMac14,N.

The ACPI tables of the two new iMac models are mostly identical, with the exception of the addition of the GFX0 Method. Of course. There are a couple of other changes, but nothing really spectacular.

Want to have a look for yourself? Ok. First download acpi-extract.pl and run it in a terminal window:

sudo [perl] acpi-extract.pl

Make sure you run it from the folder with the extracted ROM files in it. You can extract the IM141_0118_B00_LOCKED.scap and/or IM142_0118_B00_LOCKED.scap file(s) with help of Andy’s PhoenixTools.

Please note that Sam’s Perl script (thanks to BlackOSX for sharing the link to the original file) only works with the extracted ROM files, but it did extract the following ACPI tables from the .scap files:

DMAR.aml
DSDT.aml
SSDT-ApCst.aml
SSDT-ApIst.aml
SSDT-Cpu0Cst.aml
SSDT-Cpu0Ist.aml
SSDT-Cpu0Tst.aml
SSDT-CpuPm.aml
SSDT-CtdpB.aml
SSDT-LakeTiny.aml
SSDT-PcieTbt.aml
SSDT-SataAhci.aml
SSDT-SDUmuxUsb.aml
SSDT-SDUsbLpt.aml
SSDT-Sdxc.aml
SSDT-TbtPEG10.aml
SSDT-TbtPEG11.aml
SSDT-UsbLpt.aml
SSDT-UsbMuxLp.aml

You can locate the files in the AML folder, but Sam’s Perl script also decompiles the ACPI tables, automatically, in a DSL folder. This way you can open them straight away. Right after the extracting processes has finished.

Ok folks. This has to be it for now. I may update this blog post at a later date, but now I have work to do (the new server finally arrived).

Update

I already changed Sam’s Perl script a little (now also extracts the DMAR table) but I have changed it even more and added the following (missing) tables to the list: APIC, ECDT, FACP, FACS, HPET, MCFG and SBST.

The problem with the data is that we need to patch it up before we compile it, and even then everything won’t be there. This because the missing address data is unknown until the EFI startup process.

Running a new updated version of Sam’s Perl script did extract all tables, but it also showed me that some of the available tools, notably IOJones, still fail to extract some essential ACPI tables. Which is too bad for such a nice tool, but using IOJones to extract the tables from newly released hardware, especially when you are looking for the data to patch your ACPI tables for power management… that won’t get extracted. Luckily we can put the data together with both tools. A bit of work, but it works.

I haven’t checked Darwin Dumper myself, but if you used it to extract data on a new MacBookAir and/or iMac then please share your results so that I can check it. Thanks!

Update-2:

The latest version of acpi-extract.pl is available for download here.

Advertisement

AppleIntelFramebufferAzul.kext (part III)

In AppleIntelFramebufferAzul.kext Part I and in AppleIntelFramebufferAzul.kext Part II we discussed a number of new/unknown/changed values (properties) and today I like to inform you about another important change.

In previous framebuffer versions from Apple it was not required to use the correct connector-type, since Apple wasn’t using/checking it, but that has changed with OS X 10.9 aka Mavericks and the release of OS X 10.8.5 so from now on you’ll need to use 8 for HDMI or HDMI audio won’t work.

You can verify this yourself by using the following two patches for Mavericks DP8:

sudo perl -pi -e 's|\x3d\x0c\x0c\x00\x00\x75\x61\xeb\x30|\x3d\x0c\x0c\x00\x00\x75\x61\xeb\x0e|g'
/System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAController.kext/Contents/MacOS/AppleHDAController

sudo perl -pi -e 's|\x3d\x0c\x0a\x00\x00\x74\x07\x3d\x0c\x0d\x00\x00|\x3d\x0c\x0a\x00\x00\x74\x07\x3d\x0c\x0c\x00\x00|g'
/System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAController.kext/Contents/MacOS/AppleHDAController

This should enable HDMI audio, and if not then your framebuffer data isn’t correct. Patching AppleIntelFramebufferAzul.kext is easy with AIFBAzul2.sh from Resolving The DP4 HDMI Hang. Use that script and start patching your frame buffer data to get HDMI audio going.

Have fun with HDMI audio 😉

Update:

Here is the frame buffer data that works for Toleda:

0300 220D 0003 0303 0000 0002 0000 0001
0000 0000 0000 0040 9914 0000 9914 0000
0000 0000 0000 0000 0105 1200 0004 0000
8700 0000 0204 1400 0004 0000 8700 0000
0306 1000 0008 0000 0000 0000 FF00 0100
0100 0000 4000 0000 0200 0000 0101 0000
0400 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000

We removed the delay of the third connector (factory data: 0306 1000 0004 0000 1100 0000) to force select port-number 7. Something that is required to get HDMI audio on this connector going. The result is port-numbers: 5 (DP), 6 (DVI) and 7 (HDMI) instead of 5, 6 and 0. We also changed the connector-type from 04 into 08 (see green byte).

The only problem is that your motherboard may use a different layout, and thus you first need to figure out where the connectors show up in IORegistryExplorer. Then you can start making the required changes.

Haswell HDAU solution

Someone asked me if I was willing to share a screenshot that shows the HDMI (HDAU) audio in all its glory. Ok. Sure. No problem. What about this screenshot:

Haswell HDAU

This is with OS X 10.9 Developer Preview 8. Take a look at the device-id. Yup. That is one of a 8-series motherboard. Enough evidence?

And sure. This error is gone also:

Sound assertion - Command/Response TIMED OUT and ( kRequestStateMatch == fCodecRequest->state = 2 ), fCodecRequest->command->codec: 0xffffff80219b5d00, fCodecRequest->command->verb: 0xF0000, fPoweredDown: 0

In fact. All AppleHDA related errors are gone. None whatsoever left. Meaning that I have MaximumBootBeepVolume set like this:

        <key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
        <dict>
                <key>layout-id</key>
                <data>
                AwAAAA==
                </data>
                <key>PinConfigurations</key>
                <data>
                AA==
                </data>
                <key>MaximumBootBeepVolume</key>
                <data>
                ZA==
                </data>
        </dict>

I also set a number of other properties, which I will explain later. In a new blog article. That is. If I don’t forget about it. Like I did with this one (MaximumBootBeepVolume) so thank you to Dmitry for the friendly reminder 😉

Update 1:
Ok. One more screenshot to convince people here. And Toleda, you are one of the folks in my inner circle. You are someone I trust and thus I am willing to share this with you, in the hope that you are willing to continue your amazing work on audio/HDMI stuff!

Haswell_Sony_TV_HDMI

You see. I am not a bad person. I am willing to share my work, but I won’t share files. Not now and not in the future. That is most certainly not going to change. But folks. Please respect my late sister and my family, or this will be the last thing you see from me.

This is why I want you to step up the plate and raise your voice when something like this happens again. Blow the suckers away. Do not ignore them. Fight them. I tell you this. It is people like you who are ultimately paying for their baseless comments so stop them now and for ever.

Thank you for cleaning the cruft from the crop. Our community seriously need it!

And here is one more screenshot. This time showing AppleHDAEngineOutput properties.

Haswell_HDMI_Properties

This shows you that it is actually working. And properly. All that we needed is someone like me who takes the time for it. I hereby also challenge everyone in our community to solve the power management problems for Haswell motherboards. Oh wait. Maybe I already have a solution for it. Oh well. Time will tell don’t you think?

p.s. I never used “npci=0x[2/3]000” – or any other kind of boot flags for that matter – and thus audio on my X79 motherboard worked from day one. Not that I use if for hacking anymore, but still. I know that it worked for all versions of OS X so I am still a bit puzzled as to why people need this boot flag to boot properly.

Update 2:

Good news folks. Toleda contacted me per e-mail and I have given him the required patch data. This means that HDMI audio should soon be available for everyone. Yah!

Here is the truth…

I like to make a statement here. I think that we need it to show you what is going on.

Ok. Some weeks ago, we, Jeroen and I were trying to solve a HDMI problem for Haswell motherboards. We worked hard and after a long hunt for the crux of the problem… we finally found it.

HDAU-solution

Then I said not to want to share this find with people who disrespect me and my family. Jeroen was OK with it and thus we shot a movie that we wanted to post on youtube. That was when something strange happened. That was when someone tried to hack Jeroens hackintosh, at the same time that we were shooting the movie for our HDMI solution. Hence us having a perfect alibi (thanks to the movie as evidence).

Now. What some of you may know is that I use a P2P anomizer (VPN). Something I worked on at school with Jeroen. Years ago. Long before I joined Google Inc. as a software developer. So we all – Jeroen, my father, my late sister and I, including six or seven other people, were all using one IP number out of a certain range (this must be why some people in the community think that we are one and the same person). Well. What can I say. It works great and we are now running a small startup business (on trial basis) with this (new) commercial product. So now even more people are starting to use these IP numbers. Surprise! surprise!

Now back to the hack. The fact is that this hack was a straight attack on a certain IP number, which we only used for hackintosh stuff. From one of our early customers. And this shows us, but more importantly the Dutch police (since Jeroen was Dutch) that it had to be someone in the community. Someone (think moderators et all) must have given out, or misused otherwise, the IP number that we were using.

Normally not a big deal. We just had a backdoor open during our testing, but what he did was wrong. Terribly wrong! Why? I tell you why. The person, and what I can tell you is that we have a letter from Dutch authorities with the identity of this person, uploaded pornographic images of naked children! So yes. We all know what is coming now. Legal action from Dutch authorities. Prosecution. Jail time for the sucker who did this.

One other thing I did not speak about is the fact that Jeroen committed suicide, not long after this event. He was sick and tired of the people in our community. That and the fact that he lost his girlfriend (Samantha) and that some of you kept on pushing him over the edge. By spreading lies about my sister. So yeah. You can now be ‘proud’ because now everyone in our community knows what kind of people you are!!!

In short: This is why I am mad as hell. This is why I won’t help anyone outside my community anymore. No thanks. I much rather die than to help brain-death people like you (you know who you are) and thus only people from the inner circle will get help. And all this thanks to some sick people in our community!

iPhone 5S Touch ID

Some of you may remember my sister blogging about a meeting she had with Steve Jobs and crew about desired features for a next iPhone, and one of them is now introduced with the release of the iPhone 5S and is called Touch ID. Others features she talked about are already introduced, and two more will be introduced in the iPhone 6.

Some of you may also recall people telling her that she didn’t know what was coming, or that it was impossible for her to knew what was coming. Like she didn’t knew what was coming. This shows you how little those people knew. They were wrong. All of them.

So funny 🙂

Yah. New Apple hardware next week

Yah. New Apple hardware (MacBook Pro) next week. What else can I say. At last. The wait is over!

Update: The flight case with my new hardware in it arrived minutes ago (I lost my MacBook Pro during my honeymoon trip to Greece). The shipment was a day late, due to a stupid typo. Resulting in some unknown number and thus I couldn’t get the goods shipped to me. No. I had to get them from the airport myself. And pay duties of course.

Anyway. I now have everything that I need (for work) again, and that is all that matters to me. Let’s see what the Android emulator does on this machine. Hopefully it runs as fast as it does on Windows, or I will be forced to use a Windows PC for Android development (just another hobby project) once again. Nah. I rather use a virtual machine. That also works. Even for me.