Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About ab___73

  • Rank
    InsanelyMac Protégé
  1. What do you mean by stop function? Does it shutdown by selecting shutdown in the menu? Does it Restart using menu? Does it Sleep using menu? I'm thinking of updating but won't until shutdown/restart/sleep functions work. BTW thanks for the guide. - AB
  2. @oSxFr33k, I've never seen a key called PSSInfo, we know PSS is working in IOREG by finding items in the Array key: "PerfomanceStateArray" Or by using voodoomonitor, or coolbookcontroller. I think you have P-States working, that's great! These will help cool your CPU, temperature difference between P-State code, could be undervolting your CPU with the P-States package. Change your code to : OperationRegion (GPIO, SystemIO, 0x1080, 0x3C) Field (GPIO, ByteAcc, NoLock, Preserve) { GU00, 8, GU01, 8, GU02, 8, GU03, 8, GIO0, 8, GIO1, 8, GIO2, 8, GIO3, 8, ...... ...... ...... How to find this address: $ lspci -xxxvvv -d8086:2815 Gives you: 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 02) Subsystem: Dell Unknown device 022e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information <?> 00: 86 80 15 28 07 01 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 2e 02 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: [color="#0000FF"]01 10[/color] 00 00 80 00 00 00 [color="#FF0000"]81 10[/color] 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 07 0a 80 80 91 00 00 00 0b 0a 09 80 00 00 00 00 ..... ..... Red bytes: Swap these bytes gives: 10 81 and take away 01, address for GPIO is 0x1080. I've confirmed this with vanilla DSDT from an Acer Netbook and a Gigabyte motherboard. Blue bytes: Our PMBASE, swap and take away 01, address for PMBASE is 0x1000. We now need to copy code to get this working, and also the EC device working, i think these are essential to allow the LPC device to get registered in the OS. -- AB
  3. If you don't get CSTInfo in IOREG, then i suspect, C-States aren't functional. I've still got the LPC Register error. No Cigar for me -- AB Your correct these functions do not add anything to our DSDT. Must have been some left over code copied from another DSDT. FYI: This code refers to the General Purpose Event and ours is located at PM_BASE+0x2C, so even we tried to use the script above we would have to change the SystemIO address to 0x102C. The SystemIO used in the script above must have came from a DSDT with a PM_BASE of 0x400 (Mac, or Desktop PC). On another topic: I've also found that our GPIO base address is 0x1080. this is located in position 0x48 of our lpc device. We need to change this in our DSDT, if we would like to use these fields properly. This info comes from the Intel ICH8 chipset reference, located at the intel website. -- AB
  4. Their Chameleon code is broken, for now. I'm sure someone is working on a fix.
  5. Looked at it very interesting, just now the latest revision and 350 is not working, memory alloc error. I've also looked over their code and it looks as if it's hardcoding the CPU PM Base Address into the CST generator. We would need to adjust the code to match ours. (Macs,Giga and Asus Desktops have 0x410, most laptops including M1330 and M1530 have 0x1010 as the CPU PM Base, this is address (+0x4 and +0x5) is always located somewhere in the _CST section of D/SSDT table) Thanks for this link, i'm going to keep a close eye on this. -- AB
  6. All mainboards I've came across that report C-States working have a PMBase of 0x400 and a CPU PMbase of 0x410. Can anyone disprove this? -- AB
  7. AnVAL (ACPI Loader)

    Have you tried, DSDT=<file> All boot parameters are case sensitive. -- AB
  8. My latest findings..... Another difference is that our PM base address is 0x1000, all apple macs are 0x400, our CPU address is PMbase + 0x10h = 0x1010 and apple cpu base address is 0x410. I've decompiled the ACPI_SMC_PlatformPlugin binary in the ACPI_SMC_PlatformPlugin.kext and found that this kext is hardcoded to look at the PM base of 0x410. __ZN23ACPI_SMC_PlatformPlugin17registerLPCDriverEP9IOServicebPb: 000027b2 pushl %ebp 000027b3 movl %esp,%ebp ..... ..... 00002a36 movl (%eax),%eax 00002a38 movl %edx,(%esp) 00002a3b call *0x00000094(%eax) 00002a41 movl %eax,0x000000f4(%edi) 00002a47 movb $__ZNK23ACPI_SMC_PlatformPlugin12getMetaClassEv,0x00000151(%edi) 00002a4e cmpw $0x8086,0xd2(%ebp) 00002a54 jne 0x00002aab 00002a56 movb $0x01,0x00000151(%edi) 00002a5d calll __ZL12getCPUIDInfov 00002a62 cmpl $0x05,%eax 00002a65 jne 0x00002a76 00002a67 movl $0x00000410,__ZL13gIOPMBaseAddr <<--Assigns the 0x410 value into the IOPMbaseaddr address. 00002a71 jmpl 0x00002b51 00002a76 movl (%esi),%eax 00002a78 movl $__ZN23ACPI_SMC_PlatformPlugin19enableCStateSupportEb,0x04(%esp) 00002a80 movl %esi,(%esp) 00002a83 call *0x000004bc(%eax) 00002a89 andl $0xfe,%eax 00002a8c movl %eax,__ZL13gIOPMBaseAddr 00002a91 movb $0xa8,0x000000f8(%edi) 00002a98 movb $0x54,0x000000f9(%edi) 00002a9f movb $0x58,0x000000fa(%edi) 00002aa6 jmpl 0x00002b51 00002aab cmpw $0x10de,0xd2(%ebp) 00002ab1 jnel 0x00002b51 ..... ..... My theory is (sorry not good news) All LPC control is based on this PMBase address and this is one of the reasons why we cannot get the LPC Device to register correctly with the OS. I've also patched this binary to use the 0x1010 address and it still fails to register, so there must be other parts of the OS that hard codes this address into the code. It would be good if we could somehow change our PMBase to 0x400, this is assigned in the FADT.aml table but requires the BIOS to assign code or functions at this address for it work (i think). I've attached the decompiled binary. ACPI_SMC_PlatformPlugin.s.zip
  9. Bretts DSDT.aml does allow sleep, i would guess you're problem is associated with a kext. Do you have any NullCPUPowermanagement kexts or the like loaded in your system? -- AB
  10. Came across this in ProjectX forums... It's an ioreg file of a newer MacPro4,1.. Maybe this will help us? Cheers, AB MacPro4_1.zip Sorry this is not a MacBookPro, I keep getting these two mixed up!!!
  11. Hi Brett, Both attachments are the same? Do you have the SSDTs from a MacBookPro4,1. Cheers, AB
  12. All, I actually thought this article was dead!! Sorry folks.... Just to let you all know, since there is a demand for this, I'm writing a new SSDT loader into the Chameleon RC4. I thought the devs over at chameleon would have done this by now. I'll keep you all posted when it's been tested. Unless someone beats me to it? (AnV) I've got a few small extras up my sleeves. Cheers, AB
  13. Yes, i'm here. I'm also short of a MB4 or MBP4 ioreg. I would love to have this ioreg. It may be the answer to one of our dreams. The following topic contains a snow leopard kernel based on the voodoo kernel that you could use to output the kprintf=1 information, i've tried it but it takes ages to boot up (i used the 10.0.2 version)... Snow Kernel Boot options command for dmesg output using this kernel: legacy_kernel -v kprintf=1 blacklist=0 I'll post my dmesg output once i reboot. Cheers, AB dmesg: ACPI: RSDP @ 0xe63000/0x0024 (v002 DELL ) ACPI: XSDT @ 0xe66000/0x0064 (v001 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: FACP @ 0xe67000/0x00F4 (v004 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: DSDT @ 0xe5e000/0x4B1C (v002 INT430 SYSFexxx 0x00001001 INTL 0x20080926) ACPI: FACS @ 0xdfe82800/0x0040 ACPI: HPET @ 0xdfe73b00/0x0038 (v001 DELL M08 0x00000001 ASL 0x00000061) ACPI: APIC @ 0xdfe73c00/0x0068 (v001 DELL M08 0x27D80B13 ASL 0x00000047) ACPI: MCFG @ 0xdfe73bc0/0x003E (v016 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: SLIC @ 0xdfe73c9c/0x0176 (v001 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: OSFR @ 0xdfe73200/0x002C (v001 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: BOOT @ 0xdfe737c0/0x0028 (v001 DELL M08 0x27D80B13 ASL 0x00000061) ACPI: SSDT @ 0xdfe7217e/0x04CC (v001 PmRef CpuPm 0x00003000 INTL 0x20050624) .... .... ACPI: SSDT @ 0xdfe72cb4/0x02C8 (v001 PmRef Cpu0Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0xdfe7264a/0x05E5 (v001 PmRef Cpu0Cst 0x00003001 INTL 0x20050624) ACPI: SSDT @ 0xdfe72f7c/0x00C4 (v001 PmRef Cpu1Ist 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0xdfe72c2f/0x0085 (v001 PmRef Cpu1Cst 0x00003000 INTL 0x20050624) VID: strict PM order enforced Warning - kext com.apple.iokit.CHUDProf has immediate dependencies on both com.apple.kernel* and com.apple.kpi.* components; use only one style. Warning - kext com.pctools.iantivirus.kfs has immediate dependencies on both com.apple.kernel* and com.apple.kpi.* components; use only one style. DSMOS has arrived ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized
  14. Hi, The M1530 has 1 "visible" SSDT located at 0xDFE7217E, this is ACPI table 7. This SSDT table then loads the "invisible" SSDT tables using the array of memory locations per my previous post. Extract from the XSDT dump: [024h 036 8] ACPI Table Address 0 : 00000000DFE7389C [02Ch 044 8] ACPI Table Address 1 : 00000000DFE73B00 [034h 052 8] ACPI Table Address 2 : 00000000DFE73C00 [03Ch 060 8] ACPI Table Address 3 : 00000000DFE73BC0 [044h 068 8] ACPI Table Address 4 : 00000000DFE73C9C [04Ch 076 8] ACPI Table Address 5 : 00000000DFE73200 [054h 084 8] ACPI Table Address 6 : 00000000DFE737C0 [05Ch 092 8] ACPI Table Address 7 : 00000000DFE7217E When using the DropSSDT=yes boot option the loading of the "visible" SSDT table is skipped, so the OS never sees any of the SSDT tables. I've confirmed this by modifying the boot file to debug and output the "visible" SSDT memory address locations. I've attached the "debug" chameleon boot file it's based on RC4 source code (again thanx to the chameleon team for releasing sources). Backup you existing bootfile: sudo cp /boot /boot.bak then extract and copy the extracted boot file to your / directory. Once you have seen what you need to see restore your boot file sudo cp /boot.bak /boot Please only use this if you know what you are doing. Hopefully this helps someone. Cheers, AB boot.zip