Jump to content

Dell XPS 1340 mostly working with OSX 10.5.6,10.5.7

bcc9

By bcc9,
in Installation Guides

 Share
514 posts in this topic

Recommended Posts

mastrchee
mastrchee
Posted
Posted
So, with 10.5.7 my truemobile 1395 disappeared from the OS (yes, I know no one else with a 1340 has one... yet). It shows it in the menu next to the clock, but it says its off. Whenever i try to turn it on.... it remains off...

 

I figured if I switched PCI express slots it would work.... so I decided to swap it with the Bluetooth card. It appears as if my bluetooth card has a stripped screw holding it in. Anyone have any ideas how to get working?

 

Thanks!

 

try the broadcom enabler script in in the hardware section

Link to comment
Share on other sites
Gambit642
Gambit642
Posted
Posted

After the 10.5.7 update, is anyone else get 667MHZ FSB reporting in "About my Mac". CPU-x is showing the correct 1066 FSB, but the profiler is reflecting it incorrectly. I tried replacing the SMBIOS; SMBusPCI and SMBusController from the ones from the XxX install, but still shows fron FSB.

 

Did anyone else get this after 10.5.7?

 

What extension controls this?

Link to comment
Share on other sites
shumik
shumik
Posted
Posted
After the 10.5.7 update, is anyone else get 667MHZ FSB reporting in "About my Mac". CPU-x is showing the correct 1066 FSB, but the profiler is reflecting it incorrectly. I tried replacing the SMBIOS; SMBusPCI and SMBusController from the ones from the XxX install, but still shows fron FSB.

 

Did anyone else get this after 10.5.7?

 

What extension controls this?

 

i had this before 10.5.7 and i have it now. it also says ddr2

Link to comment
Share on other sites
Gambit642
Gambit642
Posted
Posted
i had this before 10.5.7 and i have it now. it also says ddr2

We're saying the same thing. Its reporting DDR2 at 667.

DDR3 runs, minimum, at 1066 (shows as 1067)

 

Something vanilla in that 10.5.7 distro over-wrote something which is causing false identification.

I also had upgraded to the Chameleon 2.0rc1 boot manager, maybe that's the cause.

 

shumik, are you using the default Darwin boot manager from the XxX distro or have upgraded to chameleon to?

Link to comment
Share on other sites
shumik
shumik
Posted
Posted
We're saying the same thing. Its reporting DDR2 at 667.

DDR3 runs, minimum, at 1066 (shows as 1067)

 

Something vanilla in that 10.5.7 distro over-wrote something which is causing false identification.

I also had upgraded to the Chameleon 2.0rc1 boot manager, maybe that's the cause.

 

shumik, are you using the default Darwin boot manager from the XxX distro or have upgraded to chameleon to?

 

i am using 2.0rc1... i have it since 10.5.6. i had the issue with ddr2 before i upgraded to 10.5.7. unfortunately i don't remember what exactly started to cause it, i guess whatever i did in 10.5.6 and whatever the upgrade does is the same thing. maybe it was the 2.0rc1, or something else.

Link to comment
Share on other sites
Gambit642
Gambit642
Posted
Posted
you can mod the smbios.plist file to show whatever you want!

I havn't done this before but I think I did it right and it still doesn't work. Chameleon 2.0rc1 is supposed to be able to take a smbios.plist and inject SMBIOS strings through the boot loader if you place that plist in the /Extra folder on the root of the drive. It does nothing; makes no difference what I set anything to, like its ignoring the plist all together. I set owner to root and permissions to 755. I even downloaded a few from online and provided them in the same location. I think Vanilla is starting to patch some of the unofficial OSX86 drivers. Has anyone gotten this to work? Is there something i have to due for smbios.plist to be interpreted by Chamealon? Between this and the battery (all the ACPI) issue, Im am seriously thinking about going back to Vista.

 

I do remember reading something that a string in SMBIOS had to match the EFI string of your machine, but how and which string?

Link to comment
Share on other sites
kzharia
kzharia
Posted
Posted
Here's what I've figured out so far on getting OSX working on the dell studio xps 1340, aka dell studio xps 13.

 

Working "out of the box":

  • gig-ethernet, usb, firewire, sata
  • system suspend
  • touchpad as mouse
  • webcam (video only), video capture verified with photo booth application

Working with mods below:

  • GeForce 9400M G graphics with quartz extreme
  • Built-in speaker, hotkey volume/mute controls
  • Intel speedstep
  • Touchpad gestures with voodoo team's voodoops2controller Note that you should uninstall your AppleACPIPS2Nub.kext when installing this voodoo kext else you'll get panics and problems with keyboard input. Also I seem to be unable to post a link to this mod "You have entered a link to a website that the administrator does not allow links to"

Not working:

  • Proper ps2 keyboard bindings (modifier keys for mac command/option map wrong)
  • Built-in digital mic, mic-in jack, mute of speakers when headphones attached
  • touchpad unusable resume
  • battery status, suspend on lid close
  • Dell 1515 802.11 wireless (atheros ar9280 aka ar5009). However some systems ship with the older Dell 1510 802.11 which is broadcom based and works. According to Atheros' press release in 2007 the 1515 supports OSX. So I think we basically just need to keep waiting for Atheros or Apple to publish the alleged driver. That is unless someone wants to roll their own based upon the linux version. I certainly don't care enough to do that.
  • SLI with 9500m video

For installation I recommend the XxX 10.5.6 distribution, as it's the only distribution I could find that handled booting off of nvidia sata devices.

(Before XxX I tried the iPC livedvd, and that would hang during boot, apparently due to lack of nvidia sata support. Older distributions such as kalyway, boot & install but the OS randomly hangs, apparently due to problems with the sata drivers.)

 

With XxX, during the install, you need not select any of the optional kexts. Note that more is not necessarily better - you can screw up features such as system suspend by installing kexts that were meant for other chipsets such as older nvidia chipsets.

 

For working quartz Extreme & core image (QE/CI), install my modified IOPCIFamily kext, and my EFI plist. My EFI plist includes EFI strings for the 9400m video and for the IDT audio. To apply the plist to your com.apple.boot.plist using OSX86 Tools:

  1. Save attached plist file as something.plist
  2. Run OSX86 Tools
  3. Select Add EFI Strings/Boot Flag
  4. Select Import Hex/Plist
  5. Select Import File
  6. Select the plist file you just saved, click choose
  7. Select import string to boot editor
  8. select apply changes to com.apple.boot.plist

Replace the existing IOPCIFamily kext with my modified kext (manually or using something like kexthelper).

 

For working IDT audio you'll also need the attached AppleHDA.kext. Thanks to the Dell 1535/1735 folks (ridgeline, boombeng) for coming up with IDT audio pathmaps that begin to work on this laptop. Unfortunately this kext is from 10.5.3 and at also seems to be flaky for some users, as it was for the 1535/1735.

You should *not* need to install HDAEnabler.kext as advised elsewhere as my EFI plist includes the audio EFI string already.

Update: Verify working audio by ensuring that "Internal Speakers" is available and selected under System Preferences->sound->output, then go to the sound effects tab and try something.

 

For working CPU throttling (intel speedstep) use my modified version of superhai's VoodooPower.kext. Attached. (I've attached my source code changes as well, which is only of interest if you're a developer.) Superhai has some support applications: GenericCPUPMControl, vpower over here, and there's also cpu-x to monitor the CPU multiplier state.

 

I could really use some help on the non-working components! Such as:

  • For the battery status and lid, the ACPI devices show up. If you install VoodooBattery from here, the battery icon shows up but the battery remains unavailable. Looks to me like this is because no ACPI events ever go thru. This in turn is apparently due to lack of working ACPI controller (AppleACPIEC plugin doesn't load, nor does AppleSMBusPCI). I think both of these should be loading OK since the controller hardware is the same as for the unibody macbook (nvidia mcp79).
  • For SLI video, need someone who has the 9500m to try and work on a 2nd graphics EFI string for the 9200m part. I think the right devicepath for the 9200m is:
    PciRoot(0x1)/Pci(0x0c,0x0)/Pci(0x0,0x0), but I don't have a 9500m to play with this.
  • For audio, it'd be great if someone could figure out how to get the 10.5.6 version of the IDT-modified AppleHDA.kext to work. I get no audio devices with this version. Also both analog&digital mics work under linux with alsa 1.0.19, but not under OSX, even with what looks like the right pathmap. Clues?

Contributions welcome

 

Hi There!!!!!

 

I read this over and it looks like this may be the closest tut to get my Dell XPS M1210 (with the cursed Intel GMA 950 graphics card which only seems to work with the iATkos 5i install---vid card crashes on update on my current 10.5.5 machine.

 

Here's the million dollar question...is there ANY way to get a retail install of 10.5.6 to work on my machine??? I've spent about two days experimenting and reading and crashing and Time Machining...I know deep down inside this can happen...and probably would if it weren't for the Intel GMA card....

 

Can u help? I would SOOOOO appreciate it!

 

I have a 300gb harddrive with 100gb ready on my third partition for the retail install, 1st partition is WinXP/Ubuntu, 2nd partition is iatkos

Link to comment
Share on other sites
Gambit642
Gambit642
Posted
Posted

According to this FreeBSD documentation, our DSDT is f***ed in the 1340 BIOS.

 

"ACPI depends on a Differentiated System Descriptor Table (DSDT) provided by each machine's BIOS. Some machines have bad or incomplete DSDTs, which prevents ACPI from functioning correctly. Replacement DSDTs for some machines can be found at the DSDT 3 section of the ACPI4Linux 4 project Web site. FreeBSD can use these DSDTs to override the DSDT provided by the BIOS; see the acpi(4) manual page for more information."

 

Assuming we have no DSDT experts, someone should beg dell to fix their DSDT {censored} in their next BIOS release. Man I don't know why Dell is still f***ing with NVidia!

 

Source: FreeBSD Docs

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
According to this FreeBSD documentation, our DSDT is f***ed in the 1340 BIOS.
I don't see how you come up with that conclusion from the generic description you quote. In fact I'd go further and say I disagree with your conclusion as the dsdt for the 1340 works fine under linux.
Link to comment
Share on other sites
shumik
shumik
Posted
Posted

to me the thing i would like to see in my xps1340 hackintosh is the dual view on my 9400m. Other things I can survive without. Battery - ok, I will just use common judgement, and i am plugged in 99% of the time anyway. Mic - I have a usb headset... inconvenient to carry it around, but ok. Closed lid status - I can just sleep my computer manually before closing. But the dual-view problem doesn't get resolved. :-( Have to reboot in vista or ubuntu everytime i want to watch a video on a big screen.

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

So I have managed to patch AppleACPIPlatform so that it is able to setup the interrupt vectors for the GPE blocks. Looks like AppleACPIPlatform was wrongly assuming that there was just 1 GPE block, or that if there were two, they were contiguous.

With my patch, AppleACPIEC no longer fails to initialize with the "ACPI: EC <number> register GPE handler failed" error. So the ACPI embedded controller finally seems to load. With ACPIEC loaded, I'm now getting DSDT "Method parse/execution failed" errors when VoodooBattery is run, for these objects:

_SB_.PCI0.LPC0.EC0_.BAT0.UPBI
_SB_.PCI0.LPC0.EC0_.BAT0._BIF
_SB_.PCI0.LPC0.EC0_.BAT0.UPBS
_SB_.PCI0.LPC0.EC0_.BAT0._BST

Looks like voodoobattery can't handle the complexity of the _BIF & _BST methods in the 1340's DSDT. Has anyone worked on making the DSDT simpler for voodoobattery or have a fix for voodoobattery?

Link to comment
Share on other sites
mastrchee
mastrchee
Posted
Posted

hmm i would try it, but everytime i try to install a distro, when i go in to diskutil, it screws up all my other partitions (ntfs partitions). any hints on that?

 

on a different note, has anyone managed to get HDMI working?

 

thanks.

Link to comment
Share on other sites
Cheesy
Cheesy
Posted
Posted
So I have managed to patch AppleACPIPlatform so that it is able to setup the interrupt vectors for the GPE blocks. Looks like AppleACPIPlatform was wrongly assuming that there was just 1 GPE block, or that if there were two, they were contiguous.

With my patch, AppleACPIEC no longer fails to initialize with the "ACPI: EC <number> register GPE handler failed" error. So the ACPI embedded controller finally seems to load. With ACPIEC loaded, I'm now getting DSDT "Method parse/execution failed" errors when VoodooBattery is run, for these objects:

_SB_.PCI0.LPC0.EC0_.BAT0.UPBI
_SB_.PCI0.LPC0.EC0_.BAT0._BIF
_SB_.PCI0.LPC0.EC0_.BAT0.UPBS
_SB_.PCI0.LPC0.EC0_.BAT0._BST

Looks like voodoobattery can't handle the complexity of the _BIF & _BST methods in the 1340's DSDT. Has anyone worked on making the DSDT simpler for voodoobattery or have a fix for voodoobattery?

 

Good work ! I would like to have a go at this (making voodoo battery work), could you please post your patch ?

 

Regards !

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

Great news -

I cleaned up the compiler errors from the dell DSDT such that it cleanly compiles with the intel compiler (the stock DSDT is microsoft compiler based). Then I installed the custom DSDT with the chameleon bootloader. Viola, no more DSDT errors upon boot and VoodooBattery now works.

 

Side effect: When the system goes to sleep automatically or manually, it immediately wakes up from the sleep, logging "Wake reason = PWRB". Hmm.

 

Will post my AppleACPIPlatform fix shortly. It was definitely the hard part in figuring this out.

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

Here is my patched version of the 1.2.4 version of AppleACPIPlatform, from OSX 10.5.6. Replace the stock version in /System/Library/Extensions/AppleACPIPlatform.kext/Contents/MacOS with this version.

 

Gory details on the patch in case anyone is interested:

My patch was to take where the code was initializing the GPE vector sizes, and double the size of GPE block 0 as read from the FADT table. See FreeBSD's AcpiEvGpeInitialize() for the exact code which Apple copied into AppleACPIPlatform. By doubling the reported len of GPE block from 8 to 16, the vectors for block 0 & block 1 become contiguous. This then prevents the buggy code in initEventVectors() from mis-computing the total size. With the vectors for GPE block 1 allocated, the ACPI embedded controller is finally able to initialize.

[update: My newer version of this change simply hacks initEventVectors() to compute the total size with GPE block #1 included. Hacking the length of block 0 seemed cleaner but was causing AcpiEnterSleepState() to fail.]

 

Also here is my modified DSDT. My laptop is on the A06 BIOS so this DSDT is based upon that.

[Edit: See first post for revised DSDT, and revised applieacpiplatform patch]

Link to comment
Share on other sites
pmcnano
pmcnano
Posted
Posted

thanks again bcc9, you are the man here. anyway, ill post my results latter since i cant try yet.

 

edit:

 

Working juuuuust fine! thanks bcc9.....really..you have put a lot on effort with this and its very much appriciated!

 

Thanks again

 

edit2:

 

Just for you to know...I made a thread some months ago in hackint0sh forum......its updated and ordered. If you want to use it to update your first post..is cool if not is cool too XD

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
thanks again bcc9, you are the man here. anyway, ill post my results latter since i cant try yet.

 

edit:

 

Working juuuuust fine! thanks bcc9.....really..you have put a lot on effort with this and its very much appriciated!

 

Thanks again

You're welcome. It was a lot of work figuring out what Apple did wrong with AppleACPIPlatform, I might not have tried if I knew it'd take so much effort :thumbsup_anim:
Just for you to know...I made a thread some months ago in hackint0sh forum......its updated and ordered. If you want to use it to update your first post..is cool if not is cool too XD
Yes, I'm planning to update the first post but it'd be real nice to figure out why sleep doesn't work when the embedded controller is initialized. I'm guessing that one of the methods in the DSDT that depends upon the controller is causing a problem; anybody good at troubleshooting sleep problems?

Also I now made separate 10.5.7 versions of my AppleACPIPlatform, IOPCIFamily changes, need some way to sanely present separate versions for the separate releases. I hadn't noticed a hackint0sh thread, I'd be happy to crib something from there if you already made better instructions. Personally I don't really want to get into owning a total newbie guide tho.

Link to comment
Share on other sites
bogeyboy89
bogeyboy89
Posted
Posted

Hey just wanted to say thanks for taking the time to help us all out and make so much progress on the 1340.

 

Personally i picked mine up about a month ago and it was only through your help that i got a stable version of OSX on it(well minus the battery and sleeping issue).

 

Thanks alot to Bcc9 and everyone else who has posted and helped work out the problems.

 

Waitin for the 10.5.7 versions of the patched Kexts so i can update. Also it would be wonderful if you could post exactly how to get battery workin on first post for everyone.

 

Thanks Again. Keep up the good work!

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

I've updated my first post with 10.5.7 versions of IOPCIFamily, AppleACPIPlatform, and updated the instructions. I've also revised my posted DSDT with a new version that includes a notify method to fix the LID status (working suspend notification upon lid close). However the lid fix is pretty useless right now as suspend is still not working properly. I really really could use some help on that.

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