Jump to content

[GUIDE] Making a DSDT.aml for Dell XPS M1330, XPS M1530, and XPS M1730

immo

By immo,
in Laptops

 Share
2,030 posts in this topic

Recommended Posts

Brett Whinnen
Brett Whinnen
Posted
Posted

Yes have the original locations in one of my previous DSDT's where I put SSDT in there as well.

 

I wanted to see if they are loaded into the same spot or if we need to modify the addresses they are referenced from based on where they are loaded if we do it via DropSSDT=Yes. I'm just trying things from a different angle from the bits I was looking at yesterday...

 

The thing of note and I was playing with this all yesterday is that yes we get the LPC loaded, as we have a pci8086:2815 which is exactly what a MacBookPro3,1 has I've yet to locate a lspci -nn output from a MacBookPro4,1 or a ioreg for that matter. But even though the LPC kext is loaded it is not properly initiialized, which means the C-states will not be started (regardless of whether we have them loaded or not). I ended up changing the device ID of the LPC yesterday to a number of different ones, even so far as trying to set it to the pci10de:0aae which is the LPC for a MacBookPro5,1 that most of us use (mainly due to P-States number issues).

 

One thing I couldn't do above was to set the vendor from 8086 to 10de, so will investigate further on that one.

 

The other option I'm looking at is to calculate up 10 p-states to allow the MacBookPro4,1 to load without modifying the resource under ACPI_SMC_PlatformPlugin to be 6 p-states...

Link to comment
Share on other sites
jkbuha
jkbuha
Posted
Posted 

00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
00:01.0 PCI bridge [0604]: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port [8086:2a01] (rev 0c)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 02)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 02)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 02)
00:1c.5 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 [8086:2849] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 02)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 02)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller [8086:2829] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 02)
01:00.0 VGA compatible controller [0300]: nVidia Corporation G86 [GeForce 8400M GS] [10de:0427] (rev a1)
03:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
03:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
03:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
03:01.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 12)
03:01.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 12)
09:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713] (rev 02)
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4328 802.11a/b/g/n [14e4:4328] (rev 03)

 

Here's mine from my M1330 - slightly different but not that much...

Could it be the different Nvidia graphics card (and memory?)

 

Cheers

jkbuha

Link to comment
Share on other sites
ab___73
ab___73
Posted
Posted
Yes have the original locations in one of my previous DSDT's where I put SSDT in there as well.

 

I wanted to see if they are loaded into the same spot or if we need to modify the addresses they are referenced from based on where they are loaded if we do it via DropSSDT=Yes. I'm just trying things from a different angle from the bits I was looking at yesterday...

 

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

Link to comment
Share on other sites
dlach
dlach
Posted
Posted
Yes have the original locations in one of my previous DSDT's where I put SSDT in there as well.

 

I wanted to see if they are loaded into the same spot or if we need to modify the addresses they are referenced from based on where they are loaded if we do it via DropSSDT=Yes. I'm just trying things from a different angle from the bits I was looking at yesterday...

 

The thing of note and I was playing with this all yesterday is that yes we get the LPC loaded, as we have a pci8086:2815 which is exactly what a MacBookPro3,1 has I've yet to locate a lspci -nn output from a MacBookPro4,1 or a ioreg for that matter. But even though the LPC kext is loaded it is not properly initiialized, which means the C-states will not be started (regardless of whether we have them loaded or not). I ended up changing the device ID of the LPC yesterday to a number of different ones, even so far as trying to set it to the pci10de:0aae which is the LPC for a MacBookPro5,1 that most of us use (mainly due to P-States number issues).

 

One thing I couldn't do above was to set the vendor from 8086 to 10de, so will investigate further on that one.

 

The other option I'm looking at is to calculate up 10 p-states to allow the MacBookPro4,1 to load without modifying the resource under ACPI_SMC_PlatformPlugin to be 6 p-states...

 

I've been thinking about the c-state addresses as well. I've been toying with Andy V's branch of Chameleon which lets you load the SSDT tables individually. I'd had no success with another platform on which I had working c-states with the SSDTs embedded in the DSDT. I was getting the same LPC error with separate tables that we get on the m1530 with SSDTs embedded and it got me wondering. I've since found out that if you don't load embedded SSDTs you have to change the addresses they are expected at, see the thread HERE. Planning on digging some more this weekend.

Link to comment
Share on other sites
Brett Whinnen
Brett Whinnen
Posted
Posted

I've been doing some tidying up on the DSDT, mainly cosmetic changes to match names of devices to those from the MBP5,1. But that got me thinking, the MBP5,1 uses an nVidia based main board, complete with MCP79 controllers etc. I was also looking at the MBP3,1 and it is closer, in fact it uses the very same LPC controller as ours and a great deal of other devices match up in both name and address.

 

So what I want to find now is the ioreg output (prefer a .ioreg file but a .txt will do) and DSDT from a MacBookPro4,1. If anyone has seen one in their travels or can get hold of one please pass them onto me. I've seen almost every model but not that one! Most annoying.

Link to comment
Share on other sites
Neonkoala
Neonkoala
Posted
Posted
I've been doing some tidying up on the DSDT, mainly cosmetic changes to match names of devices to those from the MBP5,1. But that got me thinking, the MBP5,1 uses an nVidia based main board, complete with MCP79 controllers etc. I was also looking at the MBP3,1 and it is closer, in fact it uses the very same LPC controller as ours and a great deal of other devices match up in both name and address.

 

So what I want to find now is the ioreg output (prefer a .ioreg file but a .txt will do) and DSDT from a MacBookPro4,1. If anyone has seen one in their travels or can get hold of one please pass them onto me. I've seen almost every model but not that one! Most annoying.

 

Knew I saw one somewhere:

 

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

Link to comment
Share on other sites
overshoot
overshoot
Posted
Posted

I saw this one too...

 

The fact is that it is ab____73 which has posted this and i saw him posting on this thread...

Probably he still have a MBP4.1 and is able to give you the ioreg...

 

ab____73, are you there? ;-)

Link to comment
Share on other sites
CalaverX11
CalaverX11
Posted
Posted

Having a problem here.

 

This process seems to work about 90% of the way on the Dell Precision M4400 (similar configuration to the XPS M1530). The RIGHT side USB ports on my machine are non-functional, which also seems to have taken out the Dell Wireless 370 card (was using DellBluetoothHCI.kext), both of which worked using an older dsdt.aml. Files and lspci/lsusb output are linked.

 

What works:

- Sleep/Shutdown

- Left side and dock USB ports

- Webcam

- Audio (using VoodooHDA)

- Keyboard and touchpad/stick (using modified PS2 kexts)

- Wireless hard toggle (turns Bluetooth and WiFi antennae off and on, Airport recovers connection)

- Though probably irrelevant, Chameleon 2 RC4 handles GraphicsEnabler just fine (Quadro FX 770M)

 

What's broke:

- Restart(?!)

- Right side USB ports and Bluetooth (was using DellBluetoothHCI.kext)

- PC Card (tested) and ExpressCard (untested, no cards to test with)

- SDHC; VoodooSDHC doesn't seem to do anything at all

 

KEXTs in use (in /Extra/Extensions):

AHCIPortInjector.kext

AppleACPIBatteryManager.kext

AppleACPIPS2Nub.kext

ApplePS2Controller.kext

DellBluetoothHCI.kext

HDAEnabler.kext

IOACPIFamily.kext

IOAudioFamily.kext

IONetworkingFamily.kext

IOPCCardFamily.kext

IOPCIFamily.kext.BACKUP

Intel82566MM.kext

OSvKernDSPLib.kext

OpenHaltRestart.kext

PlatformUUID.kext

VoodooHDA.kext

fakesmc.kext

SleepEnabler.kext (in /S/L/E)

 

UNMODIFIED dsdt.dsl:

http://pastebin.com/bN5gb1W2

 

MODIFIED dsdt.dsl using instructions from post 1:

http://pastebin.com/GF92UAsF

 

I'm posting from within Mac OS right now, I'll have lspci and lsusb up in a minute.

 

EDIT:

Output of lspci -v:

http://pastebin.com/5MQx4nTY

 

Output of lsusb -v:

http://pastebin.com/5kpj1MxF

 

Hardware:

Dell Precision M4400

CPU: Intel Core 2 Extreme QX9300 quad-core @ 2.53GHz, 12MB L2

RAM: 8GB DDR2 800MHz Corsair (not sure of the chipset)

Chipset: Not specified, I believe Intel ICH9

GPU: NVIDIA Quadro FX 770M 512MB

 

Currently running Snow Leopard 10.6.3. My previous setup used the unmodified dsdt.dsl listed above, plus a few additional kexts, along with ClamShellDisplay, in 10.6.2. Updating to .3 broke sleep and ClamShell completely, so I tried using these dsdt instructions to make them work. The tradeoff was non-functioning USB ports and Bluetooth, which I can sort of live without (except that I have a Bluetooth mouse).

 

Any help would be appreciated.

Link to comment
Share on other sites
ab___73
ab___73
Posted
Posted
I saw this one too...

 

The fact is that it is ab____73 which has posted this and i saw him posting on this thread...

Probably he still have a MBP4.1 and is able to give you the ioreg...

 

ab____73, are you there? ;-)

 

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

Link to comment
Share on other sites
Brett Whinnen
Brett Whinnen
Posted
Posted

And look they are exactly where they should be too...

 

Really want the ioreg now, or an lspci -nn from the MBP4,1 as this will be the telling tale on the HW installed...

 

I have a MB3,1 and a MB5,1 but the same no MB4,1, same with the MBP.

Link to comment
Share on other sites
CalaverX11
CalaverX11
Posted
Posted

Update, and interesting find:

 

The right-side USB ports and Bluetooth DO work with this dsdt--after booting into Ubuntu, and rebooting into Snow.

 

Another piece to the puzzle. Apparently, the ACPI calls from a cold boot aren't sufficient. Rebooting from Ubuntu into Snow Leopard doesn't fully power off the laptop and doesn't send calls to devices to power down, so devices are active and detectable when OSX loads. But starting from a cold boot, not all of the buses initialize properly. Why is this? Can this be fixed in my dsdt, or do I need to start from scratch?

 

Also: here's a dump from Ubuntu from /proc/acpi/dsdt (decompiled using iasl in Ubuntu):

http://pastebin.com/kQc2nau5

Link to comment
Share on other sites
Brett Whinnen
Brett Whinnen
Posted
Posted

You did this fix? As this fixed a very similar issue with the M1530 and USB detection.

 

Required for Snow Leopard: Fix USB Devices Randomly Not Working - Added 2009/20/14

Reportedly, some are having issues with USB randomly not working on startup, but then trying again will bring the USB back. I haven't actually experienced this. Perhaps it is Snow Leopard specific? Jkbuha and FMulder have come up with this fix (thanks!):

EDIT 2009/10/22 -> I've now updated to Snow Leopard, and sure enough this is REQUIRED for proper USB function.

Remove the following two lines from the Device (TMR) section:

			IRQNoFlags ()
			{2}

Link to comment
Share on other sites
CalaverX11
CalaverX11
Posted
Posted
You did this fix? As this fixed a very similar issue with the M1530 and USB detection.

Yes.

 

Now it's working. Here's what happened.

 

Up until today, I was using getDSDT to get a dsdt dump from the machine in its running state in OS X. I was already using a slightly-modified dsdt.aml I got from another user, which apparently was being pulled by getDSDT; I compared it to another modified dsdt.aml I had saved from a backup, and they were identical. So I used the /proc/acpi/dsdt dump I made and started from scratch, with a pure, untouched dsdt template. I added the fixes for:

- USB (removing IRQNoFlags mentioned above)

- ClamShell

- Shutdown

and Master Chief's OSXRestart.kext (thank you for that, btw). I skipped the EHC2 and EHCI additions, as well as the DTGP addition. I then compiled using DSDT Patcher -newHPET.

 

After confirming no kernel panics or kext issues using -s -v -x -f, I rebooted and let the OS load on its own. As of now, I have working:

- USB (all ports, machine and dock)

- Sleep, Shutdown (using patches)

- Restart (using OSXRestart.kext)

- Bluetooth (using latest DellBluetoothHCI.kext)

 

The toggle switch appears to be working as well. Right now my fan is blowing like mad, but the machine is a little warm and it's not very cool in this room, so I'll have a better idea of the stepping/cooling ability later on tonight.

 

Most importantly, thanks to this guide, I'm several HUGE steps closer to having a Dell Precision M4400 MacBook Pro equivalent.

 

If anybody is interested (particularly the thread OP immo), I can detail everything I used to get vanilla 10.6.3 running on my M4400 in its current state, which includes the dsdt patches I found here, which were the biggest help of all.

Link to comment
Share on other sites
immo
immo
Posted
  • Author
Posted
If anybody is interested (particularly the thread OP immo), I can detail everything I used to get vanilla 10.6.3 running on my M4400 in its current state, which includes the dsdt patches I found here, which were the biggest help of all.

 

That may be helpful to anyone else who has an M4400. There have been others who have also gotten their non M1330 and M1530 computers working with this guide. Perhaps I will add a section linking to posts of people that got other computers working with the guide when I get a chance. Glad the guide was of help.

 

Immo

Link to comment
Share on other sites
CalaverX11
CalaverX11
Posted
Posted
That may be helpful to anyone else who has an M4400. There have been others who have also gotten their non M1330 and M1530 computers working with this guide. Perhaps I will add a section linking to posts of people that got other computers working with the guide when I get a chance. Glad the guide was of help.

 

Immo

 

I appear to be back at square one...after doing a few more reboots using the tools above, the USB/Bluetooth functionality seems to be totally random and intermittent. I'm going to try a few more DSDT hacks to see if I can make it work.

 

Everything else (sleep, shutdown, restart) works as advertised. This is the ONLY thing preventing me from making it 100% useable. If anybody can offer any insight outside of everything from the first page, I'd appreciate it.

Link to comment
Share on other sites
immo
immo
Posted
  • Author
Posted
Hi Immo,

 

 

It looks like a MacPro 4.1 ioreg, not a MacBook Pro 4.1, isn't it?!

 

 

Julien.

{censored}! Sorry about that. Looks like I got the 3.1 and 5.1 that everyone else has :)

 

Immo

Link to comment
Share on other sites
overshoot
overshoot
Posted
Posted
MB41_SSDT.zip

 

SSDT from a MB4,1. Haven't found the DSDT yet.

 

MB41_SSDT.zip

 

DSDT and some SSDT from the MBP4,1.

 

Also what does your battery status say next to Condition? I've made a change to the DSDT and mine now says Replace Soon, I am sure it used to say Service Battery...

 

Cheers

 

Brett

 

Mine say "replace now" (as it was an order...) ;-)

Link to comment
Share on other sites
CalaverX11
CalaverX11
Posted
Posted

At the end of the day, persistence and tenacity pays off.

 

I combined elements of the tutorial here with this one and this one. USB and Bluetooth still refused to work even with the patched DSDT, but I found another solution in a patched IOPCIFamily.kext. I now have an M4400 with working shutdown, restart, sleep, and fully-functional USB and Bluetooth.

 

My next mission will be to patch SSDT to enable C-states. Since removing NullCPUPowerManagement.kext my machine IS running quite a bit hotter, so if I can get proper power stepping re-enabled that will be one of the last pieces to the puzzle.

Link to comment
Share on other sites
donkey
donkey
Posted
Posted
At the end of the day, persistence and tenacity pays off.

 

I combined elements of the tutorial here with this one and this one. USB and Bluetooth still refused to work even with the patched DSDT, but I found another solution in a patched IOPCIFamily.kext. I now have an M4400 with working shutdown, restart, sleep, and fully-functional USB and Bluetooth.

 

My next mission will be to patch SSDT to enable C-states. Since removing NullCPUPowerManagement.kext my machine IS running quite a bit hotter, so if I can get proper power stepping re-enabled that will be one of the last pieces to the puzzle.

 

Sounds like a good plan. C-States would be great!

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...