keeza Posted October 20, 2009 Share Posted October 20, 2009 Ok, I'm in need of more specific information on how to add SBUS and EC to my DSDT. Anybody care to write a miniguide on the subject? :-) Oh, and including what the kext's that are floating around do (LegacyACPI_SMC_PP.kext, LegacyAGPM.kext). Thanks. Btw, I lost my headphone autodetection, any thoughts on the cause? At the moment I don't have working sleep, and the headphone thing. Otherwise everything is working as it should, except the missing SBUS etc of course. Here's my DSDT for debugging: DSDT_rc5.31.dsl.zip Try this, still a work in progress for me. SMBus_test.dsl.zip Link to comment Share on other sites More sharing options...
Beerkex'd Posted October 20, 2009 Share Posted October 20, 2009 Ok, I'm in need of more specific information on how to add SBUS and EC to my DSDT. Anybody care to write a miniguide on the subject? Download Master Chief's latest DSDT from here: http://www.insanelymac.com/forum/index.php...t&p=1280888 Open the .dsl and compare to yours. Then start editing. Read the whole P5K Pro thread, and this too: http://www.insanelymac.com/forum/index.php?showtopic=181631 Link to comment Share on other sites More sharing options...
William Parker Posted October 20, 2009 Share Posted October 20, 2009 So where's my crystal ball? Yes, your dsdt please! p.s. Don't you have a Device (SBUS) yet? Then please add/fix it first. Sure thing. 2 files one called DSDT.dsl which is the current edit, working okay, and the koalal.dsl which was output from the patcher by fixing LAN, NVIDIA, HDEF, HPET, etc. only. Thank you for looking. Archive.zip Link to comment Share on other sites More sharing options...
mm67 Posted October 20, 2009 Share Posted October 20, 2009 Fine. And what about removing "AAPL,clock-id" and using the other "AAPL..." items? That also works for you? Edit: You don't seem to have a working SBUS/EC Device combo. And that might explain why I don't need the extra bits. Could you please rename... what was it PX43 (?) to SBUS and make it work by adding the missing parts? And don't forget device EC ok I'm aware that it requires more of your free time, but it might help other GB owners a lot! Here is one with SBUS and EC, still can't remove those clock-id's from ehci devices. usbtest.dsl.zip Link to comment Share on other sites More sharing options...
William Parker Posted October 20, 2009 Share Posted October 20, 2009 Just an FYI. This took me in when I was sitting in front my computer with the air conditioner full blast. I had fixed dsdt & temps were around 33 C @idle. Next day I was back again @43-44. The weather was pleasant & so the AC was off, & I was ripping apart my dsdt to see what went wrong. Food was fuel for my brain, for while having lunch it struck me to switch the AC on & I was back @ 33. So friends ambient temperatures do make a significant difference. Hope this saves someone a wild goose chase. Link to comment Share on other sites More sharing options...
iSoprano Posted October 20, 2009 Author Share Posted October 20, 2009 I want you guys&gals to remove (comment out first if you like) the device_id bits of Method _DSM in all Device (UHCn) then tell me which board you have (ICH9 or ICH10) and if it works for you, or not of course. Chief, for ICH9, system fails to sleep without the device_id bits. Link to comment Share on other sites More sharing options...
FKA Posted October 20, 2009 Share Posted October 20, 2009 Just an FYI. This took me in when I was sitting in front my computer with the air conditioner full blast. I had fixed dsdt & temps were around 33 C @idle. Next day I was back again @43-44. The weather was pleasant & so the AC was off, & I was ripping apart my dsdt to see what went wrong. Food was fuel for my brain, for while having lunch it struck me to switch the AC on & I was back @ 33.So friends ambient temperatures do make a significant difference. Hope this saves someone a wild goose chase. Quite so ! it's just dropped down to around 13.C in London over the last week or so - if I don't have any heating on I'm just under 40.C - heating on it's back to 43 -44.C Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 Chief, for ICH9, system fails to sleep without the device_id bits. Too bad. The main problem is that I don't have a GB board. Hmm. Someone said: "Get a PayPal account and I'll donate some dope to get you cracking". Well. I don't know. Would that work?!? I mean I don't like to ask for money, but having a GB would help me greatly of course. And since I don't have a need for it... let me know what you guys think. Link to comment Share on other sites More sharing options...
pet1 Posted October 20, 2009 Share Posted October 20, 2009 Will this dsdt.aml work with my board? Isn't it suggested not to use dsdt.aml from other motherboards? Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 Sure thing. 2 files one called DSDT.dsl which is the current edit, working okay, and the koalal.dsl which was output from the patcher by fixing LAN, NVIDIA, HDEF, HPET, etc. only.Thank you for looking. I think I found something. Let's have a look at a code block: OperationRegion (SMIC, SystemIO, 0xB2, One) Field (SMIC, ByteAcc, NoLock, Preserve) { SCP, 8 } OperationRegion (APMP, SystemIO, 0xB2, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMD, 8 } Scope (\) { OperationRegion (SCPP, SystemIO, 0xB2, One) Field (SCPP, ByteAcc, NoLock, Preserve) { SMIP, 8 } } All three basically the same. And all three used to control Advanced Power Management. The second one isn't even used in the DSDT so comment it out. In fact do that for all three and add this: Name(SCP, 0x80000000) Name(SMIP, 0x80000000) The idea is basically to eliminate the OperationRegion/Field combo's. Let's see if you can do without them. Food first now! Link to comment Share on other sites More sharing options...
mm67 Posted October 20, 2009 Share Posted October 20, 2009 I think I found something. Let's have a look at a code block: OperationRegion (SMIC, SystemIO, 0xB2, One) Field (SMIC, ByteAcc, NoLock, Preserve) { SCP, 8 } OperationRegion (APMP, SystemIO, 0xB2, 0x02) Field (APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMD, 8 } Scope (\) { OperationRegion (SCPP, SystemIO, 0xB2, One) Field (SCPP, ByteAcc, NoLock, Preserve) { SMIP, 8 } } All three basically the same. And all three used to control Advanced Power Management. The second one isn't even used in the DSDT so comment it out. In fact do that for all three and add this: Name(SCP, 0x80000000) Name(SMIP, 0x80000000) The idea is basically to eliminate the OperationRegion/Field combo's. Let's see if you can do without them. Food first now! Works just fine with those modifications. Doesn't help with the usb clock-id's though. Link to comment Share on other sites More sharing options...
William Parker Posted October 20, 2009 Share Posted October 20, 2009 @ Master Chief Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results. Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work. As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike? Thank you very much Link to comment Share on other sites More sharing options...
FKA Posted October 20, 2009 Share Posted October 20, 2009 @ Master Chief Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results. Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work. As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike? Thank you very much Out of interest is your keyboard in a USB hub or direct to one of the MB's ports? D. Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 Works just fine with those modifications. Doesn't help with the usb clock-id's though. The purpose of this change is only to be able to remove the Windows/Linux bits from the DSDT simply because that for some is the main cause of PC Insomnia. And now you should be able to remove Name (OSFX, One) and Name (OSFL, One) And remember that OSFL is 0x02 so this: Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL, 0x02)) { Return (0x02) } Else { Return (0x03) } } can be changed into this: Method (_S3D, 0, NotSerialized) { Return (0x02) } You can also remove Method (^_INI, 0, NotSerialized) and Method (OSTP, 0, NotSerialized) and the calling code. I hope that I didn't forget anything, and otherwise I'm here (or just PM me). Whatever suits you best. Note: You probably know this already, but I'll add it here for the rest of the clan who isn't that far. @ Master Chief Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results. Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work. As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike? Thank you very much What we do is part of sleep and should also/eventually enable you to wake you hack with a single key press. p.s. Mine is connected to the a port at the back of my hack, and connecting the mouse to the left/right port on the Apple keyboard also enables me to wake my hack by mouse. Link to comment Share on other sites More sharing options...
FKA Posted October 20, 2009 Share Posted October 20, 2009 p.s. Mine is connected to the a port at the back of my hack, and connecting the mouse to the left/right port on the Apple keyboard also enables me to wake my hack by mouse. This is also how my Apple Pro keyboard and Logitech mouse are connected - Both wake the machine from deep sleep. Link to comment Share on other sites More sharing options...
mm67 Posted October 20, 2009 Share Posted October 20, 2009 You can also remove Method (^_INI, 0, NotSerialized) and Method (OSTP, 0, NotSerialized) and the calling code. I hope that I didn't forget anything, and otherwise I'm here (or just PM me). Whatever suits you best. Ok, removed everything except _INI methods. There is two in your dsdt, so which one should I remove. System still running fine. Here is my latest very heavily stripped down version. dsdt_stripped.dsl.zip Link to comment Share on other sites More sharing options...
xopher Posted October 20, 2009 Share Posted October 20, 2009 I've added SBUS and EC to my DSDT, but without success. Can't get it to compile. Could someone check it out? DSDT_SBUS.EC.dsl.zip Thanks Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 Ok, removed everything except _INI methods. There is two in your dsdt, so which one should I remove. System still running fine. Here is my latest very heavily stripped down version. dsdt_stripped.dsl.zip I was talking about this Method: Method (^_INI, 0, NotSerialized) { If (STRC (_OS, "Microsoft Windows")) { Store (0x56, SMIP) } Else { If (STRC (_OS, "Microsoft Windows NT")) { If (CondRefOf (\_OSI, Local0)) { If (_OSI ("Windows 2001")) { Store (0x59, SMIP) Store (Zero, OSFL) Store (0x03, OSFX) } } Else { Store (0x58, SMIP) Store (Zero, OSFL) } } Else { Store (0x57, SMIP) Store (0x02, OSFL) } } } Which I think you already removed. Anyway. Note the call to Method STRC since that can also be removed now, along with the two new Name([sCP/SMIP], 0x80000000) vars. You should also be able to remove the following lines from Method _WAK: \_SB.DBEN () Store (0xFF, DBG1) If (LEqual (Arg0, 0x03)) { Store (0x8F, SCP) } But the DBG1 bits must be checked first. Also remove the following bits from Method _PTR: If (LEqual (Arg0, One)) {} If (LEqual (Arg0, 0x03)) {} Store (0x99, SMIP) The first two are meaningless, and the last line is just a leftover from your previous work. Link to comment Share on other sites More sharing options...
mm67 Posted October 20, 2009 Share Posted October 20, 2009 I was talking about this Method: Method (^_INI, 0, NotSerialized) { If (STRC (_OS, "Microsoft Windows")) { Store (0x56, SMIP) } Else { If (STRC (_OS, "Microsoft Windows NT")) { If (CondRefOf (\_OSI, Local0)) { If (_OSI ("Windows 2001")) { Store (0x59, SMIP) Store (Zero, OSFL) Store (0x03, OSFX) } } Else { Store (0x58, SMIP) Store (Zero, OSFL) } } Else { Store (0x57, SMIP) Store (0x02, OSFL) } } } Which I think you already removed. Anyway. Note the call to Method STRC since that can also be removed now, along with the two new Name([sCP/SMIP], 0x80000000) vars. You should also be able to remove the following lines from Method _WAK: \_SB.DBEN () Store (0xFF, DBG1) If (LEqual (Arg0, 0x03)) { Store (0x8F, SCP) } But the DBG1 bits must be checked first. Also remove the following bits from Method _PTR: If (LEqual (Arg0, One)) {} If (LEqual (Arg0, 0x03)) {} Store (0x99, SMIP) The first two are meaningless, and the last line is just a leftover from your previous work. Ok, all that is gone, still working great. stripped2.dsl.zip Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 Ok, all that is gone, still working great. stripped2.dsl.zip Great job. Let's get cracking shall we? Have a look at the following lines of code: Scope (\) { Name (PICF, Zero) Method (_PIC, 1, NotSerialized) { Store (Arg0, PICF) } } And this is what the ACPI specification has to say about it: "The \_PIC optional method is to report to the BIOS the current interrupt model used by the OS. This control method returns nothing. The argument passed into the method signifies the interrupt model OSPM has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this method is optional for OSPM. If the method is never called, the BIOS must assume PIC mode. It is important that the BIOS save the value passed in by OSPM for later use during wake operations." Now note the last sentence, because that actually never happens in many of the DSDT's floating around here. And your DSDT, like many, only has two options, being: PIC (BIOS default) or APIC. What do you think about removing the extra bits? Let's have a look at one of these snippets: Method (_PRT, 0, NotSerialized) { If (LNot (PICF)) { Return (PICM) } Else { Return (APIC) } } Our goal is to have one Return() only! But that's not all of it because here's the longest part of it: Name (PICM, Package (0x10) { Package (0x04) { 0xFFFF, Zero, LNKE, Zero }, Package (0x04) { 0xFFFF, One, LNKD, Zero }, Package (0x04) { 0xFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNKA, Zero }, Package (0x04) { 0x0001FFFF, Zero, LNKD, Zero }, Package (0x04) { 0x0001FFFF, One, LNKC, Zero }, Package (0x04) { 0x0001FFFF, 0x02, LNKA, Zero }, Package (0x04) { 0x0001FFFF, 0x03, LNKE, Zero }, Package (0x04) { 0x0002FFFF, Zero, LNKC, Zero }, Package (0x04) { 0x0002FFFF, One, LNKA, Zero }, Package (0x04) { 0x0002FFFF, 0x02, LNKE, Zero }, Package (0x04) { 0x0002FFFF, 0x03, LNKD, Zero }, Package (0x04) { 0x0007FFFF, Zero, LNK1, Zero }, Package (0x04) { 0x0007FFFF, One, LNK1, Zero }, Package (0x04) { 0x0007FFFF, 0x02, LNK1, Zero }, Package (0x04) { 0x0007FFFF, 0x03, LNK1, Zero } }) Name (APIC, Package (0x10) { Package (0x04) { 0xFFFF, Zero, Zero, 0x14 }, Package (0x04) { 0xFFFF, One, Zero, 0x13 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x10 }, Package (0x04) { 0x0001FFFF, Zero, Zero, 0x13 }, Package (0x04) { 0x0001FFFF, One, Zero, 0x12 }, Package (0x04) { 0x0001FFFF, 0x02, Zero, 0x10 }, Package (0x04) { 0x0001FFFF, 0x03, Zero, 0x14 }, Package (0x04) { 0x0002FFFF, Zero, Zero, 0x12 }, Package (0x04) { 0x0002FFFF, One, Zero, 0x10 }, Package (0x04) { 0x0002FFFF, 0x02, Zero, 0x14 }, Package (0x04) { 0x0002FFFF, 0x03, Zero, 0x13 }, Package (0x04) { 0x0007FFFF, Zero, Zero, 0x17 }, Package (0x04) { 0x0007FFFF, One, Zero, 0x17 }, Package (0x04) { 0x0007FFFF, 0x02, Zero, 0x17 }, Package (0x04) { 0x0007FFFF, 0x03, Zero, 0x17 } }) Ok. This is a rather long example, but there are others which are less long, but clutter the DSDT. What do you think? Are you able to remove the extra bits? But this time I won't tell you what to remove or how to change it. Let's call it a challenge. Here's one tip I have for you: Add an If clause to this code: Load (IST0, HI0) to check the value of PICF. This is basically everything you'll need to know. More even so surprise me Good luck! I've added SBUS and EC to my DSDT, but without success. Can't get it to compile. Could someone check it out? DSDT_SBUS.EC.dsl.zip Thanks You sir should be able to use the great work done by fellow GB user/owner mm67 or at least verify/compare your changes with his DSDT, or try diff -uw old-file.dsl new-file.dsl Link to comment Share on other sites More sharing options...
xopher Posted October 20, 2009 Share Posted October 20, 2009 You sir should be able to use the great work done by fellow GB user/owner mm67 or at least verify/compare your changes with his DSDT, or try diff -uw old-file.dsl new-file.dsl That I realized a moment ago. I tried mm67's DSDT, and it works on my board as well. Checked the tech-specs and the only (obvious) differences between the boards are the absence of eSata and RAID on mm67's m/b. I had to add some bits (device-id) to get LPC to load, I then added my PSS-tables, but otherwise it booted superbly. How can I verify that SBUS/EC are working? I have the same problem with sleep as I did with my DSDT though, sleeps fine, but on wake-up (by mouse works, but..) it restarts. Thank you MasterChief and kiitos mm67, for putting up with me ;-) I've already learned a lot. Link to comment Share on other sites More sharing options...
Master Chief Posted October 20, 2009 Share Posted October 20, 2009 That I realized a moment ago. I tried mm67's DSDT, and it works on my board as well. Checked the tech-specs and the only (obvious) differences between the boards are the absence of eSata and RAID on mm67's m/b. I had to add some bits (device-id) to get LPC to load, I then added my PSS-tables, but otherwise it booted superbly. How can I verify that SBUS/EC are working? I have the same problem with sleep as I did with my DSDT though, sleeps fine, but on wake-up (by mouse works, but..) it restarts. Thank you MasterChief and kiitos mm67, for putting up with me ;-) I've already learned a lot. That's what we're here for. Having a bit of fun, and to learn something new. Here's a little howto for Device (SBUS): kextstat|grep SMBus 30 2 0x555c1000 0x3000 0x2000 com.apple.iokit.IOSMBusFamily (1.1) <5 4 3> 67 0 0x5ca8a000 0x2000 0x1000 com.apple.driver.AppleSMBusPCI (1.0.2d0) <14 5 4 3> 79 0 0x5c2b8000 0x9000 0x8000 com.apple.driver.AppleSMBusController (1.0.2d0) <30 14 13 5 4 3> Then do a kextstat|grep AppleIntel in a terminal window, this to check whether one or multiple CPU type kexts are loaded – you should only see one! Here's an example: 89 0 0x5c6e5000 0x7000 0x6000 com.apple.driver.AppleIntelPenrynProfile (17) <71 6 4 3> Link to comment Share on other sites More sharing options...
xopher Posted October 20, 2009 Share Posted October 20, 2009 That's what we're here for. Having a bit of fun, and to learn something new. Here's a little howto for Device (SBUS): kextstat|grep SMBus 30 2 0x555c1000 0x3000 0x2000 com.apple.iokit.IOSMBusFamily (1.1) <5 4 3> 67 0 0x5ca8a000 0x2000 0x1000 com.apple.driver.AppleSMBusPCI (1.0.2d0) <14 5 4 3> 79 0 0x5c2b8000 0x9000 0x8000 com.apple.driver.AppleSMBusController (1.0.2d0) <30 14 13 5 4 3> Then do a kextstat|grep AppleIntel in a terminal window, this to check whether one or multiple CPU type kexts are loaded – you should only see one! Here's an example: 89 0 0x5c6e5000 0x7000 0x6000 com.apple.driver.AppleIntelPenrynProfile (17) <71 6 4 3> Ok, I do see the SMBus-devices, but kextstat -k | grep AppleIntel gives me all these three: com.apple.driver.AppleIntelCPUPowerManagement (90.0.0) <7 6 5 4 3 1> com.apple.driver.AppleIntelCPUPowerManagementClient (90.0.0) <7 6 5 4 3 1> com.apple.driver.AppleIntelPenrynProfile (17) <69 6 4 3> Does this mean that the kexts (LegacyACPI_SMC_PP.kext and LegacyAGPM.kext) are not loading properly? Link to comment Share on other sites More sharing options...
Master Chief Posted October 21, 2009 Share Posted October 21, 2009 Ok, I do see the SMBus-devices, but kextstat -k | grep AppleIntel gives me all these three:com.apple.driver.AppleIntelCPUPowerManagement (90.0.0) <7 6 5 4 3 1> com.apple.driver.AppleIntelCPUPowerManagementClient (90.0.0) <7 6 5 4 3 1> com.apple.driver.AppleIntelPenrynProfile (17) <69 6 4 3> Does this mean that the kexts (LegacyACPI_SMC_PP.kext and LegacyAGPM.kext) are not loading properly? There's only one AppleIntel*Profile and thus it's ok. Link to comment Share on other sites More sharing options...
xopher Posted October 21, 2009 Share Posted October 21, 2009 There's only one AppleIntel*Profile and thus it's ok. Great! Actually, if I run kextstat right after boot, it shows Merom and Nehalem as well, but they're unloaded after a while it seems. Update: Confirmed, I rebooted and got the same result. Link to comment Share on other sites More sharing options...
Recommended Posts