[Guide] Lenovo ThinkPad T440P

[the-braveknight]

Still show this... lose my mind...

Post your EFI/Clover folder.

 

[MidGQ]

Post your EFI/Clover folder.

Here it is

 

[the-braveknight]

Here it is

You should use ACPIDebug to see if the GPOF is actually being called and/or the checks inside it are succeeding.

I added ACPIDebug codes to your DSDT, simply put in Clover/ACPI/patched. Make sure you install latest ACPIDebug.kext.

Boot with ACPIDebug.kext installed, Nvidia spoof injections in config.plist (in case it fails to disable), and this DSDT Clover/ACPI/patched. I added a GPOF call in PEG.VID._INI and some debugging code. You can remove SSDT-DGPU.aml for now.

After you've booted, you should open Terminal and enter this command:

log show --predicate "processID == 0" --debug --start  `date "+%Y-%m-%d"` > ~/Desktop/kernel.log

Then post problem reporting files and the generated log at ~/Desktop/kernel.log.

 

[MidGQ]

You should use ACPIDebug to see if the GPOF is actually being called and/or the checks inside it are succeeding.

I added ACPIDebug codes to your DSDT, simply put in Clover/ACPI/patched. Make sure you install latest ACPIDebug.kext.

Boot with ACPIDebug.kext installed, Nvidia spoof injections in config.plist (in case it fails to disable), and this DSDT Clover/ACPI/patched. I added a GPOF call in PEG.VID._INI and some debugging code. You can remove SSDT-DGPU.aml for now.

After you've booted, you should open Terminal and enter this command:

log show --predicate "processID == 0" --debug --start  `date "+%Y-%m-%d"` > ~/Desktop/kernel.log

Then post problem reporting files and the generated log at ~/Desktop/kernel.log.

ACPIDebug installed. Boot with DSDT.aml ------>

 

[RehabMan]

ACPIDebug installed. Boot with DSDT.aml ------>

I suspect the SystemMemory addresses (in native DSDT vs. ACPI/patched/DSDT.aml) do not match.

In fact, the SystemMemory addresses in the DSDT.aml attached to post #323 do not match those in #324.
This is a filtered diff:

u430:origin Admin$ diff DSDT.dsl ~/Downloads/DSDT.dsl|grep SystemMemory
<     OperationRegion (MNVS, SystemMemory, 0xB6E7D018, 0x1000)
>     OperationRegion (MNVS, SystemMemory, 0xBCE7D018, 0x1000)
<     OperationRegion (GNVS, SystemMemory, 0xB6D7BC18, 0x02B0)
>     OperationRegion (GNVS, SystemMemory, 0xBCD7BC18, 0x02B0)
<                     OperationRegion (ATRP, SystemMemory, \ATRB, 0x00100000)
>                     OperationRegion (ATRP, SystemMemory, ATRB, 0x00100000)

 

[the-braveknight]

ACPIDebug installed. Boot with DSDT.aml ------>

I added ACPIDebug codes to this SSDT-DGPU.aml instead. Remove DSDT.aml and copy this SSDT-DGPU.aml to Clover/ACPI/patched.

Then upload the results.

 

[MidGQ]

I added ACPIDebug codes to this SSDT-DGPU.aml instead. Remove DSDT.aml and copy this SSDT-DGPU.aml to Clover/ACPI/patched.

Then upload the results.

Result is uploaded

BTW，I just unlock the advanced menu in BIOS. But I can't find a way to disable the integrated graphics card.

 

[Sniki]

Result is uploaded

BTW，I just unlock the advanced menu in BIOS. But I can't find a way to disable the integrated graphics card. View attachment 304694

If you also unlocked advanced menu on bios you can definetly disable it on bios, I don’t know where it is exactly located but i can tell you after i go back home (when i finnish work) the exact place where you can disable it.

It should be into IGD i guess and you have optimus, you just set it to UMA only something like this

 

[the-braveknight]

Result is uploaded

BTW，I just unlock the advanced menu in BIOS. But I can't find a way to disable the integrated graphics card. View attachment 304694

It was never about disabling the integrated graphics. What we're trying to accomplish here is disabling the Nvidia card that cannot be made to work in macOS to save battery life. DO NOT risk trying to disable the integrated graphics because it will brick your laptop and the screen won't turn on.

So, by looking at your kernel log, I can see that the 'If (VMSH || \_SB.PCI0.PEG.VID.OMPR == 0x03)' check is not succeeding. VMSH is Zero and OMPR is 0x02. No wonder why the code in GPOF is not being executed.

OMPR is being set to OPCE in _SB.PCI0.PEG.VID.NVOP, which I suspect to be 0x02. It is also being set to 0x02 at the end of GPOF method (which is not being executed).

Another thing is that VMSH is being set to 0x00 (Zero) in _SB.PCI0.IGPU.VRSI (and VRSI is being called from _SB.PCI0.PEG.VID._INI) because you're simulating 'Windows 2012' which is Windows 8. In VRSI, it will be set to 0x01 (non-Zero) if OSYS is greater than or equal to '0x07DD', which is 'Windows 2013' or Windows 8.1.

To sum this up, you should try simulating 'Windows 2013' instead of 'Windows 2012' in SSDT-XOSI.aml and the GPOF code will be executed just fine.

Maybe @RehabMan can add further notes?

Here are the new SSDT-XOSI.aml and SSDT-DGPU.aml (I added code to check OSYS value just to make sure XOSI is simulating the right version). Test and report back with full problem reporting files and a new kernel.log.

 

[RehabMan]

It was never about disabling the integrated graphics. What we're trying to accomplish here is disabling the Nvidia card that cannot be made to work in macOS to save battery life. DO NOT risk trying to disable the integrated graphics because it will brick your laptop and the screen won't turn on.

So, by looking at your kernel log, I can see that the 'If (VMSH || \_SB.PCI0.PEG.VID.OMPR == 0x03)' check is not succeeding. VMSH is Zero and OMPR is 0x02. No wonder why the code in GPOF is not being executed.

OMPR is being set to OPCE in _SB.PCI0.PEG.VID.NVOP, which I suspect to be 0x02. It is also being set to 0x02 at the end of GPOF method (which is not being executed).

Another thing is that VMSH is being set to 0x00 (Zero) in _SB.PCI0.IGPU.VRSI (and VRSI is being called from _SB.PCI0.PEG.VID._INI) because you're simulating 'Windows 2012' which is Windows 8. In VRSI, it will be set to 0x01 (non-Zero) if OSYS is greater than or equal to '0x07DD', which is 'Windows 2013' or Windows 8.1.

To sum this up, you should try simulating 'Windows 2013' instead of 'Windows 2012' in SSDT-XOSI.aml and the GPOF code will be executed just fine.

Maybe @RehabMan can add further notes?

Here are the new SSDT-XOSI.aml and SSDT-DGPU.aml (I added code to check OSYS value just to make sure XOSI is simulating the right version). Test and report back with full problem reporting files and a new kernel.log.

Makes sense to me.