AppleHDA patching in Mountain Lion

[TimeWalker75a]

yes, I have calculated those here: http://applelife.ru/...e-9#post-299195

however this is only a good working solution for ALC662, 665, 889, 892. At least those were reported as working.

here are the confirmation that it worked: #1 #2 #3

These also should work:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x53\x01\x00\x00|\x62\x06\xec\x10\x0f\x84\x8f\x02\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x2f\x01\x00\x00|\x62\x06\xec\x10\x0f\x84\x53\x02\x00\x00|g' AppleHDA

Please report if they do, as these calculations don't match my codec so I'm unable to test myself. These are better, because they skip one additional jump that is used in the patch above.

[DoiX]

@TimeWalker, funny enough. Neither your patching nor the ones used by Vladlenas work, despite having the same audio chip.

[Riley Freeman]

@TimeWalker: Is there any advantage to patching out the Wolfson codec? My HDA seems to be working just fine by patching out ALC262. There's only one string to binpatch and it doesn't need to be altered when the binary changes.

 

sudo perl -pi -e 's|\x62\x02\xec\x10|\x83\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

Just curious as patching out the Wolfson seems to be more involved and isn't constant between versions.

[TimeWalker75a]

DoiX,

every perl line has an id that need to be changed to your codec' s id. if you havent changed them it just won't work. so you just can't copy and pase the lines and hope for the best.

if the solution provided by Vladlenas has not worked for you, then you have an obvious problem with your:

1. layout it

2. pathmap id

3. platforms/layout zlib

4. pinconfig data

 

 

Riley Freeman,

take a look at this graph which describes the FunctionGroupFactory logic when enabling a functiongroup for a specific audio codec: http://puu.sh/JzZ0

the green lines are true, the red line - false. basically every codec goes through a series of checks to determine if it's a valid and can use one of the predefined groups/widget that actually enable audio. the wolfson is the first one to get checked. if we substitue it with the desired id and make it not go deep into the check sequence but instead forward it to the address we need (ie the desired substitute codec, which in your case is 262) we basically eliminate the fail factor.

well, the 262 is not that far in the check sequence actually and if your codec is close enough and is able to work than you're lucky

[DoiX]

@TimeWalker75a, obviously i wasn't born yesterday in the Osx86 scene . Every bite was changed accordingly to my audio chip. Layout id/pathmap/platforms/pinconfig have all been ported from previously patched AppleHDA (that works)...

 

Found the problem: The god damn DSDT compiler introduces unicode text in the region i modified the value. Must be something with ML because on Lion it works.

Edited July 18, 2012 by DoiX

[TimeWalker75a]

Ok, than this seems really strange to me.

Try this then:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x53\x01\x00\x00|\x65\x06\xec\x10\x0f\x84\x47\x01\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x2f\x01\x00\x00|\x65\x06\xec\x10\x0f\x84\x23\x01\x00\x00|g' AppleHDA

 

If this doesn't work, then try the good old method that Vladlenas was using:

sudo perl -pi -e 's|\x85\x08\xec\x10|\x65\x06\xec\x10|g' AppleHDA
sudo perl -pi -e 's|\x5f\x31\x30\x45\x43\x30\x38\x38\x35|\x5f\x31\x30\x45\x43\x30\x36\x36\x35|g' AppleHDA

If still no, than try to add

sudo perl -pi -e 's|\x84\x08\xec\x10|\x00\x00\x00\x00|g' AppleHDA

to the above patch.

 

if after all that it still doesn't work then welcome to my boat

 

UPD:

AFAIK dsdt is 32 bit. so ML might interpretate the unicode characters wrong. so it worked after all ? which of the patches exactly ? can you confirm the one I have previously asked to test works?

[DoiX]

Uh, i spoke to soon. i repatched the kext again (vladlenas method) to make sure i didn't miss something by mistake. Still not working. I'll test the other strings you suggest.

 

I'll report back in 15 minutes or so.

[TimeWalker75a]

ok, I'll stay put.

In case all of the above fails, try to substitute 262 .. but add the ASCII patch to it as well, like so:

sudo perl -pi -e 's|\x62\x02\xec\x10|\x65\x06\xec\x10|g' AppleHDA
sudo perl -pi -e 's|\x5f\x31\x30\x45\x43\x30\x32\x36\x32|\x5f\x31\x30\x45\x43\x30\x36\x36\x35|g' AppleHDA

[nyolc8]

yes, I have calculated those here: http://applelife.ru/...e-9#post-299195

however this is only a good working solution for ALC662, 665, 889, 892. At least those were reported as working.

here are the confirmation that it worked: #1 #2 #3

These also should work:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x53\x01\x00\x00|\x62\x06\xec\x10\x0f\x84\x8f\x02\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x2f\x01\x00\x00|\x62\x06\xec\x10\x0f\x84\x53\x02\x00\x00|g' AppleHDA

Please report if they do, as these calculations don't match my codec so I'm unable to test myself. These are better, because they skip one additional jump that is used in the patch above.

Tried, these worked too

 

(edit: I'm getting sound assertion errors in console, but i'm getting those since 10.6.4 or something...)

[DoiX]

Alright, so:

 

First patch: Shows only HDMI output as a name, no specific info in System Profiler and devices section is empty, and cuts off AppleHDACodecGeneric in the IORegistry

The rest: Shows all the channels names, no specific info. Devices section empty. IOreg shows the AppleHDACodecGeneric with AppleHDA loaded beneath, but thats it.

 

In Other words, not working... so does your boat have a mini fridge?

[TimeWalker75a]

f . u encoding. ...

 

Tried, these worked too

(edit: I'm getting sound assertion errors in console, but i'm getting those since 10.6.4 or something...)

 

ok, cool. will make a note to myself then, as this is a more logical patch than the first one you've used.

yes, these are usually related to setpinconfig and powermanagement. i believe you can get rid of them, but i havent looked into it in detail...

 

In Other words, not working... so does your boat have a mini fridge?

 

ugghhh.. I guess you can try to patch out all of the ASCII, not just 2 occurrences with underscore (\x5f). I mean like this:

sudo perl -pi -e 's|\x31\x30\x45\x43\x30\x32\x36\x32|\x31\x30\x45\x43\x30\x36\x36\x35|g'  AppleHDA

basically try this

sudo perl -pi -e 's|\x62\x02\xec\x10|\x65\x06\xec\x10|g' AppleHDA
sudo perl -pi -e 's|\x31\x30\x45\x43\x30\x32\x36\x32|\x31\x30\x45\x43\x30\x36\x36\x35|g' AppleHDA

or this ...

sudo perl -pi -e 's|\x85\x08\xec\x10|\x65\x06\xec\x10|g' AppleHDA
sudo perl -pi -e 's|\x31\x30\x45\x43\x30\x38\x38\x35|\x31\x30\x45\x43\x30\x36\x36\x35|g' AppleHDA

 

If it fails, then I really have no clue what's wrong with your setup. I guess, make sure you use the right version of IOAudioFamily and also double-check that your layout id is set to one of the actual numbers used by Apple. In the event this is correct our boat shall sail on .. sadly, with no mini fridge at the moment ...

[DoiX]

@TimeWalker, could you ask vladlenas if he uses his AppleHDA.kext with the stock IOAudioFamily.kext or with the old patched one. Also if he did any extra DSDT modification?

[TimeWalker75a]

You can't use the old patched one, it is incompatible with the new zlib architecture in ML. You have to use ML vanilla one, that comes with the install.

In 10.7 he was using the stock one until i had patched the 10.7.4 recently, he is using it as of now for his 10.7 install and for 10.8 there's no solution since sources are not out yet.

He has no DSDT modifications for HDEF, he uses layout injection through Clover settings:

<key>PCI</key>
<dict>
<key>HDAInjection</key>
<string>12</string>
</dict>

I have been chatting with him a lot lately.

[DoiX]

Oh, thats better than switching distros to compile DSDT . I've tested your patches with both vanilla and your patched IOAudioFamily.kext. Using Lion's patched AppleHDA and your IOAudioFamily.kext everything works ok even on ML.

 

I've did a bit of debugging using darwindumper and comparing the results with Lion kexts. It seems to me that platforms.xml.zlib isn't getting loaded for some reason, i can't tell why.

[TimeWalker75a]

I haven't really looked into the changes to the xmls to be honest, those might be the problem you and me are not getting sound after all these patches. But for my desktop machine with ALC888 i just took both of the xmls, converted them to zlib and they work, so I just went ahead and assumed that nothing had changed dramatically .. so AL269 should also work.

 

Well, in case the principle of going around the obstacles (ie skipping most of the checks by patching wolfson out) still apply, I guess what I will be doing in the near future is taking all of the jumptables with the codec ids that are still in place in the binary, patching out the wolfson id with mine then jumping to a desired codec from jumptable. I will just need to calculate a new jump address for each codec that is found in the binary >_< this way i will be able to figure out why is AD1984 no longer working for ALC269/271 and what might be the aplicable codec as of 10.8 to patch it in the future.

[DoiX]

I'll disassemble it myself and see if can trace the problem related to platforms by comparing it to the old ones. More specifically, HDAPlatform.kext plugin to the new ML AppleHDA. It will be a long shot, but hey. Who doesn't get his fix by staring into lines of numbers?

[toleda]

Great work, must be doing something wrong. Any ideas?

Testing results with H67N/889/10.8 GM

 

10.8 AppleHDA_v2.3.0

 

FF 87 EC 1A 0F 8F 53 01 00 00

FF 87 EC 1A 0F 8F 2F 01 00 00

 

A. nyolc8 post #25

 

89 08 EC 10 0F 84 1F 01 00 00

89 08 EC 10 0F 84 FB 00 00 00

 

B. TimeWalker75a #26

 

89 08 EC 10 0F 84 8F 02 00 00

89 08 EC 10 0F 84 53 02 00 00

 

C. TimeWalker75a #31

 

89 08 EC 10 0F 84 47 01 00 00

89 08 EC 10 0F 84 23 01 00 00

 

All failed; no audio devices, same sound assertions:

7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1570
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 2200
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 217
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1055

[TimeWalker75a]

Hey, toleda!

It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)

You can try this kext http://puu.sh/K6QD

It has been put together for ALC889 by Sergey_Galan over at applelife.ru forums, which incorporates my patch used in post #25.

Even though the node distribution might be a little bit off, you should at least get some of the I\O to show up in system preferences.

If it somewhat works, then your layouts\platforms\pinconfig will need some adjustments to them.

 

If you're interested how this all goes you can try and read up on applelife. I perfectly understand that google translate is not a best experience and might seem as a waste of time, but at least you can catch the idea. Start at this post: http://applelife.ru/threads/applehda-from-mountain-lion-gm.36232/page-9#post-299106

[TimeWalker75a]

In 10.7 the situation was the following (binary from 10.7.4 analyzed)

000000000003fe11 cmpl $0x11d41983,%ebx
000000000003fe17 jg 0x0003fed1

so to get to the place of AD1984 you were previously zeroing the "AD1983" so the this check would be always positive since any positive number (which our codec id is) is > 0.

000000000003fed1 cmpl $0x11d41984,%ebx
000000000003fed7 je 0x0003ff08

the address 0x0003ff08 is unique to this codec in 10.7.4, majority of the codecs who's id can't be determined after all the checks are sent to 0x000400f5 if their id doesn't match anything along the way, some are just redirected to another codecs (like ALC261->ALC262 and ALC884 -> ALC885).

000000000003ff08 movl $0x00000530,%edi
000000000003ff0d callq 0x0003ff12
000000000003ff12 testq %rax,%rax
000000000003ff15 movq %rax,%rbx
000000000003ff18 je 0x0004010f ---- this address is common for all the codecs, its the semi-final stage to create the widget I guess

000000000004010f testq %rbx,%rbx
0000000000040112 jne 0x0004012e -- if test has not returned 0 ? then jump to this address else it will cause an assertion in the IOLog


0000000000040114 leaq 0x0001b599(%rip),%rdi
000000000004011b leaq 0x0001cf1f(%rip),%rsi
0000000000040122 movl $0x00000065,%edx
0000000000040127 xorb %al,%al
0000000000040129 callq 0x0004012e -- after the assertion message it would still proceed to the same address.

000000000004012e movq %rbx,%rax
0000000000040131 addq $0x08,%rsp
0000000000040135 popq %rbx
0000000000040136 popq %rbp
0000000000040137 ret - this returns us to where we previously were, so we can proceed to the call operation

 

000000000003ff1e movq %rbx,%rdi
000000000003ff21 callq __ZN20AppleHDAWidgetAD1984C1Ev

So, the widget element __ZN20AppleHDAWidgetAD1984C1Ev is called which in the end jumps to __ZN20AppleHDAWidgetAD1984C2Ev which jumps to __ZN20AppleHDAWidgetAD19849MetaClassC1Ev ..

the last one has a ret operator, which enables it to get back to where it left of after the call:

000000000003ff26 jmp 0x0004010f  -- this runs the test again

 

So, how I mentioned previously some of the codecs get redirected if the id is greater than the one it is compared to

000000000003fe29 cmpl $0x10ec0261,%ebx
000000000003fe2f jg 0x0003ff2b

or

000000000003fe1d cmpl $0x10ec0884,%ebx
000000000003fe23 jg 0x0003ff5a

say .. for ALC262 and ALC855 the situation would be the following.

000000000003ff2b cmpl $0x10ec0262,%ebx
000000000003ff31 jne 0x000400f5   -- if id is not equal (ZF has not been set?) send to an additional test sequence because we failed with ALC261 and now with 262
000000000003ff37 movl $0x00000530,%edi -- else we can initialize the widget much like with the AD1984 described above
000000000003ff3c callq 0x0003ff41
000000000003ff41 testq %rax,%rax
000000000003ff44 movq %rax,%rbx
000000000003ff47 je 0x0004010f
000000000003ff4d movq %rbx,%rdi
000000000003ff50 callq __ZN20AppleHDAWidgetALC262C1Ev
000000000003ff55 jmp 0x0004010f -- so if the call had a ret operator in the end of jumping through widget elements it will go to the common test sequence again ...

 

000000000003ff5a cmpl $0x10ec0885,%ebx
000000000003ff60 jne 0x000400f5 - same thing here, if we failed with 884 and failed again with 885 then were ought to be tested additionally..
000000000003ff66 movl $0x00000548,%edi - if everything is fine and id has matched then we can initialize the widget
000000000003ff6b callq 0x0003ff70
000000000003ff70 testq %rax,%rax
000000000003ff73 movq %rax,%rbx
000000000003ff76 je 0x0004010f
000000000003ff7c movq %rbx,%rdi
000000000003ff7f callq __ZN20AppleHDAWidgetALC885C1Ev
000000000003ff84 jmp 0x0004010f

 

 

now, for the other codecs that are being sent to 0x000400f5 it goes like this:

00000000000400f5 movl $0x00000530,%edi
00000000000400fa callq 0x000400ff
00000000000400ff testq %rax,%rax
0000000000040102 movq %rax,%rbx
0000000000040105 je 0x0004010f

so, as you can see, they go through an additional test sequence in order to get to the common address for the other check 0x0004010f.

so basically I went ahead and on the first check for to match the id i sent it to the location of AD1984 instead of going through all this routine.

__ZN21AppleHDAWidgetFactory20createAppleHDAWidgetEP11DevIdStruct:
000000000003fcd0 pushq %rbp
000000000003fcd1 movq %rsp,%rbp
000000000003fcd4 pushq %rbx
000000000003fcd5 subq $0x08,%rsp
000000000003fcd9 testq %rdi,%rdi
000000000003fcdc jne 0x0003fcfd
000000000003fcde leaq 0x0001b9cf(%rip),%rdi
000000000003fce5 leaq 0x0001d355(%rip),%rsi
000000000003fcec movl $0x00000036,%edx
000000000003fcf1 xorb %al,%al
000000000003fcf3 callq 0x0003fcf8
000000000003fcf8 jmp 0x000400c1
000000000003fcfd movl (%rdi),%ebx
000000000003fcff cmpl $0x10ec0269,%ebx -- here used to be the id of the Wolfson codec (0x1aec87ff)
000000000003fd05 je 0x0003ff08 -- and here used no be a jg operator that would redirect us to the id of 0x1aec8800 in case our id was greater, else it would proceed into deep hole of id matching and would fail eventually.

 

in 10.8 AD1984 and ALC885 share this "unique address" which requires them to go through only one test to enable the widget\functiongroup, whereas all of the other codecs if failed to determine the proper id are required to go through both of these tests.

 

I hope I make sense.

 

by the way, nyolc8, I hope you don't mind if we turn this thread into a discussion to this problem? Since you have decided to call it so, the title is aplicable to the content that we are discussing .. so you might as well remove the [sOLVED] tag for the title, because as a matter of fact the patching of AppleHDA in ML isn't solved yet.

[toleda]

It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)

You can try this kext http://puu.sh/K6QD

Thanks for the reply. I tried the attached AppleHDA.kext with no audio devices result. Confirmed the AppleHDA binary patch is post #25. Sound assertions:

 

7/20/12 1:51:51.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4544
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4315
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4226
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4259

[TimeWalker75a]

Well, the person who has put the kext together said that you are bound to get assertions and that he was getting these in previous ML builds as well, while using the binary patches from RevoGirl's sh script found on her Git repo ...

[bcc9]

Hey, toleda!

It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)

You can try this kext http://puu.sh/K6QD

It has been put together for ALC889 by Sergey_Galan over at applelife.ru forums, which incorporates my patch used in post #25.

Great, thank you, this one works with my alc889 codec with my gigabyte z68, and 10.8 GM.

Would be nice to put together a general patch script that would take a codec ID as input and patch AppleHDA as appropriate.

[TimeWalker75a]

That again proves that the problem of inconsistency of test results lies in the xmls from 10.7. You see, the problem is .. the offsets and therefore the addresses suffer a slight change for every version of the binary. I know how to calculate the target that we must reach for a decided codec base ie as1984/alc262/alc885. It is not hard, just the binary needs to be disassembled first. I'm not that skilled to write an app, but technically it is possible to make an app that would disasm the binary &  look for a base codec id occurrences in the dumped asm file, thet it would take occurence address, take the address of wolfson codec and calculate the new jump address by using a formula. Then it would replace the id of wolfson with ours and adjust the je operator's bytes to mathc calculated destination address.

[bcc9]

Perhaps something like my ati-personality.pl where the perl code invokes otool and the opcodes & operands of the 64 bit binary are decoded in order to figure out where the patch goes.

[TimeWalker75a]

Im sorry I have never seen this work of yours as Im not an ATI person, but it sounds just about right.

 

The basic idea is:

1. Find the address of wolfson codec occurrence and the jg opperator address that follows it.

2. Find the decided substitute codec address (say ad1984) and note the destination address that it is being sent to if id mathces

3. Take the above destination address substract the address of jg operator of the wolfson codec and substract 6 bytes which is the lenghts of the argument of jg operator

4. Swap the id of wolfson with your id, swap the jg operator to je (0f 8f to 0f 84) and replace first 2 bytes of the argument with the calculated 2 byte digit.

5. Repeat for another occurrence.