Contribute
Register

HP ZBOOK G5 17

Wifi works, but you need heliport or manually edit the info.plist inside the kext to add your SSID and password. Blutooth I didn't test, and my kext build are pretty old now, so you're probably right.

It does in my system, it could be related to your TB3 problem, since there's output sharing between ports.

Did you try to flash a newer TB3 firmware? TB3 and USBC work in my system without any problems.

If we can't get the complete debug logs, there's no point in keeping the card out.
As a last resort, if you have a spare HDD then you can install Catalina and try again? it may be a BigSur issue.

Thank you for helping.
Hello, after two days of hard study, I finally installed 10.15.7 on my laptop, and the 10.13.6 boot failed.

Now I use DEBUG to save dmsg-boot-display.txt, which contains debug information, you can check it out.

If you have any needs, you can tell me to save it. In UMA mode, I can only choose the 13.3 or 16.1 macbook pro model to be able to output with dual graphics cards. With macbook pro 15.1, only the notebook has its own screen display, and it cannot be displayed externally.
 

Attachments

  • IORegistry.ioreg
    10.7 MB · Views: 39
  • dmsg-boot-nodisplay.txt
    805 KB · Views: 38
  • debug.zip
    7.9 MB · Views: 63
Hello, after two days of hard study, I finally installed 10.15.7 on my laptop, and the 10.13.6 boot failed.

Now I use DEBUG to save dmsg-boot-display.txt, which contains debug information, you can check it out.

If you have any needs, you can tell me to save it. In UMA mode, I can only choose the 13.3 or 16.1 macbook pro model to be able to output with dual graphics cards. With macbook pro 15.1, only the notebook has its own screen display, and it cannot be displayed externally.
That is great, thank you, I'll look into these. I have another set of tests I will send you in a couple of hours. These will help us understand the acpi variables present and hopefully find a clean simple ssdt solution.

After some tests I've found that the DDC and AUX lines are switched to PEG0 when the MXM card is present, so we need either a driver for the i2c bridge device so that the display information will be read by AGDC and then forwarded to IGPU (this is what is basically happening with my supported DGPU), or find the ACPI switch to patch back the i2c lines to the IGPU.
 
Ok this is the first acpi debug set. To run this set you will need to add from the attached folder, SSDT-Acpi-Vars.aml to your OC/ACPI folder, then ACPIDebug.kext to your kexts folder, then add the config-adds to your working config.

Screen Shot 2021-11-04 at 4.50.18 PM.png

Finally copy the ioio executable to your desktop and open Applications->Utilities->Console and in the search box type "ACPI". (the console screen should clear up)
Then using terminal cd to your desktop and run the next command:
Code:
ioio -s org.rehabman.driver.ACPIDebug dbg0 0

Back in the console you should get a bunch of output with the values for your acpi variables. Copy and paste in a text file and upload here.

-Also reboot with external display attached and run it again, maybe there is a difference with external displays we may need.

I'll make another set for other possible ACPI suspects tonight.
 

Attachments

  • DEBUG-ACPI-ZBOOK.zip
    21.1 KB · Views: 51
Same idea as before, here are 2 more SSDT's to load and do the same ioio command to print acpi variables to console.

You have to copy both SSDT's to EFI/OC/ACPI and (very important) replace SSDT-Acpi-Vars.aml with SSDT-Acpi-Vars2.aml in OC config. Then run the ioio command as before with and without a monitor plugged in at boot. Then again replace SSDT-Acpi-Vars2.aml with SSDT-Acpi-Vars3.aml in your OC config.
You must only load one of these at a time with your OC config.

Hopefully these variables will be enough to give us 2 things. The variable/address/method of the missing switch, and a power control variable/method to get full TDP in fake UMA mode.
 

Attachments

  • SSDT-Acpi-Vars2.aml
    7.5 KB · Views: 37
  • SSDT-Acpi-Vars3.aml
    5.5 KB · Views: 40
Ok this is the first acpi debug set. To run this set you will need to add from the attached folder, SSDT-Acpi-Vars.aml to your OC/ACPI folder, then ACPIDebug.kext to your kexts folder, then add the config-adds to your working config.

View attachment 533266
Finally copy the ioio executable to your desktop and open Applications->Utilities->Console and in the search box type "ACPI". (the console screen should clear up)
Then using terminal cd to your desktop and run the next command:
Code:
ioio -s org.rehabman.driver.ACPIDebug dbg0 0

Back in the console you should get a bunch of output with the values for your acpi variables. Copy and paste in a text file and upload here.

-Also reboot with external display attached and run it again, maybe there is a difference with external displays we may need.

I'll make another set for other possible ACPI suspects tonight.
You don't need ACPIDebug, there are boot arguments you can use to have AppleACPIPlatform log debug statements. You need the following boot-args: "acpi_layer=0x08", "acpi_level=0x02". You will also want to add DebugEnhancer.kext to make the `dmesg` buffer larger (or use "msgbuf=1048576 but that prevents Monterey from booting and makes a smaller buffer than DebugEnhancer.kext).

Once you've rebooted with the above boot-args and DebugEnhancer.kext, you can use "sudo dmesg > ~/Desktop/acpi_log.txt" to pipe the output of "sudo dmesg" to a file to search through. All log statements begin with "[ACPI Debug]", though lines can end up split, so I would suggest not using grep and instead using search once the output is in a file.

The "Log" command does sort of work. It will miss a large portion of the boot process though. This would be the same even with AcpiDebug. I just default to using dmesg now.

To print out statements from your ACPI, just set "debug" equal to whatever string you want to print. For example, you can do...
Code:
External (\OSYS, IntObj)

Method (_INI, 0, NotSerialized)
{
    Debug = "Entering \_INI!" // Prints "Entering \INI!"
    Debug = "Hello World!" // Prints "Hello World!"
    Debug = Concatenate ("OSYS is equal to: ", \OSYS) // Prints "OSYS is equal to: 0x7DC"
}

Edit: Oops!
I didn't see you were actually having AcpiDebug run debug ACPI methods.
I'll leave this here for future reference. Can't replicate what your doing here without AcpiDebug!
 
Last edited:
You don't need ACPIDebug, there are boot arguments you can use to have AppleACPIPlatform log debug statements. You need the following boot-args: "acpi_layer=0x08", "acpi_level=0x02". You will also want to add DebugEnhancer.kext to make the `dmesg` buffer larger (or use "msgbuf=1048576 but that prevents Monterey from booting and makes a smaller buffer than DebugEnhancer.kext).

Once you've rebooted with the above boot-args and DebugEnhancer.kext, you can use "sudo dmesg > ~/Desktop/acpi_log.txt" to pipe the output of "sudo dmesg" to a file to search through. All log statements begin with "[ACPI Debug]", though lines can end up split, so I would suggest not using grep and instead using search once the output is in a file.

The "Log" command does sort of work. It will miss a large portion of the boot process though. This would be the same even with AcpiDebug. I just default to using dmesg now.

To print out statements from your ACPI, just set "debug" equal to whatever string you want to print. For example, you can do...
Code:
External (\OSYS, IntObj)

Method (_INI, 0, NotSerialized)
{
    Debug = "Entering \_INI!" // Prints "Entering \INI!"
    Debug = "Hello World!" // Prints "Hello World!"
    Debug = Concatenate ("OSYS is equal to: ", \OSYS) // Prints "OSYS is equal to: 0x7DC"
}

Edit: Oops!
I didn't see you were actually having AcpiDebug run debug ACPI methods.
I'll leave this here for future reference. Can't replicate what your doing here without AcpiDebug!
Thanks, it's good information, and yes I needed to run ACPI methods after the fact, so I used the ioio+AcpiDebug combo. Only had to split it up into several ssdt's because it runs out of memory if it tries to fetch too many variables in one go.
 
Same idea as before, here are 2 more SSDT's to load and do the same ioio command to print acpi variables to console.

You have to copy both SSDT's to EFI/OC/ACPI and (very important) replace SSDT-Acpi-Vars.aml with
You must only load one of these at a time with your OC config.

Hopefully these variables will be enough to give us 2 things. The variable/address/method of the missing switch, and a power control variable/method to get full TDP in fake UMA mode.
Hello, can you directly share these configurations as EFI files? I just need to boot for testing. If I add all these files, other unknown bugs are prone to appear. I have discovered this problem during the testing process these days. Waste a lot of time.
 
Hello, why doesn’t mine show up? Where is it that it’s not set up or it’s not working?



ioio.png


ioio-2.png
ioio-3.png
ioio-4.png
 
Last edited:
Hello, why doesn’t mine show up? Where is it that it’s not set up or it’s not working?
Did you copy the SSDT's to EFI/OC/ACPI ?
Screen Shot 2021-11-05 at 10.36.38 AM.png
 
Last edited:
y
Did you copy the SSDT's to EFI/OC/ACPI ?
View attachment 533320Yes, I have copied the files in, and I have shared the EFI OC configuration I used. You can see if what I did is correct, and if there are errors, you can correct them.
Yes, I have copied the files in, and I have shared the EFI OC configuration I used. You can see if what I did is correct, and if there are errors, you can correct them..

WX20211106-005911@2x.png
 

Attachments

  • OC-DEBUG.zip
    35.8 MB · Views: 52
Last edited:
Back
Top