Jump to content

DSDT editor and patcher

oldnapalm

By oldnapalm,
in Guides

 Share
999 posts in this topic

Recommended Posts

kizwan
kizwan
Posted
Posted
@MaLd0n,

 

Yes I remember leaving them in, but if I am going to use Chameleon features I should remove those IRQ's.

 

MY TMR is labelled TIMR and my PIC is labelled IPIC.

In the modified DSDT I gave to you earlier already removed IRQ from RTC device & put two IRQs in HPET device. I didn't remove IRQ from TMR (or TIMR) & PIC (or IPIC) devices.

Link to comment
Share on other sites
oSxFr33k
oSxFr33k
Posted
Posted

@MaLd0n and @kizwan,

 

Removing them from TIMR and IPIC did have an effect. I was seeing some Mouse Pointer Artifacts which are now gone and some intermittent kernel panic which after several boots has disappeared.

Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted
In the modified DSDT I gave to you earlier already removed IRQ from RTC device & put two IRQs in HPET device. I didn't remove IRQ from TMR (or TIMR) & PIC (or IPIC) devices.

 

No problems

can apply the patch without problems :)

 

smokev.gif

Link to comment
Share on other sites
toology
toology
Posted
Posted

Can some of you DSDT experts help me to patch ASUS P5B?

I'm not currently using a custom DSDT but I'd like to try it out because of the instant wake problem when trying to put my Hackintosh in sleep mode. From reading this forum, it seems that usb devices are a problem. I found a modified kext but that completly disabeld usb input.

 

BTW could DSDT fix the problem of not working front usb ports?

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
  • Author
Posted

@oSxFr33k: please see my post #270

 

@Morto_jeffrey: which Java version do you have? DSDT Editor needs version > 1.6

 

@toology: please attach your DSDT and a kernel log after you try to use sleep. If it wakes instantly you may fix it removing _PRW from devices that appear in log as "wake reason".

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
@oSxFr33k: please see my post #270

He doesn't have problem with _CST, at least no error messages regarding _CST in his log files. The only reason he want to try the _CST patch in DSDT because he want to see if it can make i7 work efficiently in Mac OS X. I think this answered your question:-

What happens if you boot without any _CST or _PSS patches, no RC5 state generators and no disabler for AppleIntelCPUPowerManagement?

He doesn't use any disabler kext. I know this because I help him cleanup his DSDT. He have problem when waking up from sleep. If USB disk is plugged in, there is an error message telling it did not properly ejected. Already applied EHCI sleep fix but it didn't solve the problem.

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
  • Author
Posted
He doesn't have problem with _CST, at least no error messages regarding _CST in his log files. The only reason he want to try the _CST patch in DSDT because he want to see if it can make i7 work efficiently in Mac OS X. I think this answered your question:-

Ok, thanks. I just wanted to know if his original SSDT has _CST. If so, I believe no DSDT patches are needed for SpeedStep, since his original LPC device ID is compatible. Are temps in 50-67 range high for his CPU? Shouldn't that patch be used with EvoSpeedstep.kext?

 

He doesn't use any disabler kext. I know this because I help him cleanup his DSDT. He have problem when waking up from sleep. If USB disk is plugged in, there is an error message telling it did not properly ejected. Already applied EHCI sleep fix but it didn't solve the problem.

Did he try the patches from this topic?

http://www.insanelymac.com/forum/index.php...t&p=1124268

				Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x07)
					{
						"AAPL,current-available",
						0x05DC,
						"AAPL,current-extra",
						0x03E8,
						"AAPL,current-in-sleep",
						0x0BB8,
						Buffer (0x01)
						{
							0x00
						}
					}, Local0)
				DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				Return (Local0)
			}

http://www.insanelymac.com/forum/index.php...t&p=1240686

						Method (_DSM, 4, NotSerialized)
					{
					   Store (Package (0x04)
						   {
							 "AAPL,clock-id",
							 Buffer (0x01)
							 {
								 0x01
							 },
							 "device_type",
							 Buffer (0x05)
							 {
								"EHCI"
							 }
							}, Local0)
						DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
						Return (Local0)
					}

Link to comment
Share on other sites
oSxFr33k
oSxFr33k
Posted
Posted

@oldnapalm,

 

So its clear now on the _CST thing? All I tried to do is keep temps more in the range of 50-55 instead they tend to go beyond 55 and as high as 67. I thought the EVO hack or Chameleon's C and P state Generator would lower the temps more or at least keep them lower than 55.

 

I could only pull those SSDT tables using Everest. Ubuntu would not supply them using the script around here somewhere, or at least I did not see them in /proc. Only DSDT was there.

 

From your post above, they look like variations of the EHCI hacks I have now. Those hacks are for EHCx not USB correct? I'll give them a try later and report back.

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
Ok, thanks. I just wanted to know if his original SSDT has _CST. If so, I believe no DSDT patches are needed for SpeedStep, since his original LPC device ID is compatible. Are temps in 50-67 range high for his CPU? Shouldn't that patch be used with EvoSpeedstep.kext?

I didn't look his SSDT but my conclusion same as yours (no need to apply _CST patch in his DSDT). He got (easily) ~67 celcius on normal load, so it does look a bit high. However he managed to lower down the CPU temp range after changing the model identifier from MacBookPro6,1 to iMac11,1. Yes, the _CST patch need to be use with EvoSpeedstep.kext. I don't know whether he did installed it or not. Just like you said, I don't think he need to apply _CST patch. It just because of the high CPU temp he got earlier that make him want to test the _CST patch.

Did he try the patches from this topic?

http://www.insanelymac.com/forum/index.php...t&p=1124268

				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x07)
						{
							"AAPL,current-available",
							0x05DC,
							"AAPL,current-extra",
							0x03E8,
							"AAPL,current-in-sleep",
							0x0BB8,
							Buffer (0x01)
							{
								0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}

http://www.insanelymac.com/forum/index.php...t&p=1240686

						Method (_DSM, 4, NotSerialized)
						{
						   Store (Package (0x04)
							   {
								 "AAPL,clock-id",
								 Buffer (0x01)
								 {
									 0x01
								 },
								 "device_type",
								 Buffer (0x05)
								 {
									"EHCI"
								 }
								}, Local0)
							DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
							Return (Local0)
						}

Yes, I already applied this patch in his DSDT except the current value is a bit different. There are two EHCI device & I set clock-id to 0x01 for EHC0 & 0x02 for EHC1. This is his DSDT if you want take a look:-

http://www.mediafire.com/?m25ymr7i6y28gm4 (My mistake, I set same clock-id at both EHCI device. It should be different.)

This is the one I cleanup for him earlier to troubleshoot the device removal issue after wake from sleep. All is original codes except PNLF, SBUS, EHCI sleep fix, LID sleep fix, Airport injection (AR9285) & RTC CMOS reset fix.

 

EDIT: @oSxFr33k, please fix the clock-id to 0x01 for EHC0 & 0x02 for EHC1 because both should not have same value. Also try change the current value like the above patch.

Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted

Remove IRQ from device PIC and move IRQs from devices RTC and TMR to device HPET

 

into device name_hid PNP0000 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0100 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} store_%8;
into device name_hid PNP0100 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0B00 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} store_%9;
into device name_hid PNP0B00 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0103 code_regex_not IRQNoFlags code_regex Name\s\(([^,]+),\sResourceTemplate\s\(\)\n\s+\{((?:.|\n)*)\}\) replace_matched
begin
Name (%1, ResourceTemplate ()\n
				{\n
					IRQNoFlags ()\n
						{%8}\n
					IRQNoFlags ()\n
						{%9}\n
%2
})
end

 

 

Remove IRQs from devices PIC, RTC and TMR, and add IRQs to device HPET

 

into device name_hid PNP0000 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0100 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0B00 code_regex IRQNoFlags\s\(\)\n\s+\{(\d+)\} remove_matched;
into device name_hid PNP0103 code_regex_not IRQNoFlags code_regex Name\s\(([^,]+),\sResourceTemplate\s\(\)\n\s+\{((?:.|\n)*)\}\) replace_matched
begin
Name (%1, ResourceTemplate ()\n
				{\n
					IRQNoFlags ()\n
						{0}\n
					IRQNoFlags ()\n
						{8}\n
%2
})
end

 

oldnapalm

Thank you very much

smokev.gif

Link to comment
Share on other sites
oSxFr33k
oSxFr33k
Posted
Posted

@kizwan,

 

Done. But should I keep the script the way it is now with Store (Package ()) or include two separate store package sections separating them as the above patches or just have it the way we have it now?

 

WHat other values should I try changing other than the Clock ID?

 

Lastly, should I apply Method Device IDs to all USB sections and EHCx sections as well as apply the AAPL to each USB device and if so would you happen to know how the script would look like for each USB? I know exaclty how to apply the Method Device Ids but I read from the posts above its not a good idea to have 2 separate methods, one for the Device Id and another for AAPL and just to combine them. If so I am curious as to how it should look for the EHCx sections and USB sections?

 

 

Thanks Again

Link to comment
Share on other sites
toology
toology
Posted
Posted

@oldnapalm: The DSTD file solved the problem without removing any kexts nor changing system identifier! Thanks a lot!

 

I have one more question: What is better for power management (like speedstep), VoodooPowerMini.kext or Apple built in? If your answer is the latter, would I need any further DSDT patching?

 

Once again, a big thank you for sharing your valuble knowledge and experience with us!

 

EDIT: Out of curiosity, I tried deleting SleepEnabler.kext and the computer refused to wake up. Seems like Ill have to keep using it.

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
@oldnapalm: The DSTD file solved the problem without removing any kexts nor changing system identifier! Thanks a lot!

 

I have one more question: What is better for power management (like speedstep), VoodooPowerMini.kext or Apple built in? If your answer is the latter, would I need any further DSDT patching?

 

Once again, a big thank you for sharing your valuble knowledge and experience with us!

 

To my knowledge, VoodooPowerMini doesn't activate C-States. I can't really tell you which solution is better as I am not familiar with different hardware. But I could speak of my experience if you like. My cpu is P8400.

 

1) I've extracted SSDT tables and loaded them back with AnVaL Bootloader from Extra folder. Since the memory addresses of these tables have been changed after overriding them, I need to find the new addresses by using VoodooKernel.

2) So modified the SSDT table accordingly.

3) Set a proper mac model, which is MacbookPro5,4. (Note that not every mac model can work for you.)

4) Created a legacy ACPI_SMC_PlatformPlugin.kext for MacbookPro5,4.

5) Created a legacy AppleGraphicsPowerManagement kext for MacbookPro5,4. (This drops my Open GL score but reduces the temperature after wake up. I may need to work on this. )

 

Now, I have P-States and C-States (Although I can't tell you how many of them have been activated).

 

Most of the time, especially if you are a laptop owner, when you set a proper mac model, OSX can read P-States from Bios with a legacy ACPI_SMC_PlatformPlugin.kext. I believe this is the easiest way of speedstepping. You don't need SSDT tables.

 

But, what I noticed is that after loading SSDT tables, my laptop boots with 28-35 C, which I've never seen before. It goes to C-States when idle more often. There is a noticeable difference between using the laptop on AC Power or Battery Mode in terms of C-States. I can't speak with a scientific mind but it seems to me that some C-States are only being activated on Battary Mode. Now, I don't hear the noise of a constantly running fan while watching a movie on VLC or a flash video on Youtube. (Using ClicktoFlash plugin.)

 

In case someone may ask. I tried Chameleon RC5's P-States and C-States features but my laptop works very hot with these features enabled.

 

Finally, I don't know how but I may need to edit CST table to get proper C-States and also underclock P-States by modifying PSS section.

 

Anyway, I hope this doesn't go off topic.

EDIT: Out of curiosity, I tried deleting SleepEnabler.kext and the computer refused to wake up. Seems like Ill have to keep using it.

You may need that kext until you start using vanilla power management.

Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted
I have one more question: What is better for power management (like speedstep), VoodooPowerMini.kext or Apple built in? If your answer is the latter, would I need any further DSDT patching?

Native power managment use Chameleon RC5

http://www.insanelymac.com/forum/index.php?showtopic=225766

 

Run on Terminal

kextstat | grep LPC

see if the kext is loaded

if the answer is no

use this patch

# Change ID of device with _ADR 0x001F0000 (LPC)
#
into method label _DSM parent_adr 0x001F0000 remove_entry;
into device name_adr 0x001F0000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package (0x02)\n
	{\n
		"device-id", \n
		Buffer (0x04)\n
		{\n
			0x16, 0x29, 0x00, 0x00\n
		}\n
	}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}
end

 

*many Asus boards do not need patches LPC and HPET

 

Out of curiosity, I tried deleting SleepEnabler.kext and the computer refused to wake up. Seems like Ill have to keep using it.

 

you need the Native power managment

Some motherboards also need to fix usb

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
  • Author
Posted
@oldnapalm: The DSTD file solved the problem without removing any kexts nor changing system identifier! Thanks a lot!

 

I have one more question: What is better for power management (like speedstep), VoodooPowerMini.kext or Apple built in? If your answer is the latter, would I need any further DSDT patching?

 

Once again, a big thank you for sharing your valuble knowledge and experience with us!

 

EDIT: Out of curiosity, I tried deleting SleepEnabler.kext and the computer refused to wake up. Seems like Ill have to keep using it.

I'm glad it solved the sleep issue, but I also included _CST to _PR scope, so native power management should work if you remove those kexts and change model identifier. Just check if AppleLPC.kext is loaded.

 

JBraddock and MaLd0n already answered your question, but I will confirm it, you can get rid of SleepEnabler when you have native power management working.

 

Edit: I just read your reply about AppleLPC. Can you check your original LPC device ID? You can use this app

http://www.insanelymac.com/forum/index.php?showtopic=219584

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
@kizwan,

 

Done. But should I keep the script the way it is now with Store (Package ()) or include two separate store package sections separating them as the above patches or just have it the way we have it now?

 

WHat other values should I try changing other than the Clock ID?

You only need to apply this patch in USB 2.0 device (EHCI). I already put the patch in your DSDT (already combined two patches in one _DSM control method). You just need to change the "AAPL,current-*" values with the one from oldnapalam's post (above). If there are more than one EHCI device in DSDT, clock-id value need to be different. In your case, you only need to change the clock-id value for second EHCI device (EHC1) from 0x01 to 0x02. :)

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...