Voodooprojects

Chameleon => General Discussion => Topic started by: Lord Anubis on May 28, 2009, 11:30:09 AM

Title: Using chameleon, how important is the DSDT file?
Post by: Lord Anubis on May 28, 2009, 11:30:09 AM
Hi,

Always, like you all, looking to get things right.

I did read that with 10.5.6+ and Chameleon we don't need the DSDT file anymore. f.e PCWIZComputer.com
Somewhere else they just talking about using that file.

Is this true, and what are your experiences?
Is maybe using or not using this file conflicting the [m]kext load?

Any comments on this
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Blackosx on May 28, 2009, 11:45:44 AM
Hi Lord Anubis

I don't use a DSDT file, like you I read that it wasn't needed with 10.5.6 so I have never used one.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Kabyl on May 28, 2009, 02:40:38 PM
I did read that with 10.5.6+ and Chameleon we don't need the DSDT file anymore. f.e PCWIZComputer.com
Somewhere else they just talking about using that file.

It was needed in the beta releases of 10.5.6 because of the new AppleRTC kext, in the final release the bug was gone and so the so called RTC fix in the DSDT wasn't necessary.

On some PCs the DSDT has serious bugs and fixes are needed, sometimes you *want* to fix it to get things working like PM (Power Management) stuff.

Unfortunately, there is a lot of misinformation, so try to find a good source and don't believe everything you read!
Title: Re: Using chameleon, how important is the DSDT file?
Post by: rocksteady on May 28, 2009, 07:19:47 PM
I was also intrigued from the rumors about its necessity back in the day before the final 10.5.6 update. However, since it ended up not being necessary, I dropped my research.

I'm using a modified BIOS on my hack and so far (X.5.7) everything is smooth (as far as hacks go).  Besides the now invalid AppleRTC.kext buzz, if my memory serves me right, the very first thing a patched DSDT was supposed to solve, is Processor aliases (popular for Asus mobos) in order to get all cores working (or get them to work they way they should) in order to avoid certain kernel panics.

Another member has posted some useful info in this thread: [Solved] Difference in booting with and w/o DSDT (http://forum.voodooprojects.org/index.php/topic,241.0.html) verifying a popular thread @insanely about Chameleon's DSDT override capabilities.

For reference's sake, here's a short definition of the Differentiated System Description Table  from the official ACPI Spec (http://www.acpi.info/spec.htm):
"An OEM must supply a DSDT to an ACPI-compatible OS. The DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system. The OS always inserts the DSDT information into the ACPI Namespace at system boot time and never removes it."

but as the LinuxACPI (http://www.lesswatts.org/projects/acpi/) project states:
"Unfortunately, many hardware vendors and OEMs are not capable of supplying fully functional tables (not even the members of the ACPI SIG).", which pretty much sums up why most of the hacks would benefit from a decently patched DSDT file.

Anubis, if you'd like to maintain this thread and come up with useful info I'd be happy to start researching DSDT again (as time permits). An easy+fast solution would be to integrate the info from the thread above into this one (I should move it anyway as its not part of the bugs).
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on May 28, 2009, 09:00:06 PM
Since 10.5.6, ASUS P5Q series boards can't boot OSX without the CPU aliases removed from the DSDT table.

So a patched DSDT is needed if you own one of those boards.

The patched BIOS files you can find for running OSX have the CPU aliases removed in the DSDT. It's convenient to use a patched BIOS but it can be risky and it's not as flexible as using DSDT.aml.

What's more, if you have near-compatible on-board sound, LAN and graphics you can add your hardware to the DSDT table and run without patched kernel extensions or third party drivers for that hardware.

It's a bit of a black art though. More voodoo than voodoo.

http://www.insanelymac.com/forum/index.php?showtopic=142434
 
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Lord Anubis on May 28, 2009, 09:47:10 PM
Anubis, if you'd like to maintain this thread and come up with useful info I'd be happy to start researching DSDT again (as time permits). An easy+fast solution would be to integrate the info from the thread above into this one (I should move it anyway as its not part of the bugs).


I did read in earlier info about DSDT, and not convinced that it is the holy grail.
After that I was curious what kind of influance DSDT has on the loading state of device id added modified kexts.

If DSDT is not needed anymore then IMHO Guess, it will'be a waste of time to do more research about it.

Thanks
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Blackosx on August 10, 2009, 11:20:38 PM
I don't use a DSDT file, like you I read that it wasn't needed with 10.5.6 so I have never used one.
How different things were for me back in May......   
Since then I read up on it, learnt how to build one and now I have a better system because of it. :)
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 18seven on August 15, 2009, 06:56:34 AM
Love it. IMO its a much cleaner than kext patching and offers many benefits otherwise missed. I just used it to enable hyperthreading with native ApplePowerManagement and looking forward to being able to utilize GCD in 10.6.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on August 15, 2009, 07:42:53 AM
That sounds cool, please post how you did it.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 18seven on August 15, 2009, 01:15:25 PM
Change the processor scope to system bus. Search for "Processor" change Scope (_PR) to Scope (_SB). Follow up on CPUs reference i.e search "CPU0" change each instance of \_PR.CPU0 to \_SB.CPU0, same for CPU1, CPU2, etc.. Declaring PR is default for legacy support, not current spec. Declaring SB also supports objects needed to enable native speedstep, at least that is my understanding.

Slightly ot but if anyone can ioreg dump a mac with Intel Xeon “Nehalem” processor or direct me to one already posted, it would be appreciated.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Lord Anubis on August 15, 2009, 04:18:20 PM
With 10.5.8 and the current chameleon version in mind, what is the best tutorial to get DSDT right?

I see several but always with complaining comments.

Thank you.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Blackosx on August 15, 2009, 05:19:10 PM
Hi Lord

I followed koalala's ACPIPatcher guide on Insanely. (showtopic=142434). It's a windows application but doesn't need to be run on your hack, a different windows machine will work. I have written a simple guide to help show the basics. It's no master class, but it gives an introduction to building a DSDT.aml. It's for the GA-EP45-DS3L, but the principle will be the same for your mobo. It's on insanely (showtopic=177497).

For different techniques and more advanced info, I am sure others here will be able to help.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on August 15, 2009, 08:45:54 PM
Change the processor scope to system bus. Search for "Processor" change Scope (_PR) to Scope (_SB). Follow up on CPUs reference i.e search "CPU0" change each instance of \_PR.CPU0 to \_SB.CPU0, same for CPU1, CPU2, etc.. Declaring PR is default for legacy support, not current spec. Declaring SB also supports objects needed to enable native speedstep, at least that is my understanding.

The only instance of _PR in my DSDT is at the beginning, at the part where you remove the CPU aliases. I can't find any other references to CPU0, 1, or \PR.CPU0, 1 etc.  anywhere else either. So I changed it to _SB, rebooted and it locked up during boot, sometime after this message (which I've never seen before):

ACPI_SMC_PlatformPlugin :: PushCPU_CSTData - _CST Evaluation failed

Then I tried disabling "CSTATE-tech" in the BIOS but then it locked up at initialization of AppleIntelCPUblabla instead.

I have to say that I love how easy it is to test these things with a Chameleon boot CD.

My CPU is a Core 2 Duo E8500 which doesn't have Hyperthreading of course but it would be cool to get native speed stepping working. If you do more research on this, please keep us posted.

Output from sysctl -a | grep freq:

kern.exec: unknown type returned
hw.busfrequency = 1332000000
hw.cpufrequency = 3160000000
hw.tbfrequency = 1000000000
hw.tbfrequency: 1000000000
hw.cpufrequency_max: 3160000000
hw.cpufrequency_min: 3160000000
hw.cpufrequency: 3160000000
hw.busfrequency_max: 1332000000
hw.busfrequency_min: 1332000000
hw.busfrequency: 1332000000

About the ioregs you're looking for, there's a thread at the ProjectOSX forums with attached dumps from real macs. I don't know if there are any Nehalem dumps available yet though.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 17, 2010, 06:37:43 AM
I have been doing some googling and found this topic. After reading, I just have one question about DSDT. DSDT is ACPI tables from the bios. Does the DSDT also include information about your CPU?

From what I read it covers p states for speed step and ram information but is that it? What about cpu speed information? Does the DSDT have that information in it and can it be edited if your bios provides the wrong information about your cpu like with the ASUS bioss and the cpu alias fix mentioned above?

I have looked in my own DSDT but I cant not find information about my cpu. Maybe I dont know what to look for. Is it even there?
Title: Re: Using chameleon, how important is the DSDT file?
Post by: valv on June 17, 2010, 03:20:03 PM
@00diabolic,
you are not looking in the right place. cpu states are declared in SSDTs. most are hidden from osx, that's u should dump 'em from linux or windows (if u don't know how, I made some guide on insanelymac (showtopic=215233)). Once u get those tables, look into _PSS section.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 20, 2010, 06:04:08 AM
Old thread is old. Nowadays, all peeps loving the Häagen-Dasz are using a modified DSDT.
ACPI_SMC_PlatformPlugin :: PushCPU_CSTData - _CST Evaluation failed
Getting rid of this message is one of the first steps towards working native CPU state switching.
To make it go away, we need to have AppleLPC.kext loaded (ref. time-vampire topic 181631 at Insanelymac).
This will also make the "Start up automatically after a power failure" checkbox appear in the Energy Saver preference panel, which when ticked helps to get S3 sleep working on some systems. A Win-Win situation.
The LPC device is part of the motherboard southbridge. My P5Q-E motherboard has the ICH10R southbridge, and this is the LSPCI output for the LPC device:
Code: [Select]
00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller [8086:3a16]
You will need this information to have AppleLPC.kext load on your vanilla Häagen-Dasz. Google 'LSPCI Snow Leopard' to find a LSPCI installer package.

The attached screenshot (see below) is from info.plist inside AppleLPC.kext, it's a list of supported LPC devices. As you can see, the closest ID (it's from the ICH10) to mine is 3a18. If I replace it with 3a16, AppleLPC.kext will load, the error message will go away and OS X can talk to my motherboards LPC device: http://en.wikipedia.org/wiki/Low_Pin_Count

Now, there are two ways to fix this (actually three but the 3rd way is kind of ghastly) we can use a LegacyAppleLPC.kext to override the device ID, or we can patch the LPC device in the DSDT (can I get a hell yeah).

Google (or make your own) LegacyAppleLPC.kext, use LSPCI to see the device ID of your LPC device, replace the closest ID in LegacyAppleLPC.kext/info.plist with yours. Install in /E/E or /S/L/E and hopefully it will work :-)

Below is the device ID override code I use in my DSDT to have AppleLPC load on my system. I like having this in the DSDT, IMO the less faffing around with kernel extensions the better. One of the major advantages to patching stuff via DSDT is that, unlike using patched kernel extensions, it's set-and-forget. Until you upgrade your BIOS, RAM or CPU of course.

In ASUS DSDTs the LPC device is normally named "SBRG", on Gigabyte boards, "PX40".
A sure-fire way is to use the information from LSPCI to find your LPC device. On my motherboard for example (as you can see above) the LPC device lives at "00:1f.0". Armed with this information, I could search my DSDT for "0x001F0" which would take me straight to the LPC device.
 
Mad props to zhell, I believe he came up with this way to override device IDs via DSDT (ref. topic 168014 at InsanelyMac)
I'm using Master Chief's MCDP method (topic 188920 at InsanelyMac) in the example below, it's an optimized version of Apple's DTGP method. Just replace it with the standard DTGP caller if that's what you're using. If you don't know what the hell I'm talking about, google 'DTGP method'.

Compare the code example with the LSPCI output and note how the device ID is 'backwards'. It is not necessary to inject vendor ID. It is also important to note that, as opposed to the legacy kext method, the code injects the device ID that I want my LPC device to have, not the device ID it already has!
Code: [Select]
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x02)
                        {
                            "device-id",
                            Buffer (0x04)
                            {
                                0x18, 0x3A, 0x00, 0x00
                            }
                        }, Local0)
                    MCDP (Arg2, RefOf (Local0))
                    Return (Local0)
                }
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 22, 2010, 07:25:08 AM
Gringo.. Thanks for the info. I have Start up automatically after a power failure checkbox in power saver. However I do not have appleLPC loaded when I looked through kextstat.

Could this be because I am using voodoopower and it makes the Start up automatically after a power failure show up?

I will use the DSDT fix to get this working but I am not sure I have the issue in the first place.

UPDATE.. After looking into this more.. I found my LPC device through LSPCI.  Mine is in the same place as yours.. 001f0..

00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 03)

So here is the entry in my DSDT.. I am using DTGP method for another thing. I am not sure what to change here.. can you help me with this?

Code: [Select]
Device (LPCB)
            {
                Name (_ADR, 0x001F0000)
                OperationRegion (LPC0, PCI_Config, 0x40, 0xC0)
                Field (LPC0, AnyAcc, NoLock, Preserve)
                {
                            Offset (0x20),
                    PARC,   8,
                    PBRC,   8,
                    PCRC,   8,
                    PDRC,   8,
                            Offset (0x28),
                    PERC,   8,
                    PFRC,   8,
                    PGRC,   8,
                    PHRC,   8,
                            Offset (0x40),
                    CMAR,   3,
                        ,   1,
                    CMBR,   3,
                            Offset (0x41),
                    LPTR,   2,
                            Offset (0x42),
                    CMAD,   1,
                    CMBD,   1,
                    LPTD,   1,
                    FDDD,   1,
                            Offset (0x48),
                    IOR2,   16,
                        ,   2,
                    LGRM,   6,
                            Offset (0xB0),
                    RAEN,   1,
                        ,   13,
                    RCBA,   18
                }

                OperationRegion (SMI0, SystemIO, 0xFE00, 0x02)
                Field (SMI0, AnyAcc, NoLock, Preserve)
                {
                    SMIC,   8
                }

                OperationRegion (SMI1, SystemMemory, 0xBF6E2EBD, 0x90)
                Field (SMI1, AnyAcc, NoLock, Preserve)
                {
                    BCMD,   8,
                    DID,    32,
                    INFO,   1024
                }

                Field (SMI1, AnyAcc, NoLock, Preserve)
                {
                            AccessAs (ByteAcc, 0x00),
                            Offset (0x05),
                    INF,    8,
                    INF1,   32
                }

                Mutex (PSMX, 0x00)
                Method (PHSS, 1, NotSerialized)
                {
                    Acquire (PSMX, 0xFFFF)
                    Store (0x80, BCMD)
                    Store (Arg0, DID)
                    Store (Zero, SMIC)
                    Release (PSMX)
                }

                Device (LNKA)
                {
                    Name (_HID, EisaId ("PNP0C0F"))
                    Name (_UID, One)
                    Method (_DIS, 0, Serialized)
                    {
                        Store (0x80, PARC)
                    }

                    Name (_PRS, ResourceTemplate ()
                    {
                        IRQ (Level, ActiveLow, Shared, )
                            {1,3,4,5,6,7,10,12,14,15}
                    })
                    Method (_CRS, 0, Serialized)
                    {
                        Name (RTLA, ResourceTemplate ()
                        {
                            IRQ (Level, ActiveLow, Shared, )
                                {}
                        })
                        CreateWordField (RTLA, One, IRQ0)
                        Store (Zero, IRQ0)
                        ShiftLeft (One, And (PARC, 0x0F), IRQ0)
                        Return (RTLA)
                    }

                    Method (_SRS, 1, Serialized)
                    {
                        CreateWordField (Arg0, One, IRQ0)
                        FindSetRightBit (IRQ0, Local0)
                        Decrement (Local0)
                        Store (Local0, PARC)
                    }

                    Method (_STA, 0, Serialized)
                    {
                        If (And (PARC, 0x80))
                        {
                            Return (0x09)
                        }
                        Else
                        {
                            Return (0x0B)
                        }
                    }
                }



Thanks
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 23, 2010, 05:08:40 AM
Your LPC device ID (2815) is already present in AppleLPC.kext (see plist screenshot above) so AppleLPC should load by itself on your system without any modification.

It's strange that it doesn't. Anyone have any idea why? Model identifier mismatch/smbios.plist funny business?

00diabolic, what model identifier are you using?

MacBookPro models 4,1: http://launchpadlibrarian.net/38035766/Lspci.txt
and 3,1: http://launchpadlibrarian.net/36085166/Lspci.txt
both have ICH8. If you're not using one of those maybe you can get AppleLPC.kext to load by itself if you change.
Google "MacBookPro4,1 (or 3,1) DMI" and follow links to bug reports at https://bugs.launchpad.net to get complete info (except serial numbers) to fill in smbios.plist.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 23, 2010, 05:52:37 AM
Hi thanks.. I am using macbook MacBook4,3 MB43.00C1.B00.0802091535 and a serial number made by the lizard app. I got the info from the apple site. I had Macbook4,1 but then read you should not use the exact model because its better to make up your own within the series. Is that right?

So I made a Macbook4,3 since there is no Macbook4,3. I am sure I got the specs right but maybe I missed something. The MacBook 4,1 matches my system almost perfectly. The only difference is the CPU. It has a 2.4ghz C2D and mine is a 2.5 C2D. Other then that it is the same x3100 graphics and chipset. Should I use something else?

Let me know I wanna get it right.

Here is my system info.

Lenovo 3000 N200 0769AVU Laptop/Macbook 4,3
OS: Leo 10.6.2 Snow Uni + Chameleon 2.0rc4 Testing: AnVAL - ACPI Loader
CPU: Intel Core2Duo T9300 2.5GHz 800fsb running at 738fsb due to Bios/SMBIOS issue
RAM: 4GB DDR2 @ 333MHz Dual Channel
Video: Intel X3100 965 Express CI/QE work default OSX kext
Sound: HDA 0862 works with VoodooHDA feb 2010 only
Wifi: BCM4328 Draft N card seen as Airport Extream 3rd Party
Webcam: Chicony Device ID 04f2 B013 Works with manycam!!
NW* Network: Broadcom 5906 Netlink Ethernet

Here is my Full LSPCI
Code: [Select]
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 [8086:2843] (rev 03)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f3)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 03)
00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller [8086:2829] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 03)
04:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)
06:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713] (rev 02)
08:06.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832]
08:06.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 19)
08:06.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 01)
08:06.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 0a)
08:06.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 05)
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 23, 2010, 07:08:02 AM
On a PC that matches an existing Mac as well as yours, I'd say that it's better to fake that Mac model. This is especially true in regards to speed-stepping and graphics power management because the active power profile depends on the Model Identifier. And your PC matches the MacBookPro4,1 so well it's practically begging for it.
The CPU being faster is not important, what matters is that it has the same family/type of CPU. This will ensure that OS X loads an appropriate power profile for it.   

Try using MacBookPro4,1 instead and see what you get. Install Apple Xcode (it's on the Snow Leopard retail DVD) so that you can run IORegistryExplorer. This will allow you to verify that your modifications are working.

Try finding MacBookPro4,1 DSDT and SSDT tables and compare to yours (search InsanelyMac and Project OSX forums).
You could probably use most of the code in it unmodified.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 25, 2010, 07:10:55 AM
Why are you saying macbookpro 4,1? That has nvidia graphics and not x3100 like mine. It seems the MacBook4,1 is better right? unless I'm really missing something? They both have the same CPU. Please correct me if I'm missing something here.

Here are the 2 models. I dont see how the pro fits my system better then the macbook does?

http://www.everymac.com/systems/apple/macbook/stats/macbook-core-2-duo-2.4-black-13-early-2008-penryn-specs.html
http://www.everymac.com/systems/apple/macbook_pro/stats/macbook-pro-core-2-duo-2.4-15-early-2008-penryn-specs.html

Also is it good to make up my own model number in the series? Change the 4,1 to 4,3? Your answer was not very clear on that. Ive read its better to make up a model within the series.

I have IOregistry explorer already..

I still do not have AppleLPC loading with MacBook4,1 (or 4,3) so I must still be doing something wrong..

When I try to force it to load it fails.. Here are the details on that..

Warnings:
    The booter does not recognize symbolic links; confirm these files/directories aren't needed for startup:
        /system/library/extensions/AppleLPC.kext/Contents/CodeDirectory
        /system/library/extensions/AppleLPC.kext/Contents/CodeRequirements
        /system/library/extensions/AppleLPC.kext/Contents/CodeResources
        /system/library/extensions/AppleLPC.kext/Contents/CodeSignature

Please let me know what you think.. Thanks 00D

UPDATE: I found an LSPCI for a MacBook 4,1

Product Name: MacBook4,1
Family: MacBook
Product Name: Mac-F22788A9
Version: Mac-F22788A9

Code: [Select]
lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 04)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 04)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 04)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 04)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f4)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 04)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 04)
02:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. Marvell Yukon 88E8058 PCI-E Gigabit Ethernet Controller (rev 1
04:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

Looks almost spot on to mine. I gotta think the MacBook 4,1 is better right?

I also found a DSDT and SSDT tables for a MacBookPro 4,1. If there is something that is better about using that one reguardless of the graphics difference I will give it a try and see what happens.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 25, 2010, 04:30:34 PM
You're right, it's a better match. I didn't look that closely at the other ones, I just saw Intel GMA graphics and ICH8. I don't know the specs of all Apple laptops by heart.. :o

About "making up your own model identifier in the series", that is complete nonsense. If you're not going to use a real model identifier then it makes no difference what you call it, because then there will be no match for it in any kernel extensions or anywhere else. You might as well call it "ROFLCopterX,Y".

The warning about symbolic links is strange, I've never seen anything like that.

Have you ever tampered with AppleLPC.kext?

What version of OS X are you running? I could attach an AppleLPC.kext for you, if I have the right version for your OS.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 25, 2010, 05:19:16 PM
HAHA.. Thank you for clearing that up. I thought it made no sense. I was wondering why this thinkpad t60 guide said it. Glad to know I will stick with MacBook 4,1 from now on.

I am running OSX 10.6.2 and since I know all of this I am going to attempt tonight to pull out a whole bunch of none apple kext and see what breaks in my install. I am going to first make my S/L/E vanilla and add all the extra kext to Extra and remove 1 at a time and then try to see if I can get APpleLPC to load. I do not want a patch LPC if I can help it. I really want to go for a vanilla system here. Can you think of any other reason I might not be able to get AppleLPC to load?

Also you mentioned that I might be able to use a real macs DSDT.aml. What kind of damage are we looking at if it fails? Will it simply not load and thats it. Or am I looking at seriously messing up my system with that idea? I now have the DSDT.aml from a MacBook 4,1 the exact system that matches mine so well. If I cant use it What kind of info could I grab from it? I am new to DSDT but I want to learn to make my system closer to a real mac. I cant find evidence of anyone using a real mac DSDT. Looking like no one has tried it. Should I give it a shot or to risky?



Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 26, 2010, 01:47:52 AM
AppleLPC will not load if you are using something that disables AppleIntelCPUPowerManagement.kext. Check for a Disabler.kext (it is not needed on hardware that can run the vanilla kernel) and nullCPUPowerblabla.kext

You should not have to patch AppleLPC.kext or do anything else to it, it should load by itself since the ICH8 LPC device ID is in the plist already (refer to screenshot above).

You can't use the DSDT from the macbook as it is but you can compare it to your own DSDT and try "porting" some of it, little by little. Chameleon loads DSDT.aml by default, but you can experiment with a "testDSDT.aml" which you can then load from the boot prompt. Check the Chameleon docs (Rocksteady posted them here in this forum) to see how to load an alternative DSDT.
I don't believe you can break your installation by modifying the DSDT but you should learn how to delete the extensions cache from terminal (booting from your install DVD) in case a modification causes an incompatible kernel extension to load and end up in the cache.

A good advice I think; stick to one thing at a time! If you're not using a modified DSDT yet, and OS X runs fine on your hardware, save it for later and concentrate on the kernel extensions for now so you can be more 'retail' and run the 10.6.4 update successfully.

I used the same strategy that you are talking about when making the transition from distro to retail, replacing patched kernel extensions with vanilla ones and moving everything to /Extra and /Extra/Extensions. It's boring but rewarding, if it means you can run retail in the end.

All the best DSDT guides that I've seen are on InsanelyMac, the EFI-x users forum, and there's a healty portion of useful info over at the Project OSX forums as well. Continue there (you have to take a quiz to earn posting privileges at the Project OSX forum) and I'll catch up with you if I see something I can help you with, we're too far off topic for the Chameleon forum at this point.

Good luck.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: 00diabolic on June 26, 2010, 06:05:08 AM
Hey thanks so much for your help. I am doing just as you say. Slowly moving towards a vanilla setup. I have a vanilla S/L/E right now and AppleLPC is now loaded. :-) I have found a ton of great guides at the sites your talking about but also some misinformation which is annoying. Also no one has my laptop except one guy and Azreal is not around anymore.

So now I am going to see if I can get rid of nullcpupowermgmt and platforumUUID.kext next out of E/E. I know that null will activate appleintelcpupowermgmt and platforumuuid should be taken care of by my bootloader.

Do you know if I will really have to do all the DSDT fixes to get native speedstep? Since I have appleLPC loading isnt that a sign it may just work as my system is now? Or will I have to edit the Scope (_PR) of my DSDT to get it working?

Lets hope I get no KP's.
Title: Re: Using chameleon, how important is the DSDT file?
Post by: Gringo Vermelho on June 26, 2010, 07:40:55 AM
I took the liberty of removing the redundant quotes from your posts.

Everything you need to know about getting speedstepping working on OS X is here:
http://www.insanelymac.com/forum/index.php?showtopic=181631

...explained by AsereBLN in a different (and slightly Gigabyte-motherboard-specific) way here:
http://efixusers.com/showthread.php?t=533

Now, please get out of here before the real moderators see this.  :P
I just broke a forum rule AND we're off topic.
I'll find you in one of the other forums.