[Guide] HP EliteBook 820 840 G2 I5-5300U HD5500 El Capitan [ENG]

stealthdave · Mar 16, 2016

RehabMan said:
Need ioreg and EFI/Clover (as zip, no themes).

Attached.

RehabMan · Mar 16, 2016

stealthdave said:
Attached.

Oops...

SSDT-XWAK.dsl

Code:

// Disabling XWAK

DefinitionBlock("", "SSDT", 2, "hack", "XWAK", 0)
{
    External(_SB.PCI0.XHC, DeviceObj)

    // In DSDT, native XWAK is renamed ZWAK
    // As a result, calls to it land here.
    Method(_SB.PCI0.XHC.XWAK)
    {
        // do nothing
    }
}
//EOF

May also need to disable XSEL (similarly)

Comment: Change Method(XSEL,0,S) to ZSEL
Find: <5853 454c 08>
Replace: <5a53 454c 08>

SSDT-XSEL.dsl

Code:

// Disabling XSEL

DefinitionBlock("", "SSDT", 2, "hack", "XSEL", 0)
{
    External(_SB.PCI0.XHC, DeviceObj)

    // In DSDT, native XSEL is renamed ZSEL
    // As a result, calls to it land here.
    Method(_SB.PCI0.XHC.XSEL)
    {
        // do nothing
    }
}
//EOF

stealthdave · Mar 16, 2016

RehabMan said:
Oops...

I thought about that, and actually made that edit yesterday, but that didn't fix the issue. I ran it again just now copy-pasting what you wrote just to be sure. Here's the updated ioreg and the resulting aml file. CLOVER is unchanged, save for the updated aml.

RehabMan · Mar 16, 2016

stealthdave said:
I thought about that, and actually made that edit yesterday, but that didn't fix the issue. I ran it again just now copy-pasting what you wrote just to be sure. Here's the updated ioreg and the resulting aml file. CLOVER is unchanged, save for the updated aml.

Read post #74 (eg. try nullifying XSEL).

Note: The code you have in SSDT-HACK-G2-lid is wrong. It conflicts with Device(LID) already in DSDT.

stealthdave · Mar 16, 2016

RehabMan said:
Read post #74 (eg. try nullifying XSEL).

Sadly, no change with nullified XSEL, either. I added the XSEL code to the SSDT-XWAK.dsl.

Note: The code you have in SSDT-HACK-G2-lid is wrong. It conflicts with Device(LID) already in DSDT.

My turn for OOPS! That was a failed attempt at trying solve my own problems, and perhaps learn a bit more about DSDT/SSDT editing. I thought I had reverted all of those changes.

Updated clover and ioreg attached.

RehabMan · Mar 16, 2016

stealthdave said:
Sadly, no change with nullified XSEL, either. I added the XSEL code to the SSDT-XWAK.dsl.

SSDT-XSEL.aml is not present in ACPI/patched. ??

You might try the same idea with ESEL (maybe you see the pattern now).

You could also try simulating "Windows 2012"... (XOSI).

My turn for OOPS! That was a failed attempt at trying solve my own problems, and perhaps learn a bit more about DSDT/SSDT editing. I thought I had reverted all of those changes.

Updated clover and ioreg attached.

Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.

In terminal,

Code:

if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi
mkdir ~/Downloads/RehabMan
cd ~/Downloads/RehabMan
patchmatic -extract

Note: It is easier if you use copy/paste instead of typing the commands manually.

Post contents of Downloads/RehabMan directory (as ZIP).

stealthdave · Mar 16, 2016

RehabMan said:
SSDT-XSEL.aml is not present in ACPI/patched. ??

You might try the same idea with ESEL (maybe you see the pattern now).

You could also try simulating "Windows 2012"... (XOSI).

I tried mapping XSEL to ESEL with the following patch to no effect:

Code:

Comment:    Change Method(XSEL, 0, S) to ESEL
Find:       <5853454c 08>
Replace:    <4553454c 08>

This patch made the machine unbootable. I also tried patching ESEL to ZSEL with the following patch (which I don't think you were suggesting, but what the hell), and it also made the machine unbootable.

Code:

Comment:    Change Method(ESEL, 0, S) to ZSEL
Find:       <4553454c 08>
Replace:    <5a53454c 08>

I also uncommented "Windows 2012" in the XOSI function of SSDT-HACK-G2.dsl. In a separate test, I tried commenting out everything except "Windows" and "Windows 2012" in XOSI. None of these resolved the disappearing webcam issue.

Code:
Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.

In terminal,

Code:

if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi mkdir ~/Downloads/RehabMan cd ~/Downloads/RehabMan patchmatic -extract

Note: It is easier if you use copy/paste instead of typing the commands manually.

Post contents of Downloads/RehabMan directory (as ZIP).

ACPI dump from patchmatic is attached. I've also attached my current CLOVER for reference.

RehabMan · Mar 16, 2016

stealthdave said:
I tried mapping XSEL to ESEL with the following patch to no effect:

Code:

Comment: Change Method(XSEL, 0, S) to ESEL Find: <5853454c 08> Replace: <4553454c 08>

This patch made the machine unbootable. I also tried patching ESEL to ZSEL with the following patch (which I don't think you were suggesting, but what the hell), and it also made the machine unbootable.

Code:

Comment: Change Method(ESEL, 0, S) to ZSEL Find: <4553454c 08> Replace: <5a53454c 08>

You can't change XSEL and ESEL both to ZSEL. One would have to become YSEL (method names in the same scope must be unique). If you changed both to ZSEL, it would likely cause a KP (DSDT would be invalid with duplicate methods names). We can get away with _WAK->ZWAK and XWAK->ZWAK as these methods reside in a separate scope.

But yes...the idea is to rename XSEL and ESEL (and XWAK) such that they do nothing... And then you'll need to provide an ESEL in an SSDT (in correct scope), so the calls to it don't cause ACPI abort...

Armed with new knowledge, give it another try...

The idea is to make sure that DSDT is not changing PR2 (controls USB2 port routing from XHCI) on wake from sleep. It is starting to seem like it is some other problem with the cam, but the only way to test is to nullify the effects of XSEL and ESEL (your DSDT calls ESEL when less than "Windows 2012", which is why also the experiments with XOSI).

You should also check in system.log for any clues regarding USB and the camera...

Finally, some devices work better when they are on EHCI, so that is also something to try. Remove the code related to disabling EHCI in SSDT-USB-8x0s-G2.aml and change the XHC _DSM to not inject RM,pr2-force (you can just remove that entire section, leaving only the port definitions). By doing that FakePCIID_XHCIMux will route USB2 devices (such as the webcam) to EHCI. You may need custom config for the EHCI port/hub at that point...

stealthdave · Mar 18, 2016

RehabMan said:
You can't change XSEL and ESEL both to ZSEL. One would have to become YSEL (method names in the same scope must be unique). If you changed both to ZSEL, it would likely cause a KP (DSDT would be invalid with duplicate methods names). We can get away with _WAK->ZWAK and XWAK->ZWAK as these methods reside in a separate scope.

But yes...the idea is to rename XSEL and ESEL (and XWAK) such that they do nothing... And then you'll need to provide an ESEL in an SSDT (in correct scope), so the calls to it don't cause ACPI abort...

Armed with new knowledge, give it another try...

Gotcha, that's much clearer. Thank you for explaining that!

The idea is to make sure that DSDT is not changing PR2 (controls USB2 port routing from XHCI) on wake from sleep. It is starting to seem like it is some other problem with the cam, but the only way to test is to nullify the effects of XSEL and ESEL (your DSDT calls ESEL when less than "Windows 2012", which is why also the experiments with XOSI).

You should also check in system.log for any clues regarding USB and the camera...

Finally, some devices work better when they are on EHCI, so that is also something to try. Remove the code related to disabling EHCI in SSDT-USB-8x0s-G2.aml and change the XHC _DSM to not inject RM,pr2-force (you can just remove that entire section, leaving only the port definitions). By doing that FakePCIID_XHCIMux will route USB2 devices (such as the webcam) to EHCI. You may need custom config for the EHCI port/hub at that point...

First, I CLOVER-patched ESEL->YESEL and XSEL->ZSEL to no effect.
I then removed the CLOVER-patch for EHC1->EH01 and EHC2->EH02 and removed the appropriate entries in SSDT-USB-8x0s-G2.aml, but the ports kept getting mapped to XHC anyway until I installed FakePCIID_XHCIMux.kext. After that, the ports remained on the EHC1 bus, but the webcam still didn't wake.

I also uncommented "Windows 2012" in XOSI; no change. I then tried commenting out all other Windows versions other than Windows 2012, also no change.

I looked through the log, and there was no mention of USB anything in the logs upon wake. I also looked through the DSDT and didn't see any methods besides XSEL and ESEL that set PR2 (although there were a lot of methods that seem to check PR2, and they weren't being called by various sleep/wake methods).

Here's my current kextcache of unsigned kexts:

Code:

$ sudo touch /System/Library/Extensions/ && sudo kextcache -u /
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext JMB38X.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext IntelMausiEthernet.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_XHCIMux.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HDMI_Audio.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HD_Graphics.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Broadcom_WiFi.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmPatchRAM2.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmFirmwareRepo.kext
kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext AppleHDA_ProBook.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIDebug.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext USBInjectAll.kext

Note that FakePCIID_XHCIMux.kext was only present when I was testing that particular kext. I've attached my current CLOVER, along with the modified config.plist that I used for testing with FakePCIID_XHCIMux.kext, and an ioreg for with and without FakePCIID_XHCIMux.

Thanks again,
- Dave

RehabMan · Mar 18, 2016

stealthdave said:
First, I CLOVER-patched ESEL->YESEL and XSEL->ZSEL to no effect.

YESEL is invalid. ACPI identifiers are limited to 4 characters.

And, of course, you would need the appropriate SSDT content.

but the ports kept getting mapped to XHC anyway until I installed FakePCIID_XHCIMux.kext.

As expected.

After that, the ports remained on the EHC1 bus, but the webcam still didn't wake.

Check BIOS settings. "Fast boot" disabled?

Search

[Guide] HP EliteBook 820 840 G2 I5-5300U HD5500 El Capitan [ENG]

stealthdave

Attachments

RehabMan

Moderator

stealthdave

Attachments

RehabMan

Moderator

stealthdave

Attachments

RehabMan

Moderator

stealthdave

Attachments

RehabMan

Moderator

stealthdave

Attachments

RehabMan

Moderator

Forum

Guides

Downloads