Contribute
Register
Status
Not open for further replies.
I was able to "decode" most of the patches that you made. Looks like at least one person has a more native/fresh approach (eg. not using foreign DSDT) working on a U410. See: http://www.tonymacx86.com/mountain-lion-laptop-support/111458-u410-kp-after-boot.html



It is pretty easy to take an existing patched AppleHDA and pull the right parts out to patch a new version of AppleHDA. I have such a script that does the two ProBook (4x30s, 4x40s... both IDT codecs). And I have one that does a flavor of ALC269. If you remember what binary patch you used, it is easy...

you mean binary for applehda?

you mean I was messing with pins/verbs/layouts/platforms for nothing? :)


btw, what is this low res 4000 thing?
 
you mean binary for applehda?

Yes, part of patching AppleHDA is patching AppleHDA.kext/Contents/MacOS/AppleHDA. Normally using bcc9's hda patcher.

you mean I was messing with pins/verbs/layouts/platforms for nothing? :)

No. Also a necessary part of patching AppleHDA. But once you this once, you can use the same Platforms.xml.zlib and layout.xml.zlib files for the new version. So, patched AppleHDA binary, plus Resources/Platforms & Resources/layout, plus a few plist tweaks to AppleHDAHardwareConfigDriver and you have a new up-to-date patched AppleHDA.

The hard part is the first time creating Platforms.xml.zlib and layoutX.xml.zlib (where X is your layout-id).

Here is a snippet/sample script:
Code:
# patch AppleHDA.kext for Acer Aspire S3/S5 (Realtek ALC269?)
echo !!! Patching AppleHDA ALC269 !!!
unpatched=./unpatched
mkdir ./patched/ALC269
cp -R $unpatched/AppleHDA.kext ./patched/ALC269
cd patchhda.2.0
perl ./patch-hda.pl 'Realtek ALC269' -s ../patched/ALC269
cd ..
rm ./patched/ALC269/AppleHDA.kext/Contents/Resources/layout*
cp ./Resources-ALC269/* ./patched/ALC269/AppleHDA.kext/Contents/Resources/
plist=./patched/ALC269/AppleHDA.kext/Contents/PlugIns/AppleHDAHardwareConfigDriver.kext/Contents/Info.plist
/usr/libexec/plistbuddy -c "Delete ':IOKitPersonalities:HDA Hardware Config Resource:HDAConfigDefault'" $plist
/usr/libexec/plistbuddy -c "Delete ':IOKitPersonalities:HDA Hardware Config Resource:PostConstructionInitialization'" $plist
/usr/libexec/plistbuddy -c "Merge ALC269.plist ':IOKitPersonalities:HDA Hardware Config Resource'" $plist

btw, what is this low res 4000 thing?

1366x768
 
So with this SSDT (I can extract the SSDT in use from the ioreg), I see:
Code:
    Store ("ssdtPRGen version: 6.6", Debug)
    Store ("baseFrequency    : 1200", Debug)
    Store ("frequency        : 1800", Debug)
    Store ("busFrequency     : 100", Debug)
    Store ("logicalCPUs      : 4", Debug)
    Store ("tdp              : 17", Debug)
    Store ("packageLength    : 7", Debug)
    Store ("turboStates      : 0", Debug)
    Store ("maxTurboFrequency: 1800", Debug)
    Scope (\_PR.CPU0)
    {
        Name (APLF, 0x04)
        Name (APSN, One)
        Name (APSS, Package (0x0C)

What pstates were you getting according to AICPMI?

Ideally, it is good to get an ioreg dump at the same time as AICPMI output from system.log, so they are easily correlated. Otherwise it is easy to get confused if they are spread across multiple posts...

Edit: Other people have had difficulty with this type of SSDT(APLF=4), and i3 CPU, resulting in panic on boot.

So, ill put everything together for easy understanding, even i sometimes i fill lost with so much SSDT changing.

Code:
Last login: Sat Oct 12 11:37:04 on console
localhost:~ Godoy$ cat /var/log/system.log | grep "AICPUPMI:"
Oct 12 11:36:48 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 17 ]
Oct 12 11:36:51 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 17 18 ]
Oct 12 11:36:55 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 13 17 18 ]
Oct 12 11:36:55 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 12 13 17 18 ]
Oct 12 11:37:28 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 12 13 16 17 18 ]

Reading the dump from AICUPUPMI, i see that the 8 P-state is marked before the full load of OSX. The first two states are, 8 and 17, those are in the range of the Core-i5. So, p-state 18 it's only archive using a SSDT building with the p-states from 12 to 18 (more likely the same uses on a Macbook Pro). It's that possible?

There you have the SSDT that im using and a IOReg dump, all at the same time.
 

Attachments

  • SSDT.aml.zip
    677 bytes · Views: 77
  • SaturdayIOReg.zip
    352.7 KB · Views: 66
So, ill put everything together for easy understanding, even i sometimes i fill lost with so much SSDT changing.

Code:
Last login: Sat Oct 12 11:37:04 on console
localhost:~ Godoy$ cat /var/log/system.log | grep "AICPUPMI:"
Oct 12 11:36:48 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 17 ]
Oct 12 11:36:51 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 17 18 ]
Oct 12 11:36:55 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 13 17 18 ]
Oct 12 11:36:55 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 12 13 17 18 ]
Oct 12 11:37:28 localhost kernel[0]: AICPUPMI: CPU P-States [ 8 12 13 16 17 18 ]

Reading the dump from AICUPUPMI, i see that the 8 P-state is marked before the full load of OSX. The first two states are, 8 and 17, those are in the range of the Core-i5. So, p-state 18 it's only archive using a SSDT building with the p-states from 12 to 18 (more likely the same uses on a Macbook Pro). It's that possible?

There you have the SSDT that im using and a IOReg dump, all at the same time.

To me it appears that everything is working. You're getting states 8 - 18 which is appropriate according to the specs on your CPU: http://ark.intel.com/products/65697/

I'm confused as to why are are searching for different results. Those results are perfect.
 
To me it appears that everything is working. You're getting states 8 - 18 which is appropriate according to the specs on your CPU: http://ark.intel.com/products/65697/

I'm confused as to why are are searching for different results. Those results are perfect.

Is possible that the change doesn't seen to be reflected on the SMC or DCPI. In that case its ok, battery life goes around 6 or 6,5 hours, best than 5 hours i've been taken with MacBookPro 8,1 and Chamaleon p/c states.

Now it's time to build the Sound Patch with your Advanced Layout for Sound. Any advise? I'm truly a noob in this...

Thanks for the feedback Rehabman.
 
Is possible that the change doesn't seen to be reflected on the SMC or DCPI. In that case its ok, battery life goes around 6 or 6,5 hours, best than 5 hours i've been taken with MacBookPro 8,1 and Chamaleon p/c states.

SMC?

Is DPCIManager giving you different results? Make sure you leave adequate time for the system to idle. In fact, it may even be a good idea to minimize DPCIManager while testing.

Now it's time to build the Sound Patch with your Advanced Layout for Sound. Any advise? I'm truly a noob in this...

Thanks for the feedback Rehabman.

For sound you need the AppleHDA that's been patched for the U310. And I believe you will need the "Audio Layout 12 (Advanced)" but not necessarily all of it. In particular, I'm not sure the "device-id" injection is needed (realize that entries in _DSM patches are pairs). I've seen that device-id injection in some, but not others. It would be great to find out what you *actually* need. The values in that patch are actually the values for the Ux10 as seen in ikkoku's DSDT.
 
Hi ... OK..

What I was saying is that using your DSDT will make the system think you have 6-series EHC chip.

That is good to know and is a baseline for comparing patched DSDTs to find out why...
Since this is without GenericUSBXHCI, I assume there is no USB3 support in this scenario (no driver attached to XHC, no superspeed shown in System Information->USB).


weird, cuz I see usb3 support without using genericusbxhci

ScreenShot2013-10-12at124709PM_zpsc9a9d3fb.png

now I'm confused. Should I be looking somewhere else?
 

Attachments

  • ScreenShot2013-10-12at124318PM_zps9407ffc6.png
    ScreenShot2013-10-12at124318PM_zps9407ffc6.png
    70.8 KB · Views: 98
weird, cuz I see usb3 support without using genericusbxhci

View attachment 69746

now I'm confused. Should I be looking somewhere else?

Need ioreg dump to make any conclusions.

FYI: EHC and patches for EHC have nothing to do with USB3. USB3 is XHC. USB2 is EHC.
 
Need ioreg dump to make any conclusions.

Rehabman,

"There is a patch inside the ProBook Installer for patching AppleIntelFramebufferCapri.kext"

Which check mark is this, and what does this do? Right now I am trying to chase down an audio problem. Sound works, but when i press the hardware volume buttons to change the level the change is not reflected on the menu bar/slider until full mute. However, when I plug in headphones it is (I can see the icon's sound bars decreasing, down to mute)

Also, the DSDT brightness patches dont work for me. Is there something I can try to fix this for me? Right now I am using the BIOS brightness (takes forever to change and no graphical indication)
 
Rehabman,

"There is a patch inside the ProBook Installer for patching AppleIntelFramebufferCapri.kext"

Which check mark is this, and what does this do?

It is not a separate option. It is this patch (patches a copy of capri in the Desktop folder):
Code:
sudo perl -pi -e 's|\x04\x00\x00\x81.{107}\x04\x00\x66\x01.{108}|\x08\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x11\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00\x66\x01\x01\x02\x04\x02\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x20\x10\x07\x00\x00\x10\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x05\x03\x00\x00\x02\x00\x00\x00\x30\x02\x00\x00\x02\x05\x00\x00\x00\x04\x00\x00\x07\x01\x00\x00\x03\x04\x00\x00\x00\x04\x00\x00\x07\x01\x00\x00\x04\x06\x00\x00\x00\x08\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x11\x00\x00\x00\x00\x00\x00\x00\x00|' ~/Desktop/AppleIntelFramebufferCapri.kext/Contents/MacOS/AppleIntelFramebufferCapri

Background information here:
http://www.tonymacx86.com/hp-probook/96186-unified-appleintelframebuffercapri-ivy-probooks.html
and here:
http://www.tonymacx86.com/hp-probook/99533-testers-ivy-probooks-needed.html

Right now I am trying to chase down an audio problem. Sound works, but when i press the hardware volume buttons to change the level the change is not reflected on the menu bar/slider until full mute.

It is a problem with the patching done to AppleHDA. I'm not sure of the details... Have you already posted your AppleHDA somewhere?

Also, the DSDT brightness patches dont work for me. Is there something I can try to fix this for me? Right now I am using the BIOS brightness (takes forever to change and no graphical indication)

I assume you're talking about the PNLF patch ("Brightness Fix"), right? Do you have a brightness slider in SysPrefs->Display? If you do, but it doesn't work, then you should take a look at using ACPIBacklight.kext (use google to find it). It involves more DSDT work, so be prepared to learn... If your methods in DSDT for brightness work, then you can use it (not all work, for example the methods in the ProBook don't work, but fortunately the native brightness slider does).
 
Status
Not open for further replies.
Back
Top