DSDT - Vanilla Speedstep - Generic Scope (_PR)

[keeza]

Bleh looks like it did the same attachment thing to me as that other dude above me... let's try this again

 

Forgot to ask, need your original dump also so I can see what you've added.

[TheOriginalPol]

Hmmm well I can give you the last successful compile I did that didn't have any errors, will that do? This one includes the AppleLPC patch (which went through fine) but not the _PR additions (which is what gave me the problems).

 

I'll also include the .aml I had before I even started with this thread (sorry all I have is the .aml)

 

Thanks in advance!

dsdtGOOD.dsl.zip

DSDT_old.aml.zip

[TheOriginalPol]

Here's my original untouched dump, if that's what you wanted. Though I've done many other modifications on it before this thread.

dsdt_Original.dsl.zip

[keeza]

Hmmm well I can give you the last successful compile I did that didn't have any errors, will that do? This one includes the AppleLPC patch (which went through fine) but not the _PR additions (which is what gave me the problems).

 

I'll also include the .aml I had before I even started with this thread (sorry all I have is the .aml)

 

Thanks in advance!

 

Your last working dsdt contains 117 errors! (using IASLMe vs 1.0). Using DSDTE it compiles without any errors but 3 warnings.

As your dsdt is over 8000 lines long I suggest you start over with a fresh dump using either a Linux LiveCD or Lavalys Everest (windows program, you can download a trial and get what you need.)

 

If its any consolation the same thing happened to me (compilation errors in IASL but ok in DSDTE) when I first started out on the long windy road of dsdt editing......

 

I started over, added sections, recompiled to make sure it compiled ok before adding a next section. That way you can eliminate any errors before they blow out. But you need to start with a fresh dsdt which compiles without any errors.

[TheOriginalPol]

Bleeeehhhh. It really is a long and winding road. I didn't realize that it compiled differently in different programs, that's interesting. I use DSDTSE, which I guess is why I thought it was a stable version. I also started editing on an already-auto-patched dsl, done with Patcher GUI. That might have contributed to the problem.

 

I guess I'll just suck it up and get a fresh start. Do you have any useful links that really explain the language and workings of this? I mean sure I can follow a tutorial fine and I know a tad bit of hex, but all in all I'm really doing most of this blindly. (and no, don't send me to the ACPI table website!)

 

Also, is there a difference between extracting it in Linux or Windows and just using DSDTSE?

[keeza]

Bleeeehhhh. It really is a long and winding road. I didn't realize that it compiled differently in different programs, that's interesting. I use DSDTSE, which I guess is why I thought it was a stable version. I also started editing on an already-auto-patched dsl, done with Patcher GUI. That might have contributed to the problem.

 

I guess I'll just suck it up and get a fresh start. Do you have any useful links that really explain the language and workings of this? I mean sure I can follow a tutorial fine and I know a tad bit of hex, but all in all I'm really doing most of this blindly. (and no, don't send me to the ACPI table website!)

 

Also, is there a difference between extracting it in Linux or Windows and just using DSDTSE?

 

Copy and paste this script into Terminal, this will generate the files you need through MacOSX.

#!/bin/bash

set -e

set -u

 

ioreg=

if [[ $# -eq 1 && -f "$1" ]]; then

ioreg="$(grep ' "ACPI Tables" =' "$1")"

else

ioreg="$(ioreg -lw0 | grep ' "ACPI Tables" =')"

fi

 

ioreg=${ioreg#*\{}

ioreg=${ioreg%\}*}

 

declare -a tables

ioreg="${ioreg//,/ }"

 

tables=($ioreg)

 

echo "Number of ACPI tables: ${#tables[@]}"

re='"([^"]+)"=<([^>]+)>'

dumped=0

for t in "${tables[@]}"; do

#echo Table: $t

if [[ $t =~ $re ]]; then

[[ $dumped = 0 ]] && mkdir -p ACPI

((++dumped))

echo

echo "Dumping table: ${BASH_REMATCH[1]}"

echo "Content: ${BASH_REMATCH[2]}"

echo "${BASH_REMATCH[2]}" | xxd -r -p > "ACPI/${BASH_REMATCH[1]}".aml

echo "AML code dumped to \"ACPI/${BASH_REMATCH[1]}.aml\""

type -p iasl &>/dev/null && iasl -d "ACPI/${BASH_REMATCH[1]}".aml \

&& echo "DSL code decompiled to \"ACPI/${BASH_REMATCH[1]}.dsl\""

echo

fi

done

if [[ $dumped -gt 0 ]]; then

zip -r ACPI.zip ACPI && echo "Zipped your ACPI tables in file \"ACPI.zip\""

fi

 

You will then need to add your graphics, ethernet, CMOS reset fix (important) TMR, HPET, WAK, RTC and USB fixes. You will need the AppleLPC device ID fix if you are using vanilla power management.

 

That should get you started.

[TheOriginalPol]

Nice! That's a neat trick. Thanks a lot for your help.

 

*puts down the gameboy and undoes belt* it's editing time...

[keeza]

Nice! That's a neat trick. Thanks a lot for your help.

I can't take credit for it, I pinched it from somewhere,,,

 

*puts down the gameboy and undoes belt* it's editing time...

Thats more like it...

[TheOriginalPol]

Not quite.

 

I started with a FRESH dump (removed DSDT.aml from root of drive, rebooted, and used your code). I fixed two or three compile errors. I applied the DTGP fix. Applied the USB device-id fix. Applied the AppleLPC fix. So far so good, no errors that I couldn't handle, both in DSDTSE and iaslme.

 

Then I tried the steps on this thread again, and lo and behold, a perfect 52 errors. Just like last time. What's the deal here??

 

Attached is my fresh .dsl (after two or three error fixes), modified .dsl (up to this method), and a screenshot of PStateChanger.

Any other ideas what I'm doing wrong here?

 

 

P.S. Sadly, I never actually play my gameboy anymore :-(

DSDT_Original_fixed.dsl.zip

DSDT__DTGP_USB_AppleLPC__PR_.dsl.zip

[keeza]

Not quite.

 

I started with a FRESH dump (removed DSDT.aml from root of drive, rebooted, and used your code). I fixed two or three compile errors. I applied the DTGP fix. Applied the USB device-id fix. Applied the AppleLPC fix. So far so good, no errors that I couldn't handle, both in DSDTSE and iaslme.

 

Then I tried the steps on this thread again, and lo and behold, a perfect 52 errors. Just like last time. What's the deal here??

 

Attached is my fresh .dsl (after two or three error fixes), modified .dsl (up to this method), and a screenshot of PStateChanger.

Any other ideas what I'm doing wrong here?

 

 

P.S. Sadly, I never actually play my gameboy anymore :-(

 

This attached file compiles with dsdtse and the latest IASLme with 0 errors. If I use an older version of IASLme (vs1.0) I get 55 errors.

I've no explanation for you as to why the different results.

 

Any thoughts Mitch_De?

dsdt_edited.zip

[gmacman]

I'm afraid after having read and reread this thread I'm still a bit confused.

 

I've looked at other dsdt files from people who have similar mobo and the exact same cpu as I have (Q6600) and I find very different info (and yes I understand that some is dependent on the speed they are running and thus the FID and VID).

 

But I find other differences that are not mentioned in the instructions. For example these two PSS sections below are both from people who have Q6600's. Obviously the FID/VID combo entry is different but why are the other entries within each Package (0x06) different? And so, which one do I use? Or more correctly, how do I find the right one to use?

 

The fact one is cosmetically using Name and the other Method does not concern me. What I'm trying to determine is within the Package (0x06) areas.

 

Here's one:

            Method (_PSS, 0, NotSerialized)
           {
               Return (Package (0x04)
               {
                   Package (0x06)
                   {
                       0x0D5C, 
                       0xFDE7, 
                       0x0A, 
                       0x0A, 
                       0x0926, 
                       Zero
                   }, 

                   Package (0x06)
                   {
                       0x0BE0, 
                       0xFDE8, 
                       0x0A, 
                       0x0A, 
                       0x0822, 
                       One
                   }, 

                   Package (0x06)
                   {
                       0x0A64, 
                       0xFDE7, 
                       0x0A, 
                       0x0A, 
                       0x071D, 
                       0x02
                   }, 

                   Package (0x06)
                   {
                       0x0A64, 
                       0xFDE7, 
                       0x0A, 
                       0x0A, 
                       0x071D, 
                       0x03
                   }
               })
           }

 

And here's the other Q6600:

            Name (_PSS, Package (0x04)
            {
                Package (0x06) { 2403, 0, 10, 10, 0x0928, 0 },
                Package (0x06) { 2136, 0, 10, 10, 0x0824, 1 },
                Package (0x06) { 1869, 0, 10, 10, 0x0720, 2 },
                Package (0x06) { 1602, 0, 10, 10, 0x061B, 3 }
            })

[sw170]

I'm afraid after having read and reread this thread I'm still a bit confused.

.....

gmacman, download P-states calculator and you'll understand how these values are changing

[gmacman]

gmacman, download P-states calculator and you'll understand how these values are changing

 

Thanks swavek.

 

Okay, added VoodooPState.kext to /E/E, reboot and then launched P-states calculator. At first it showed the following:

 

 

 

Then I changed the Bus Speed to 300 which I know is what I'm running and see this:

 

 

 

So I get they are changing and I'm assuming I am suppose to use the one I "made" by changing the Bus Speed to the correct number I've got in my BIOS.

 

I did try to hit the Voodoo P-States button but nothing happened, no changes either with the default data or with my 300 I put in. I'm guessing I'm doing something wrong there (I see that the kext did load so that can't be the issue).

orig_shot.tiff

mycpu_numbers.tiff

[valv]

I did try to hit the Voodoo P-States button but nothing happened, no changes either with the default data or with my 300 I put in. I'm guessing I'm doing something wrong there (I see that the kext did load so that can't be the issue).

Just go changing core multiplier values, and each time write down the other details (the line under _pss field for dsdt) u'll be needing all these later

[gmacman]

Just go changing core multiplier values, and each time right down the other details (the line under _pss field for dsdt) u'll be needing all these later

 

Okay, I think I'm getting this now.

 

With each multiplier matching the number of p states I see within the P state changer. For example in the P State Changer I see 2700, 2400, 2100 and 1800 so with my 300 FSB I should select my current 9, then 8, 7, and 6.

 

But why didn't the Voodoo P-States button do anything? Or should I not really care since at least the fog is beginning to lift.

[valv]

yep,

But why didn't the Voodoo P-States button do anything? Or should I not really care since at least the fog is beginning to lift.

same thing happened to me, but I've seen it one time fully working and popping up with a window containing all lines, don't know hoe though. the most importand is it works.

btw, make sure that u don't have oem values stating at one SSDTable or the other

[dh.taran]

Hi everyone..Im using a fellow members modified DSDT (supposedly patched), however my idle temps are still in the 50's Celsius range. He was using a Q6600 @2.4, while im using a E6320 1.8Ghz OC'd to 3.01Ghz.

 

Do I need to recalculate the pstates and work on it...very n00bish regarding scripts, more of a routing switching guy. ANy help will be appreciated. Im attaching my original, unpatched linux live CD dsdt and the modified patched one im using. Please spare a few minutes and guide.

 

Original DSDT:

 

http://www.mediafire.com/?4n5znkdgzaj

 

 

Current Boot modified DSDT

 

http://www.mediafire.com/?imznnymzgr4

[dh.taran]

@ Freakyy;)

as per our IM convo

 

Niiice, hopefully I can be fast enough for you to help me out before you get weekend busy

 

Bro, you didnt tell me which tab you needed the snapshot off voodoomonitor so im sending you all of them:

 

 

Added you on gmail aswell. Umm ..kinda confused about what all info you need about my system besides this:

 

Gigabyte P35 DS3R v1.o

E6320 @ 3.01 Ghz

2 GB Ram @ 860

I can send you the IOreg dump as well if thats gonna help?

 

 

EDIT: Also I came up with this speedstep code, kindly correct me if Im wrong

 

 

   Scope (_PR.CPU0)
{
	Method (_PSS, 0, NotSerialized)
	{
		Return (Package (0x02)
		{
			Package (0x06)
			{
				Zero, 
				Zero, 
				0x10, 
				0x10, 
				0x072A, 
				Zero
			}, 

			Package (0x06)
			{
				Zero, 
				Zero, 
				0x10, 
				0x10, 
				0x0624, 
				One
			}, 
		})
	}

	Method (_PSD, 0, NotSerialized)
	{
		Return (Package (0x05)
		{
			0x05, 
			Zero, 
			Zero, 
			0xFC, 
			0x04
		})
	}

	Method (_CST, 0, NotSerialized)
	{
		Return (Package (0x02)
		{
			One, 
			Package (0x04)
			{
				ResourceTemplate ()
				{
					Register (FFixedHW, 
						0x01,			   // Bit Width
						0x02,			   // Bit Offset
						0x0000000000000000, // Address
						0x01,			   // Access Size
						)
				}, 

				One, 
				0x9D, 
				0x03E8
			}
		})
	}
}

Scope (_PR.CPU1)
{
	Method (_PSS, 0, NotSerialized)
	{
		Return (^^CPU0._PSS ())
	}

	Method (_PSD, 0, NotSerialized)
	{
		Return (^^CPU0._PSD ())
	}

	Method (_CST, 0, NotSerialized)
	{
		Return (Package (0x04)
		{
			0x03, 
			Package (0x04)
			{
				ResourceTemplate ()
				{
					Register (FFixedHW, 
						0x01,			   // Bit Width
						0x02,			   // Bit Offset
						0x0000000000000000, // Address
						,)
				}, 

				One, 
				Zero, 
				0x03E8
			}, 

			Package (0x04)
			{
				ResourceTemplate ()
				{
					Register (FFixedHW, 
						0x08,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000414, // Address
						,)
				}, 

				0x02, 
				One, 
				0x01F4
			}, 

			Package (0x04)
			{
				ResourceTemplate ()
				{
					Register (FFixedHW, 
						0x08,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000415, // Address
						,)
				}, 

				0x03, 
				0x55, 
				0xFA
			}
		})
	}
}

 

 

EDIT 2: 2 compile errors (

 

 

 

 

Heres the speedstep code DSDT:

 

dsdt.zip

 

 

Freakyyy or anyone. Please help me out here.

[Freaky Chokra]

@ Freakyy;)

Niiice, hopefully I can be fast enough for you to help me out before you get weekend busy

 

Bro, you didnt tell me which tab you needed the snapshot off voodoomonitor so im sending you all of them:

 

Freakyyy or anyone. Please help me out here.

 

Yo dh.taran. Chill.

Finally, my weekend is here. I'll be going through your DSDT in detail soon. Just as I wrap up my show. ok

Till then, we work on current modified DSDT only. As many others have already finely tuned and tweaked it to perfection.

That way we can just pace up to the end results. ok?

Till then relax and enjoy your SnowLeo, while your working or entertaining with movies or series on it ok?

 

Regards,

Freaky Chokra.

[gmacman]

Okay, so with much appreciated help from swavek and valv I believe I have a correct _PSS section for my Q6600. For the _PSD section I am merely taking the one from the instructions on the first page as I see nearly all other dsdt files have the same thing.

 

My main concern now is the correct way to have the _CST. I only run OS X on the Hackintoshes (and of course my real Macs) so I don't have access to Linux or Windows to see the SSDT (not to mention I'm not 100% sure what I need to be looking at). I did get the MacPro 3,1 SSDT that are available but within the folder are SSDT and then SSDT-1 thru SSDT-18.

 

Should I be using the _CST section from the generic ssdt? Or is there a better way to get the info required?

 

 

 Scope (_PR)
    {
        Processor (CPU0, 0x00, 0x00000410, 0x06) {
            Name (_PSS, Package (0x04)
            {
                Package (0x06) { 2700, 56694, 10, 10, 0x91E, 0 },
                Package (0x06) { 2400, 48100, 10, 10, 0x81B, 1 },
                Package (0x06) { 2100, 40080, 10, 10, 0x717, 2 },
                Package (0x06) { 1800, 32633, 10, 10, 0x614, 3 }
            })

            Name (_PSD, Package (0x05)
            {
                0x05,
                0x00,
                0x00,
                0xFC, 
                0x04  
            })
// remainder of the scope (_CST) needs to be completed

 

 

EDIT:

 

The one I think I can use is as follows:

 

	Name (_CST, Package (0x02) {One,Package (0x04)
{ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8},})

[Beerkex'd]

Without an SSDT dump with the C-states in it there is no way to tell for sure. If you know your CPU's S-SPEC number you can check the Intel processor finder pages to see how many C-states it supports. You will still need the dump to get the values right.

If it only does C1E, then you can use the generic code from the first post though.

 

Download for example a Linux Mint live CD and dump the SSDT tables from there (see instructions somewhere in this thread). Save them to a pen drive and decompile them in OS X.

 

Make sure you have C-states enabled in the BIOS under CPU settings. With C-states disabled I get 3 SSDT tables, with them enabled I get five.

[gmacman]

Without an SSDT dump with the C-states in it there is no way to tell for sure. If you know your CPU's S-SPEC number you can check the Intel processor finder pages to see how many C-states it supports. You will still need the dump to get the values right.

If it only does C1E, then you can use the generic code from the first post though.

 

Download for example a Linux Mint live CD and dump the SSDT tables from there (see instructions somewhere in this thread). Save them to a pen drive and decompile them in OS X.

 

Make sure you have C-states enabled in the BIOS under CPU settings. With C-states disabled I get 3 SSDT tables, with them enabled I get five.

 

I was afraid I was going to get that answer.

 

I do realize I need to invest a bit more time on this to get it right. As stated, I only run OS X so I'll have to do some additional work to load another OS. Can I get this info by running it (the OS I mean) through Parallels? That way I don't have to add a new HD and partition it, load the OS, etc.

[Beerkex'd]

lol, no, there is no "10 seconds" easy way, Parallels uses its own 'emulated' BIOS. You can clearly see it (and even access it by tapping del) when you boot your virtual machine.

 

A Linux Mint live CD is just a little under 700MB, download it, burn it, boot from it (you won't have to install anything on your PC, just boot from the CD. It's a fully functional OS running off of a CD and a RAM disk), open a terminal window and type some commands to dump the tables, save them to a flash drive or email them to yourself. Done.

 

It will take a while to download the CD but otherwise it's totally a walk in the park, all you need is to find the commands, I've seen them in several posts here and on the ProjectOSX forums.

[sw170]

...

Can I get this info by running it (the OS I mean) through Parallels? That way I don't have to add a new HD and partition it, load the OS, etc.

Hi 'gmacman',

LiveCD means that you can boot system from CD, no HD modification (partitioning,formatting etc..) needed, just memory stick to store your dumped SSDT tables and thats it.

 

Great source of information about c-states starts somewhere around here go through pages 30,31,33 there is quite a lot of information about your processor too - Q6600?

good luck

s

 

Edit: oops sorry 'Beerkex'd' didn't noticed your reply.

[gmacman]

Got it. Thank you both. I had to laugh at my own stupidity a bit. I'm so old in college I had a Mac Plus as my first computer. It's easy to forget that an OS does not necessarily require GBs of space.

 

On a side note, I'm just really happy that my Hack is getting so clean (or pure if you will) between the speedstepping and the plethora of dsdt fixes I've done so far. A good deal of work, but well worth it.