148 replies to this topic

[DoiX]

Oh damn, numpad was off. I meant after DP2 and Yes, it works. On clover however it does a funny thing, it fills my screen with artifacts/glitches.

*further clarification: on the first and second ML DP i could boot normally, starting with DP3 this bug got introduced, at first i thought it's because i was using old kexts to get some things working (it happened on 10.7.4) but it turned out that wasn't the case.

[bcc9]

DoiX, on 15 July 2012 - 08:52 AM, said:

Oh damn, numpad was off. I meant after DP2 and Yes, it works. On clover however it does a funny thing, it fills my screen with artifacts/glitches.

I think I saw that with clover, and it was due to clover defaulting the board-id poorly for intel HD graphics.  Try <key>Board-ID</key><string>Mac-94245B3640C91C81</string> in your config.plist.

DoiX, on 15 July 2012 - 08:52 AM, said:

ver*further clarification: on the first and second ML DP i could boot normally, starting with DP3 this bug got introduced, at first i thought it's because i was using old kexts to get some things working (it happened on 10.7.4) but it turned out that wasn't the case.

I suspect the issue is that the newer DPs have the 32 bit kexts stripped, and so the system loads faster, and so the timing bug is then uncovered.
From digging a bit deeper, the bug seems to be that IOAHCIBlockStorage only sends out its Identify command once, presumably the disk is not ready at that point, and so the identify fails (and the driver doesn't retry sending this command.  Adding a kprintf() before the identify operation slows things down enough for things to work.  Still investigating...

PS: What kind of disk are you having trouble with, samsung?  (My two problem disks are samsungs)

[DoiX]

Mine is Toshiba, 7200RPM.

I already have that board ID set. With chameleon my system was more forgiving when it came to bugs, but on clover it's another story, if a kext or setting in the conf file isn't okay for my laptop the whole screen gets filled with artifacts. Anyway, debug=8 is causing the artifacts ( i tried to check the source code of clover but i HATE source forge, so i didn't find anything) i believe it's still reporting every debug on a subsystem level but yet again, i have no idea how clover works.

Wouldn't using a non 32bit stripped AHCIBlockStorage kext fix this or ML made it impossible to use even it? Also, i have no idea how you managed to add kprintf() in binary, could you enlighten me on this subject? I consider it valuable knowledge to know how to binpatch kexts.

[bcc9]

DoiX, on 15 July 2012 - 06:13 PM, said:

I already have that board ID set. With chameleon my system was forgiving related to bugs, but on clover it's another story, if a kext or setting in the conf file isn't okay for my laptop the whole screen gets filled with artifacts.

I also had to set <key>ProductName</key><string>MacBookPro8,1</string>, maybe that was it (sorry I did very limited clover testing)

DoiX, on 15 July 2012 - 06:13 PM, said:

Anyway, debug=8 is causing the artifacts ( i tried to check the source code of clover but i HATE source forge, so i didn't find anything) i believe it's still reporting every debug on a subsystem level but yet again, i have no idea how clover works.

Wouldn't using a non 32bit stripped AHCIBlockStorage kext fix this or ML made it impossible to use even it? Also, i have no idea how you managed to add kprintf() in binary, could you enlighten me on this subject? I consider it valuable knowledge to know how to binpatch kexts.

You can just do a simple 'svn co https://cloverefiboo...t/cloverefiboot cloverefiboot', and then you don't need to use the web page for anything.
It's more like the opposite - I suspect if you go back to DP2 and lipo -thin x86_64 your FAT kexts that the timing bug would occur there too.

As for the kprintf, the kprintf is in the production code, so turning on those two debug options cause it to actually execute (and output slowly via the serial port, thus the time delay).
I suspect I could patch the first kprintf in the kext with an unconditional IOSleep(100) or IODelay(100*1000) to fix the timing without any debug switches required.

[DoiX]

Also set, i even injected the proper snbplatform id and several other settings to reduce artifacts (been doing this since lion). Duh, snv co. Totally forgot about it, i guess i got turned down by the folder structure. I'm used to the simple and clean chameleon one.

It's really a stupid bug... being to fast breaks stuff. Really apple? I'm curious tho if this happens on MBPs/SSDs as well. Guess we have to wait for ML to go live to see.

Well, i assume you can do the same thing with a patched IOPCIFamily kext, having the sources would make it a lot easier.

[bcc9]

As for bin patching, I patched the run-time checks of the ahcidisk debug variable.
Basically the driver code is full of statements resembling:
if (ahcidisk & 0x1) kprintf(...)
a patch might be to change this to a unique bit check:
if (ahcidisk & 0x8) kprintf(...)
then if you boot with ahcidisk=8, only that 1 kprintf() is executed.
I bisected the problem that way (using a perl script to make the patching automated).

Quite tedious, I normally would just slap a gdb debug session on the problem, but since this is a timing issue...

[DoiX]

bcc9, on 15 July 2012 - 06:51 PM, said:

As for bin patching, I patched the run-time checks of the ahcidisk debug variable.
Basically the driver code is full of statements resembling:
if (ahcidisk & 0x1) kprintf(...)
a patch might be to change this to a unique bit check:
if (ahcidisk & 0x8) kprintf(...)
then if you boot with ahcidisk=8, only that 1 kprintf() is executed.
I bisected the problem that way (using a perl script to make the patching automated).

Quite tedious, I normally would just slap a gdb debug session on the problem, but since this is a timing issue...

Ah, i see. Thanks for clearing that up. It's quite tedious indeed, makes me think you're really bothered by this problem.

[bcc9]

DoiX, on 15 July 2012 - 06:50 PM, said:

It's really a stupid bug... being to fast breaks stuff. Really apple? I'm curious tho if this happens on MBPs/SSDs as well. Guess we have to wait for ML to go live to see.

Well on genuine apple hardware, the ahci controller is configured differently than with these gigabyte motherboards. For example, on the gigabyte, the internal ports are listed as hot pluggable, and ALPM power management is disabled.  On apple hardware, I see the opposite.  Apple reports these internal gigabyte SATA ports as if they were external...
Some of these differences may affect the timing or disk drive state at the point that the AHCI kext is started.

The timing problem is probably not seen on genuine mac hardware, else the problem would have been fixed before 10.8 went gold.

DoiX, on 15 July 2012 - 06:50 PM, said:

Well, i assume you can do the same thing with a patched IOPCIFamily kext, having the sources would make it a lot easier.

I'm not sure why you're bringing up this other kext.  Yes we have the source for that one, and so yes it has been a lot easier to debug the problems with that kext.

DoiX, on 15 July 2012 - 06:55 PM, said:

Ah, i see. Thanks for clearing that up. It's quite tedious indeed, makes me think you're really bothered by this problem.

Some of the other kexts I debugged are also binary only and were a lot more involved to debug.  If I had not done so, we wouldn't have the custom personality editing for ATI and Intel graphics. working HDMI audio for certain nvidia graphics hardware, and on&on.
It's worth getting to the bottom of these things - else the system only works sometimes or incompletely.  Might as well stick to genuine mac hardware if one has no interest in getting one's hands dirty debugging the details.

[DoiX]

bcc9, on 16 July 2012 - 01:56 AM, said:

I'm not sure why you're bringing up this other kext.  Yes we have the source for that one, and so yes it has been a lot easier to debug the problems with that kext.

I brought it up only to get confirmation that one could do that .

bcc9, on 16 July 2012 - 01:56 AM, said:

Some of the other kexts I debugged are also binary only and were a lot more involved to debug.  If I had not done so, we wouldn't have the custom personality editing for ATI and Intel graphics. working HDMI audio for certain nvidia graphics hardware, and on&on.
It's worth getting to the bottom of these things - else the system only works sometimes or incompletely.  Might as well stick to genuine mac hardware if one has no interest in getting one's hands dirty debugging the details.

Like i said earlier, it's a handy skill to know how to do what you do, at least in this community, which kinda lacks devs in my opinion.. at least compared to the golden age of Osx86 scene.

[bcc9]

Here's a script that will patch your IOAHCIBlockStorage kext to cause its start to be delayed by 200ms. 200ms is more than twice as long as I've found necessary to avoid the dreaded "Still waiting for root device" error. This patch can be used instead of the somewhat fragile debug=8 ahcidisk=1 workaround. This may be the best patch I can come up with - I don't see how to patch the AHCI controller to change its configuration (the hot plug-ability , and ALPM support).

Original 10.8-only patch script:  patch-ahci-mlion-0.1.zip   729bytes   987 downloads
Update: newer version of the fix is attached to post #1.

[bcc9]

DoiX, on 16 July 2012 - 07:15 PM, said:

I brought it up only to get confirmation that one could do that .

Ah yes, for sure it's a lot easier with source!  I was for example able to pretty quickly find the original npci=0x2000 workaround to the common "PCI Configuration Begin" hang using the source.  It would have taken a bunch more effort to find that workaround without source.

DoiX, on 16 July 2012 - 07:15 PM, said:

Like i said earlier, it's a handy skill to know how to do what you do, at least in this community, which kinda lacks devs in my opinion.. at least compared to the golden age of Osx86 scene.

Yes, though it is understandable that development is slow, given how little support developers get.  When one's work is successful, it seems the reward is lots of newbie questions and or your work is just incorporated into someone else's script without attribution.  The lack of attribution is not merely a matter of intellectual bad manners, it leads to subsequent improvements and issues not making it back to the developer.  Most developers combat this somewhat by making their own web site, but that's not a great solution for US based hackintosh'ing (where the reward for success would be a take-down notice).

Oops, I'm getting pretty off topic now.

[DoiX]

Script is working perfectly

So you're the brains behind 0x2000. I've read dozens of pages about people complaining about that error and using that flag to fix it.... but none of them even mentioned you (or even know what the hell it does).

I was actually wondering (after reading this ) if apple takes action against hackintosh projects in the U.S, it would be silly to leave it slide considering they almost sued the artist in the linked article. Wouldn't it be better for the recognition of devs if InsanelyMac would provide mini sites to them? Like the current blog system but with higher visibility, or even the Wiki system.

It's your topic, as far as i'm concerned you can start writing poetry here.

[TimeWalker75a]

The patch has worked for my machine as well, thank you.
Im unable to send you a PM (you have set it so apparently). I know that it's not the right thread to ask, but I figured, since you're good with assembly it's still worth asking.
If this will lead to anything good it may be carried out to a dedicated thread.

here it goes...


Hey,
I have been tinkering with HDA binary from GM build of ML for some time trying to reenable support for my ALC269 and a bunch of other codec. I have previously figured an algo similar to what RevoGirl was using. Sadly, Sam is not with us anymore, so I can't really ask her what has changed dramatically in the binary (apart from that it's not a fat macho-O anymore and IDA Pro won't let me disasm it and so won't OTX). So, since I know you are really good with assembly code I took a wild guess and thought you might help finding a spot on solution.

Now, in 10.7 I used to patch the binary like that:
1. substitute the Wolfson codec id 0x1aec87ff with my 0x10ec0269 in 4 occurencec (just 2 now, 1 in function group call and another in widget call, since the binary is arch x86_64 only)
2. instead of doing jg (0f 8f) i changed it to do je (0f 84)
3. instead of making a jump if greater to a procedure group of enabling Wolfson WM8800 codec functiongroup and widget I made it jump to an address that is being called for AD1984 codec (0x11d41984). those eliminating some check. I've recalculated the binary patch by taking the address of a procedure block related to AD1984 - the address of jg (now je) operator of Wolfson codec (now mine) and - 6 bytes. Doing a byteflip so changing the address to which je does the jump to procedure block of AD1984. This has worked flawlesly for the past versions of Lion and up to DP3. In DP4 things got complicated and binary chnaged dramatically.

What I've been able to figure out hose far is that the basic principles I used before still apply. I can replace the wolson's id with mine and I can recalculate the addres to AD1984.
Basically for the new binary the patch is the following:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x53\x01\x00\x00|\x69\x02\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|\x69\x02\xec\x10\x0f\x84\x53\x02\x00\x00|g' AppleHDA

This patch was confirmed to work by some pals of mine for ALC892 and ALC889 also AL665.

What I have found though is that in 10.7 the function group and widget used to be called directly by their respective function names.
This is done after the jump is made to an address specified for AD1984 (and now the patched codec id 0x10ec0269 which also jumps to the same address eg. 0x0003d9d2 and 0x0003ff08 in the below code snippets)

This is 10.7:

000000000003d99b	cmpl	$0x11d41984,%ebx
000000000003d9a1	je	0x0003d9d2

000000000003d9d2	movl	$0x000000f0,%edi
000000000003d9d7	callq	0x0003d9dc
000000000003d9dc	testq	%rax,%rax
000000000003d9df	movq	%rax,%rbx
000000000003d9e2	je	0x0003dc2b
000000000003d9e8	movq	%rbx,%rdi
000000000003d9eb	callq	__ZN27AppleHDAFunctionGroupAD1984C1Ev <- note this part
000000000003d9f0	jmp	0x0003dc2b <-all codecs are sent here for a test ?

000000000003dc2b	testq	%rbx,%rbx
000000000003dc2e	jne	0x0003dc4a <-if it returns 0? then jump, else cnt (this wil give assertion error in IOLog, but still will call the same address after the error is displayed)

000000000003dc4a	movq	%rbx,%rax
000000000003dc4d	addq	$0x08,%rsp
000000000003dc51	popq	%rbx
000000000003dc52	popq	%rbp
000000000003dc53	ret

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

000000000003ff08	movl	$0x00000530,%edi
000000000003ff0d	callq	0x0003ff12
000000000003ff12	testq	%rax,%rax
000000000003ff15	movq	%rax,%rbx
000000000003ff18	je	0x0004010f
000000000003ff1e	movq	%rbx,%rdi
000000000003ff21	callq	__ZN20AppleHDAWidgetAD1984C1Ev  <- note this part
000000000003ff26	jmp	0x0004010f <-seems like and address where all codecs are getting verified

000000000004010f	testq	%rbx,%rbx
0000000000040112	jne	0x0004012e

000000000004012e	movq	%rbx,%rax
0000000000040131	addq	$0x08,%rsp
0000000000040135	popq	%rbx
0000000000040136	popq	%rbp
0000000000040137	ret

in 10.8 this not like that anymore. if I undersigned that correctly instead of calling the function,it stores the function group metaclass address into a register.
then proceeds with indirect register to register addressation and this is the part when I get lost, because I'm only familiar with 8080 assembly code

000000000003f385	cmpl	$0x11d41984,%eax
000000000003f38a	je	0x0003f4fa

000000000003f4fa	leaq	0x0002eccf(%rip),%rax <-here it stores the address of __ZN27AppleHDAFunctionGroupD19849metaClassE; AppleHDAFunctionGroupAD1984::metaClass
000000000003f501	jmp	0x0003f4c0 <- this seems like an address where all the codecs are sent to enable functiongroup

000000000003f4c0	movq	(%rax),%rdi
000000000003f4c3	movq	(%rdi),%rax
000000000003f4c6	call	*0x00000088(%rax) < this seems like a qword ptr call ? [rax+88h] ?
000000000003f4cc	movq	%rax,%rbx
000000000003f4cf	testq	%rbx,%rbx
000000000003f4d2	jne	0x0003f4f0 <- if test returned flag state 0? else proceed to show assertion error in IOlog

000000000003f4f0	movq	%rbx,%rax
000000000003f4f3	addq	$0x08,%rsp
000000000003f4f7	popq	%rbx
000000000003f4f8	popq	%rbp
000000000003f4f9	ret

kind of similar with the widget

000000000004171f	cmpl	$0x11d41984,%eax
0000000000041724	je	0x0004187c

000000000004187c	leaq	0x0002d8ad(%rip),%rax <- store metaclass address ?
0000000000041883	jmp	0x0004184d <- again, thi seems like and address to which all the codecs are send for verification ?

000000000004184d	movq	(%rax),%rdi
0000000000041850	movq	(%rdi),%rax
0000000000041853	call	*0x00000088(%rax)
0000000000041859	testq	%rax,%rax
000000000004185c	jne	0x0004187a

000000000004187a	popq	%rbp
000000000004187b	ret

the widget call procedure's final part seem to differ a little compared to 10.7, but the FG call is mostly identical.
now, how do I figure what it calls for in call *0x00000088(%rax) in both the FG and widget cases? I have been pointed out that if you open up the binary in say, HexFiend, and switch to text filed search you now have widget and function group names with corresponding ID in plane ASCII. On my desktop machine I have an ALC888, and I usually patch out the 885 codec. In 10.8 I had to patch the _10EC0885 to _10EC0888 in AppleHDAFunctionGroup_10EC0885 and AppleHDAWidget_10EC0885 (to allow my codec to work, otherwise it would freeze.
sudo perl -pi -e 's|\x5f\x31\x30\x45\x43\x30\x38\x38\x35|\x5f\x31\x30\x45\x43\x30\x38\x38\x38|g' AppleHDA
Now with the perl lines I've provided above for mentioned codecs (AL892 and 889) people don't seem to need any ASCII alterations, which seems weird to me.

Could you possibly help me to figure out why is the patch that I calculated  worked for the others and not for me? Usually, in 10.7 and in DP3 the same patch was applicable for all 3 codec (ALC889, ALC892, ALC269 and also ALC271 as it's identical to 269) only the IDs needed to be changed.

If you need me to provide any additional info or files i will do ASAP.
Thank you in advance.

[bcc9]

DoiX, on 17 July 2012 - 01:00 AM, said:

Script is working perfectly

Great.  So I wonder if your clover problem cleared up too by not using debug=1, or whether you are having some other problem there.

DoiX, on 17 July 2012 - 01:00 AM, said:

So you're the brains behind 0x2000. I've read dozens of pages about people complaining about that error and using that flag to fix it.... but none of them even mentioned you (or even know what the hell it does).

Yes indeed.  I first solved the problem for the 1340 laptop and then the info was relayed to netkas's blog comments and then the information spread all over.
It's a lot like this problem in that a simple kernel boot argument or two has the ability to work around the underlying issue (PCI relocation).
This timing issue seems to affect far less users whoever.

DoiX, on 17 July 2012 - 01:00 AM, said:

I was actually wondering (after reading this ) if apple takes action against hackintosh projects in the U.S, it would be silly to leave it slide considering they almost sued the artist in the linked article.

Well I wouldn't want to publicly give my lay opinion of hackintosh legalize, but I'd note that alleged DMCA and EULA violations sometimes lead to legal action, especially if money changes hands (and forums that solicit contributions from users resemble that).

DoiX, on 17 July 2012 - 01:00 AM, said:

Wouldn't it be better for the recognition of devs if InsanelyMac would provide mini sites to them? Like the current blog system but with higher visibility, or even the Wiki system.

Perhaps.  Seen a lot of wikis that don't get kept up.  A wiki that actually detailed best current practices would be quite cool.

[bcc9]

Some good news -
I upgraded my motherboard to UEFI bios and the timing issue went away (system boots osx 10.8 fine without the AHCI patch or debug options).
I did notice that with the gigabyte UEFI bios, the AHCI driver reports the AHCI ports as not hot-pluggable, just like with geninue mac hardware, instead of as hot-pluggable like with the gigabyte legacy bios.  I wonder if this is the difference or it's some other side effect.  In any case, I still don't see how to control these AHCI port settings outside of he bios, but at least it seems like a solvable problem from the bios end of things.

[bcc9]

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

The patch has worked for my machine as well, thank you.

Ok great.  But I'm surprised to hear you say that - your last two posts insisted that the bug did not exist as of the 10.8 DP security update.  At least for you and numerous other applelife.ru folks.  (I did also check the applelife.ru forum and could only find your one post...)

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

Im unable to send you a PM (you have set it so apparently).

No, it's just my mailbox filed up as people keep PMing me for tech support (instead of posting in the threads like I keep asking).  I've cleaned out a few more posts now; the new forum no longer is notifying me when m box is full.
I wish people would stop asking me about mobile ATI/Intel hardware when I've never used such hardware with a hackintosh

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

I have been tinkering with HDA binary from GM build of ML for some time trying to reenable support for my ALC269 and a bunch of other codec.

Great, I was about to hack mine and I could use some help

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

I have previously figured an algo similar to what RevoGirl was using.

I didn't pay close attention but I believe s/he was just using information from others (such as my applehda patch).  I was the first to identify when the applehda binary changed to necessitate patching the range comparisons, here:
http://www.projectos...indpost&p=14993
and:
http://www.projectos...indpost&p=15205
my patch script is in turn based upon aschar's one-liner:
http://www.projectos...findpost&p=9687

all built on top of earlier AppleHDA knowledge such as found in The King's guide of course.

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

Sadly, Sam is not with us anymore,

Allegedly.  At least that user is gone from another forum as had happened repeatedly in the past.

TimeWalker75a, on 17 July 2012 - 09:32 AM, said:

IDA Pro won't let me disasm it and so won't OTX). So, since I know you are really good with assembly code I took a wild guess and thought you might help finding a spot on solution.

IDA pro will disassemble 64 bit osx binaries.  It's just the hex-rays decompiler not supporting x86_64 (surely there must be an update to hex-rays on the way??)
otx supports x86_64, you just need to compile it from source instead of using the antique .pkg which was for i386/ppc.  I was thinking of trying to add vtable & 64 bit relocation table support to otx at which point lacking hex-rays wouldn't be much of a handicap

Ok, the rest of your post is pretty involved; looks like I'll have to take a look at the 10.8 AppleHDA code before I can give you a real answer - I haven't had a chance yet.

I swear I already saw someone claiming they had the 10.8 GM version of AppleHDA patched correctly for alc889?

[Mohamed Khairy]

thanks bcc9
you always do best

this problem was annoying me on my notebook make me must boot with caches on (MBR) and this causes artifact on screen

now it load with caches and it is fine

---------------------------
if you free do you mind to sent PM about developing voodoo ps2 controller  ( the touchpad kext )

[TimeWalker75a]

Quote

Ok great. But I'm surprised to hear you say that - your last two posts insisted that the bug did not exist as of the 10.8 DP security update. At least for you and numerous other applelife.ru folks. (I did also check the applelife.ru forum and could only find your one post...)

Well, I was surprised after installing the GM build - the problem reverted back in this version of ML, however it wasn't there after applying the DP4 A256 updated (security one I have mentioned previously.)

I have a Vostro 3450, which has a SecureCore Tiano UEFI bios (you might have seen that in my signature on the other forum), which is identical to the one used in Inspiron N5110, see Mohamed's signature. And apparently we and all the rest of the users w/ SecureCore Taino and some Aptio-based UEFIs share the same problem for quiete some time. I also get artifacts on my HD 3000 if I boot without caches, so it was a crucial warkaround. Thank you yet again! I hope that in RTM the bug will be gone for good, because I just don't like the idea of patching so many things after each an every update and keeping it to a minimum would be great (I don't need an RTC patch anymore at least).

I took a look at your script that has a

\x83\x19\xd4\x11 range zeroing-out. This id is not in place anymore, it has been removed as of DP4. It looks like there are jump tables in place now, when a codec is sent to do a jump if equals (if id in the registry and your id matches) it is sent to a table where there are cases defined for each id. There's a by-default case and some otehrcases. It looks like ALC885 AD1984 and AD198B share the same jump table which has a  by-default id for AD198B.

Also, I was able to patch 10.7.3 and 10.7.4 binary without zeroing AD1983 out, just doing the necessary jump if equals alterations and jumping to AD1984 much like in the snipped I've provided earlier.
It basically goes like this: http://puu.sh/JwsG
1. The check sequence is initiated
2. The first in this sequence is the wolfson codec, if the id is greater proceed (jg) to the other codec to determine the id and a proper place to jump in order to call the functiongroup. You patch this to yours and make it jump if equal and specify the address of (3.) which is the address to where AD1984 is sent if the id mathces.
4. Wil determine if the flag returned 0, and 5. will proceed to call for a functiongroup.
Same thing with te widget: http://puu.sh/JwvD
So to sum up: you just had to alter the first step of the "ladder" to your id and so that it would jump to an address associated w/ AD1984 (instead of actually patching your id in place of AD1984) those eliminating some of the important checks. This will result in 0 assertion errors (at least for my codec, but you had to have hda-gfx onboard-1 to eliminate just one assertion that was related to HDMI audio).

Here how it looks in 10.8:
http://puu.sh/JzZ0
the most upper block is FunctionGroupFactory, the first block after it is the wolfson codec id verification. somewhere there in the middle lies the AD1984 which you used to patch out with your id. if the id matches after all the checks it goes to AD1984 metaclass and then to a 0x0003f4c0 where the functiongroup gets created (enabled) for the respective codec. In my patches I jump from the wolfson  block directly to AD1984 metaclass.


In case you still have 10.7.4 around you can try this w/ a clean binary, see if it works for your IDT a swell:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x96\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xfc\x01\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x7d\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xfc\x01\x00\x00|g' AppleHDA

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x97\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xcc\x01\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x7e\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xcc\x01\x00\x00|g' AppleHDA

In case it does then we can try to escalate the same method to the new 10.8 binary.

Quote

I swear I already saw someone claiming they had the 10.8 GM version of AppleHDA patched correctly for alc889?

I saw it somewhere too, but upon downloading the patched kext it turned out to be v2.3.0a57(also this version of binary is somewhat different from the one found in GM build), so the one from stock DP4 install. However upon  a quick glance through diff inspection I've found that the binary is definitely not from that version, it had more than 3k diffs, meaning it must have been from DP3 when things still worked as in 10.7. We might be speaking about different things, but I can assure you I have came up w/ the lines provided above by myself by looking at otool disassembly.

Thanks for your tip about otx, I like it's output much better. However IDA would be cool too.. I can use the console version to disasm the x86_64, but the graph it generates is a distaster to work with. It just generates plane image where all the lines are mooshed together in one fat undistinguishable nonsense.

P.S. I tried to recompile otx (rev 560 from the subversion) w/ 10.7 SDK and  standart arch. It will let me load a x86_64 binary, however it crashes upon generating the output. Do I have to have newer otools installed (from the new ML Xcode possibly?) or it's just something on my side of things? ok. nvm, CLI version is sufficient .. something is wrong w/ the GUI one.

P.S.S. I have another reported case of audio working in ML GM w/ the binary patch I have previously calculated, this time for ALC662. See THIS
Mind to try it as well ? Just swap the codec ID for your IDT. Also try the patch in my previous post as i have suggested to the person by that link.

[Mohamed Khairy]

\x83\x19\xd4\x11 range zeroing-out

-------

when it changed i searched for the thing like it

83 replaced by 8B

this code is near to the codec id that we patch

[DoiX]

@bcc9, Clover problem still persists. I'm not really bothered by it anymore. I didn't think of updating the bios, i'm still on version A06 (the latest one is A11) but probably i still wouldn't have updated because anything newer than A06 breaks sleep for some reason. And i cherish sleep more than UseKernelCache=Yes.

If you have time, could you maybe assist me in the future with some info/tips/ideas on how one could get Nvidia GPU working on OS X by binpatching the buffer check in the nvidia kexts? Only if you feel like it