Long mode

Just wondering; why wasn’t the 32-bit Chameleon code ported to 64-bit?

Think about it guys. That would really have made our life easier. Here is one example. Porting the disassembled _lzvn_decode function would have been pretty easy …

I first changed the Makefiles to make it compile the selected build target i.e. i386 or x86_64. For this I also had to copy the i386 directory to x86_64 and then I changed libsaio/libsaio.h like so:

-#include "io_inline.h"
+#include <architecture/i386/pio.h>

This way it includes: /usr/include/architecture/i386/pio.h instead of libsaio.h and now the errors for the x86_64 target in this file are solved.

I also added a new function called _prot_to_long to asm.s and it compiles without errors, but now I have to solve a reboot issue. And yes. I decided to switch from protected mode to long mode so that I can call decode_lzvn() without issues. Theoretically that is, because it isn’t working yet.

p.s. Oops. I clicked on “Update” instead of “Preview Change”. Now you see an incomplete article. Sorry about that. Hang in…

Friendly request…

I have been away for work yesterday and thus I had zero time for hack related stuff. I also have a friendly request. Can someone please e-mail me a patched AppleHDA.kext (8 series) from Yosemite (DP3) that doesn’t work? I need one, because here everything is working. In short. Would love to fix this issue, but I need your help. Oh and don’t forgot to run: ./AppleHDA8Series.sh with -b AppleHDA -b AppleHDAController

Thanks!

Update

Use the vanilla AppleHDA.kext only when you run AppleHDA8series.sh otherwise patching may fail.

AppleHDA8Series.sh v2.9 with Yosemite support

A week ago I blogged about my Haswell HDAU solution for Yosemite but the patch instructions (proof of concept) doesn’t work with Yosemite DP3 (Build 14A283o). Time to finally finish the AppleHDA8Series.sh update and release it. Enter version 2.9

Download

AppleHDA8Series.sh v2.9 is now available for download. Here is a little how-to:

1) curl -o AppleHDA8Series.sh https://raw.githubusercontent.com/Piker-Alpha/AppleHDA8Series.sh/master/AppleHDA8Series.sh

2) chmod +x AppleHDA8Series.sh

3) ./AppleHDA8Series.sh -b AppleHDA -b AppleHDAController

New

AppleHDA8Series.sh now includes a new automatic binary patching feature, to patch the AppleHDAController binary, which should enable HDMI audio.

Bugs

Please report bugs over at: https://github.com/Piker-Alpha/AppleHDA8Series.sh/issues
Not here. Thank you!

Update

Whoops. That didn’t work. Version 3.0 out with a few corrections. Thanks to Toleda for reporting it.

Update 2

You may see the following sound assertion in: /var/log/system.log (DP3)

Sound assertion in AppleHDAController at line 2861

Fixed by changing the connector-type data in the HDMI frame buffer from 0004 0000 to 0008 0000.

New Apple Logo’s found in boot.efi (Yosemite)

Three weeks ago I blogged about the new EFI images and sound files that I found in Yosemite DP1 and today I also found the Apple logos and clut data for said logos in boot.efi.

0x39fb0-0x3a51f AppleLogoPacked
0x3a520-0x3a64f AppleLogoClut
0x3a650-0x3b3af AppleLogo2XPacked
0x3b3b0-0x3b51f AppleLogo2XClut

0x3b520-0x3b8af AppleLogoBlackPacked
0x3b8b0-0x3b8ef AppleLogoBlackClut
0x3b8f0-0x3c0af AppleLogoBlack2XPacked
0x3c0b0-0x3c0ef AppleLogoBlack2XClut

The clut data is unpacked, but the Apple logo data is compressed with the new LZVN compression algorithm. I believe that this is either a variant of LZSS (Lempel–Ziv–Storer–Szymanski) or LZMA (Lempel–Ziv–Markov) but I am still waiting for ‘coercion’ to publish his ASM->C port.

And since LZVN uses opcode tables, here is where I found the 8KB (4 x 2KB) data for the Apple logos.

0x37fb0-0x39faf 4x2KB opcode tables for the logos.

Conclusion

In short. We now have Apple logos in three different files:

1) boot.efi
2) IOGraphicsFamily.kext
3) AppleLogo.efires

Still need to figure out why, but perhaps that the new AppleLogo.efires file was added for people with a hackintosh. Nah. I am just kidding. Must be for legacy support or something. Oh wait. That is hackintosh only these days. Right?

Update

Logos with “black” in the name are white. Not black. Used on hardware with BlackMode activated.

Edit: Typo fixed.

Haswell HDAU solution for Yosemite

Back in September 2013 I blogged about my findings for the Haswell HDAU solution. Not that I needed it, since I don’t even own a HDMI monitor, but back then nobody solved the puzzle so I took on the challenge and went looking for a solution. This time around it was a lot easier, because now we know what to patch :-)

Yes. Maybe I should have stopped here, but I didn’t. No. I did not cut corners but instead I went in deep and looked for a simple solution. One that doesn’t require Xcode (for nm and otool) and only uses three command line tools (grep, perl and xxd).

Saying Thanks

There was also another reason why I did it: I admire people like Toleda who commit their fee time, and energy, to help us to get audio going. Right. My work here is only facilitating a small part of his excellent work for our community. And you know what. Most of us would be nowhere without his help, so don’t forget to say thanks when you use his work. And I know that I do so here goes:

Thank you David!

My late sister Sam was also involved, because Sam figured out how we can extract and repack the audio resource files (xml.zlib). And let me tell you this. It’s been two year since her passing, but we still feel the emptiness. Even today I am trying to get over it, and the last two weeks have been particularity hard for me. That was also why I went quite. I just needed some time for myself and my family.

Proof Of Concept

Ok. With that set aside I like to share something with you that has been confirmed to work for Yosemite. Just a few lines of code taken from a script that I am working on, but this made it work for Toleda:

1) xxd -ps AppleHDAController | tr -d ‘\n’ > /tmp/AppleHDAController.txt

2) /usr/bin/perl -pi -e ‘s|3d0c0a0000740e3d0c0d00|3d0c0a0000740e3d0c0c00|g’ /tmp/AppleHDAController.txt

3) /usr/bin/perl -pi -e ‘s|3d0c0a00000f84830100003d0c0d00|3d0c0a00000f84830100003d0c0c00|g’ /tmp/AppleHDAController.txt

4) /usr/bin/perl -pi -e ‘s|3d0c0a0000745ee9180100003d0b0d00007f103d0c0c00000f8496000000|3d0c0a0000745ee9180100003d0b0d00007f103d0c0c0000744b90909090|g’ /tmp/AppleHDAController.txt

5) xxd -r -p /tmp/AppleHDAController.txt /tmp/AppleHDAController

This way you won’t have to wait – I can be really busy at times – and can you enjoy HDMI audio like before.

Edit: I f*cking hate it when wordpress.com thinks to be smart and “correct” my text, with text that does not make sense.

Update

I like to add a clarification. Let’s start with the binary patch that I used to patch the first Developer Preview of 10.9, which by the way should still work with Yosemite:

/usr/bin/perl -pi -e ‘s|3d0c0a0000|3d0c0c0000|g’ /tmp/AppleHDAController.txt

All it does is that it changes the cmp eax, 0xa0c instruction in AppleHDAController:edidIsValidForAudio() and AppleHDAController:gfxMatchedHandler() into cpm eax, 0xc0c.

This part however did not make it into AppleHDA8Series.sh because of two reasons. First. HDMI audio worked without this patch but more importantly, perl failed to patch data with patterns with \x0a (think form feed) in it. That is also why I changed a jmp instruction. Simply because that worked in AppleHDA8Series.sh

This is perfectly fine for Chameleon and Chimera, since that cannot patch AppleHDAController, but Clover can, and since Dimitry uses Clover… he had to figure out a way that did not require re-calculation of the jump address that I changed. And he did, but only after I solved the puzzle. Still. All credit goes to Dimitri for figuring out his alternative (one part of the patch instruction). Which has to be said, fair is fair, is much better suited Clover and RevoBoot users.

Now back to AppleHDA8Series.sh because my next update will be able to do the calculation for you, and that won’t check two, but only one codec ID. Something that is still impossible with Clover. In the end it’s all the same. HDMI audio works… but now we have yet another way of patching files. Something that previously failed to work for me ;)

New style of AppleHDA.kext patching for Yosemite

In Januari I blogged about a New style of AppleHDA.kext patching (take III) for Mavericks, and today I changed AppleHDA8Series.sh for Yosemite – tested with 14A261i.

Download

AppleHDA8Series.sh v2.8 is now available for download and here is a one liner how-to:

curl -o AppleHDA8Series.sh https://raw.githubusercontent.com/Piker-Alpha/AppleHDA8Series.sh/master/AppleHDA8Series.sh

Bugs

Please report bugs here: https://github.com/Piker-Alpha/AppleHDA8Series.sh/issues
Not here. Thank you!

Edit

HDMI audio is not yet functional, but I am working on a new update that should, hopefully, eliminate manual patching altogether. At least for people who use my AppleHDA8Series.sh script. And you know what. It may even be better than what Clover offers today, because with Clover you still need to know the exact data pattern that you want to alter. Not something you should have to deal with, with every OS update, and that is why I like to introduce something new. Something so simple that it makes me wonder why nobody, including me, ever thought about it.

iMac14,4 Geekbench result / SMBIOS data

Here is the Geekbench score of the brand new entry-level iMac with the Intel Core i5-4260U processor running @ 1.40 GHz.

Geekbench_iMac144

New model identifier

The new iMac has a new Mac model identifier (iMac14,4) so now we have these four:

iMac14,1
iMac14,2
iMac14,3 (Build-to-order)
iMac14,4

New board-id

The new iMac also uses one of the previously discovered board-id’s and thus now we have these:

Mac-031B6874CF7F642A (iMac14,1)
Mac-27ADBB7B4CEE8E61 (iMac14,2)
Mac-77EB7D7DAF985301 (Build-to-order iMac14,3)
Mac-81E3E92DD6088272 (iMac14,4)

RevoBoot SMBIOS data

Here is the new SMBIOS data for RevoBoot, but you can easily adapt it to Chameleon, Chimera or Clover.

#define SMB_BIOS_VERSION	"IM144.88Z.0179.B03.1405241029"
#define SMB_PRODUCT_NAME	"iMac14,4"
#define SMB_BOARD_PRODUCT	"Mac-81E3E92DD6088272"
#define EFI_MODEL_NAME		{ 'i', 'M', 'a', 'c', '1', '4', ',', '4' }

Serial numbers

And to make the data complete… here are some serial numbers for you ;)

G56K – iMac (21.5-inch, Mid 2014)
G56J – iMac (21.5-inch, Mid 2014)

The page is not there right now, but should soon be made (Edit: Done. Available right now).