Contribute
Register

Lenovo Z480 SSDT Compile Error

Status
Not open for further replies.
Joined
Jun 11, 2015
Messages
22
Motherboard
Lenovo IdeaPad Z480
CPU
Intel(R) Core(TM) i7-3632QM
Graphics
Intel(R) HD Graphics 4000 + NVIDIA GeForce GT 640M
Mac
  1. 0
Classic Mac
  1. 0
Mobile Phone
  1. Android
Hi, newbie here..

I've extracted SSDTs using F4 Clover. I got some errors when compiling my SSDTs such as PARSEOP_FIELD, PARSEOP_INTEGER, etc. How to fix this?
 

Attachments

  • origin.zip
    29.3 KB · Views: 65
Hi, newbie here..

I've extracted SSDTs using F4 Clover. I got some errors when compiling my SSDTs such as PARSEOP_FIELD, PARSEOP_INTEGER, etc. How to fix this?

There seem to be a lot of misc. CPU P-State code in SSDT-1. I would just delete it and rebuild it using
ssdtPRGen.sh:
https://github.com/Piker-Alpha/ssdtPRGen.sh
http://www.tonymacx86.com/ssdt/86906-ssdt-generation-script-ivybridge-pm.html

Also, make sure you only extract your DSDT and all of your SSDT's. Trying to compile all of those together will result in a lot of errors...

EDIT:

For SSDT-6, I would also just delete it and not use it in your final patching. In my opinion, I would only use the SSDT's extracted from Clover via F4 for reference, if you're using them for CPU power management, GPU power management, etc. I would just build them myself instead of using the OEM ones.
 
Yes, I'll using them for CPU power management and disabling nVidia Optimus. I don't know which the better method for extracting SSDTs. So I used AIDA64 from Windows and Clover via F4. Each method gives a different amount of SSDT binary file.

So you suggest me to build using ssdtPRGen in mac rather than OEM one?

There seem to be a lot of misc. CPU P-State code in SSDT-1. I would just delete it and rebuild it using
ssdtPRGen.sh:
https://github.com/Piker-Alpha/ssdtPRGen.sh
http://www.tonymacx86.com/ssdt/86906-ssdt-generation-script-ivybridge-pm.html

Also, make sure you only extract your DSDT and all of your SSDT's. Trying to compile all of those together will result in a lot of errors...

EDIT:

For SSDT-6, I would also just delete it and not use it in your final patching. In my opinion, I would only use the SSDT's extracted from Clover via F4 for reference, if you're using them for CPU power management, GPU power management, etc. I would just build them myself instead of using the OEM ones.
 
Yes, I'll using them for CPU power management and disabling nVidia Optimus. I don't know which the better method for extracting SSDTs. So I used AIDA64 from Windows and Clover via F4. Each method gives a different amount of SSDT binary file.

So you suggest me to build using ssdtPRGen in mac rather than OEM one?

Yes, I would, but to do that you would need to know the P-States of your CPU. Most of the time (for Intel CPUs), it's 800MHz - the max frequency (it's on your CPU's Intel Spec Page), and turbo boost, if your CPU has that. You run it through ssdtPRGen.sh script (credit PikerAlpha) and then it spits out a SSDT for you to use.
Your Intel Spec Page (according to your signature):
http://ark.intel.com/products/71670/Intel-Core-i7-3632QM-Processor-6M-Cache-up-to-3_20-GHz-BGA

So according to that, you would have 800MHz-2.2GHz + the turbo boost, so 800MHz-3.2GHz. In my experience the ssdtPRGen script is pretty intelligent though, so it should grab all of this information without you tinkering with it. You only start modifying it if it's wrong.

Now a somewhat common problem with generating SSDT's is that after loading generated SSDT's the CPU's locked @ 800MHz. It's a very easy solution, you just have to add another 800MHz entry in your SSDT, but you should only do that if you run into the problem...


TL;DR: Yes, I would use ssdtPRGen.sh. :thumbup:
 
Di I need to parsing all arguments such as -acpi, -bclk, -board-id, etc?
here's my IOreg View attachment Zuhriyan’s MacBook Pro.zip

Yes, I would, but to do that you would need to know the P-States of your CPU. Most of the time (for Intel CPUs), it's 800MHz - the max frequency (it's on your CPU's Intel Spec Page), and turbo boost, if your CPU has that. You run it through ssdtPRGen.sh script (credit PikerAlpha) and then it spits out a SSDT for you to use.
Your Intel Spec Page (according to your signature):
http://ark.intel.com/products/71670/Intel-Core-i7-3632QM-Processor-6M-Cache-up-to-3_20-GHz-BGA

So according to that, you would have 800MHz-2.2GHz + the turbo boost, so 800MHz-3.2GHz. In my experience the ssdtPRGen script is pretty intelligent though, so it should grab all of this information without you tinkering with it. You only start modifying it if it's wrong.

Now a somewhat common problem with generating SSDT's is that after loading generated SSDT's the CPU's locked @ 800MHz. It's a very easy solution, you just have to add another 800MHz entry in your SSDT, but you should only do that if you run into the problem...


TL;DR: Yes, I would use ssdtPRGen.sh. :thumbup:
 
...
So you suggest me to build using ssdtPRGen in mac rather than OEM one?

Best result with all OEM SSDTs and ssdtPRgen.sh generated SSDT.aml
 
I still don't understand why some SSDTs of mine have 'x' after number and some not. Do I need to dissemble it with non 'x' SSDTs?

I wouldn't use the "x" SSDTs, just use the ones that only have the data you need (CPU P-States, disabling nVidia Optimus, etc.)
 
I still don't understand why some SSDTs of mine have 'x' after number and some not. Do I need to dissemble it with non 'x' SSDTs?

It is described clearly in the guide. SSDTs with 'x' are dynamic and should not be included in ACPI/patched. But you still use them for disassembly.
 
Status
Not open for further replies.
Back
Top