Driver compatibility for Dell Studio 14z (Successful OSX install!)

[GAOO]

September 17 UPDATE:

 

Almost everything works in OSX now! Special thanks to bcc9 and westep23 for their effort! If you want to install Snow Leopard, there's some info here but it may be obsolete (read the entire thread for more info!)

 

Here's a brief overview to get everything working (This is NOT a step by step guide! Read through it so you get a general idea what you have to do, what works and doesn't work. All the necessary device drivers mentioned should be in the zip file attachment):

 

- OSX: First things first, get OSX installed onto your studio 14z. You can dual/triple boot it whatever way you want, and you can use retail OSX install or a distribution install (iATKOS v7 is confirmed to work). I will not discuss the details involved in installing OSX, it is assumed you are familiar with it. If you do the retail install and have the EFI partition, then you should place the necessary drivers and files there. So that if OSX for some reason dies, you still have the necessary kexts backed up in another partition.

 

BTW, while regular Leo seems to definitely work, SL (Snow Leopard) also seems to work.. more details below.

 

- Boot loader: Use Chameleon v2. This is needed so we can use a DSDT that helps OSX recognize all the correct devices. If you use iATKOS v7, Chameleon v2 is checked by default. If you use the retail disk, there are a number of guides elsewhere that help you get Chameleon v2 installed (look into boot132 and munky's method?).

 

Once you have Chameleon v2 installed, then you should have an Extra folder to wherever your boot partition is. The Extra folder will include the skins for Chameleon v2, and the Extra folder is where you will also drop off the DSDT.aml file. I believe you can also place the DSDT.aml file in the root of the boot partition. The DSDT.aml file is included in the the zip file attachment.

 

NOTE: You should place the DSDT file last! You need the display override files to have graphics working for the 720p screen. Read below in the Graphics section.

 

- Graphics: To get your graphics driver working, you will need to insert two Display Override files into your system if you have the 720p screen. If you have the 900p screen, then you probably don't need to insert those files. The reason is because the 720p screen has an odd resolution that is unsupported by OSX, and the display overrides will adjust the resolution.

 

Basically, unzip the two DisplayVendoID_XXX.zip files in the Graphics folder, and move the resulting directories into /System/Library/Displays/Overrides/ . Then copy the DSDT file to the right location so it will get loaded at boot, restart and you should have working graphics! (DSDT file location is described above).

 

- Sound: Need the HDAIDT kext (included). Install it, then by having the boot loader (Chameleon v2) load the DSDT file, sound should be recognized and work. Input and output (both speaker and headphone) both works.

 

- Webcam: Webcam is a standard USB HP webcam, it is recognized by OSX automatically.

 

- Wifi: There are two available Wifi cards. One supports Wifi G only, the Dell 1397 (or Broadcom 4312 I think), and the other supports Wifi N, the Dell 1515.

 

For the Dell 1515, I do not know of any solution for regular Leo. For SL, mmoogle had it working by running SL in 32bit mode and edit the info.plist in the Atheros kexts to include in the correct PCI ID.

 

For the Dell 1397, you need the Broadcom43xx kext. It is included in iATKOS v7, though I'm not sure if it works out of the box. Included in the zip file is an installer for the kext (Broadcom.pkg). Run it, restart, then open the terminal, and run the bcrm43xx_enabler.sh script included in the same folder. After another restart, wireless should now work.

 

- Bluetooth: The bluetooth module is the Dell 365. You need to run a small program (hid2hci) to get bluetooth working everytime. Run it with hid2hci -p 8162 to enable bluetooth. Included are also directions on how to make the script run at login.

 

- Ethernet: ??? No idea, doesn't seem to work, sorry.

 

- Battery: Use VoodooBattery.kext to have it enabled.

 

- Trackpad: Kind of working. Will definitely work as a dumb mouse. To have the special features like two finger scrolling, take a look into forums for VoodooPS2Trackpad kexts (Not included). A small group of developers are working on a trackpad that has the same manufacturer as ours.

 

Hope that helps. Again special thanks to bcc9 and westep23 for helping us to get everything to work! Thanks to everyone else who contributed as well!

 

 

Additional Info:

 

How to run a script: To run a script, open up terminal, and go into the directory where your script is. Make sure your script is executable (use chmod 755 FILENAME if you need). Then, to run it, it's simply ./SCRIPT_NAME .

 

More Snow Leopard Install Info: mmoogle (thanks!) described more info about his SL install here -

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

 

 

Original Post:

 

Hi everyone,

 

I was just wondering if anyone knows about the compatibility of any of the hackintosh distributions with the Dell Studio 14z (1440)? More specifically whether there are compatible drivers available for the Studio 14z hardware?

 

Here are some of the specs for the Studio 14z:

 

Intel� Core� 2 Duo T9550 (2.66GHz/1066Mhz FSB/6MB cache)

14.0" High Definition+ (900p) Bright LED Display with TrueLife�

3GB Shared Dual Channel DDR3 at 1066MHz

320GB SATA Hard Drive (5400RPM)

NVIDIA� GeForce� 9400M G

Dell Wireless 1397 802.11g Half Mini-Card

Dell Wireless 365 Bluetooth Internal (2.1)

High Definition Audio 2.0

Back-lit Keyboard

 

 

Any info would be greatly appreciated, thank you

Studio_14z_OSX_Install_Files.zip

[sheeplover]

I'm wondering about this too.

I'd love to get one of these little cuties – but I'm a bit afraid that it might have some incompatible hardware, although the specs read just fine...

[GAOO]

From what I know and can google up, the audio will work, and bluetooth can be configured to work after some tweaking.

 

But my primary concern is with the GPU NVIDIA® GeForce® 9400M G and the wireless network card Dell Wireless 1397 802.11g Half Mini-Card.

 

Does anyone have any info whether there are any drivers for those 2? Much appreciated if anyone can share any info...

 

Thank you!

[murdock743]

Hi,

 

I put OS X on my studio 14z though I cannot get the sound to work properly, no wireless, and no graphics support past 1024x768. Though my specs are a little different. I have the dell Wireless 1515 Wireless-N and I don't have the same processor as you, I have the stock T4200. If anyone can give me a link to how to get the audio working or that wireless card it would be much appreciated.

 

Cheers,

Christian

[GAOO]

Hey Murdock743,

 

I went to Best Buy yesterday to check out more details of the Studio 14z specs, and from what I found, it seems to use some kind of nForce chipset. The device manager listed a Nvidia nForce SATA Controller and a Nvidia nForce System Management Controller.

 

I was really doubtful whether OSX would even boot on the Studio 14z b/c of that, so I'm glad to hear that you got it booting.

 

I'm not sure whether you can get the wireless 1515-n to work, since I think it's relatively new and I don't remember seeing drivers for it. Most wireless cards tend to have problems with OSX so I guess it's nothing new. The sound is managed by this Nvidia High Def Sound, so I'm not sure whether there's a driver for that to get it working.

 

However, I think you should be able to get the Graphics working since the GeForce 9400 is what the MacBooks (Pro) are using.

 

If you would like to work together to try to get your Studio 14z to work, let me know. I would be very interested in helping you to get it to work (so I'll also know what to do with my 14z when I get it ). Also, do you mind telling us which distribution you're using and what options/steps you have taken so far?

 

Much appreciated, thanks.

[westep23]

As requested by bcc9 in the other thread. Here is the dsdt. I couldn't get natit to work in 10.5 only in SL. But on sleep it wont wake up.

dsdt.dsl.zip

[GAOO]

Thanks a lot for posting that westep23, I was just beginning to look at how to get the DSDT, thanks a lot!

 

Regarding the Natit.kext that bcc9 provided in the other thread, I could not get it to work either. I tried it both on iATKOS v7 and Boot132+Retail Disk 10.5.6+EFI Partition, both with the same result of no display output (blank screen). I do see the Natit setup 3 times in the boot process using -v in both installs. HannibalX said that he got it working on his Boot132+Retail Disk 10.5.6+EFI partition, however he hasn't replied back to my messages yet..

 

It's interesting to see that it works in Snow Leopard. In any case, I've been hearing different results of the Natit.kext, so I'm not even sure what to think or do anymore.

[bcc9]

Thanks again for your detailed reply bcc9, your help is much appreciated!

 

Was the other user who just PMd about his success westep23 that just posted above? It's hard to deduce what is working and what is not since none of the 14z users are sharing any information.

Yes. You guys (+Hannibal) need to be talking to each other not thru me. I don't have a 14z to test what is/isn't working for you after all.

I am using OSX86Tools to install the kexts since I got lazy tongue.gif But I will do the manual terminal method just to make sure that there is nothing missing.

osx86tools is fine for setting up the kext permissions; I don't know if it knows to maintain the mkext cache if you're using /Extra however.

I will also try to use the DSDT after I get Chameleon set up with the EFI partition. The battery is of secondary importance to me at the moment.

Should be nearly trivial to replace your boot loader with chameleon. I don't know why you'd want the extra complexity of a separate EFI partition however. GUID partition tables don't play well with windows&linux so MBR partitions seem like a better choice for a dell laptop for which one is likely to be using OSes other than OSX as well.

It seems like the Macbooks 13in all have native resolution of 1280x800 which could be the reason why the XPS 1340 has no trouble. But the 14z has 1366x768 which I am guessing OSX's NVidia driver doesn't know how to manage?

Like I said, the driver is able to pick up the resolution from the EDID. I've tested it with 1920x1200 resolution external monitors and it picks up that resolution too. The resolution is not stored in the NVCAP.

 

As requested by bcc9 in the other thread. Here is the dsdt. I couldn't get natit to work in 10.5 only in SL. But on sleep it wont wake up.

Here's a modified dsdt for the 14z. All I've done is

• Added a DTGP method from a genuine macbook dsdt for inserting EFI strings from dsdt
  
• Added the same graphics EFI strings used in the 1340 to the _DSM method for the IGPU device
  

I didn't try fixing the LID to signal a sleep event because I didn't see a sleep button device in your dsdt (PNP0C0E).

14z.dsdt.zip

[westep23]

Just a update on 10.5 I can get video thru hdmi but the internal lcd goes black. It's wierd that on SL video works fine. I really havn't messed with 10.5 to much because I ordered a Dell 1515 wireless N. And it only works in SL. Opps, just saw your new dsdt trying now.

 

 

EDIT: bcc9 I love you. I tried all night to edit the dsdt to add video. SL working well. Try Leo in a minute.

 

Second EDIT: On Leo with the new dsdt hdmi work as primary display. Internal lcd does not show up at all. It's weird that SL works no problem. I'm pretty sure all we need is the correct nvcap because the 14z has internal lcd,display port, and hdmi. Where as the 1340 has internal lcd,vga,display port, and hdmi correct.

[bcc9]

Just a update on 10.5 I can get video thru hdmi but the internal lcd goes black. It's wierd that on SL video works fine. I really havn't messed with 10.5 to much because I ordered a Dell 1515 wireless N. And it only works in SL. Opps, just saw your new dsdt trying now.

 

 

EDIT: bcc9 I love you. I tried all night to edit the dsdt to add video. SL working well. Try Leo in a minute.

 

Second EDIT: On Leo with the new dsdt hdmi work as primary display. Internal lcd does not show up at all. It's weird that SL works no problem. I'm pretty sure all we need is the correct nvcap because the 14z has internal lcd,display port, and hdmi. Where as the 1340 has internal lcd,vga,display port, and hdmi correct.

Ok, great. Yes, definitely sounds like a simple NVCAP issue. The latest chameleon beta (r638) has code to extract the nvcap from the video bios, perhaps you could try the GraphicsEnabler feature to get the NVCAP out of the ioreg and then we could correct the NVCAP in the dsdt.

 

Ok, great. Yes, definitely sounds like a simple NVCAP issue. The latest chameleon beta (r638) has code to extract the nvcap from the video bios, perhaps you could try the GraphicsEnabler feature to get the NVCAP out of the ioreg and then we could correct the NVCAP in the dsdt.

And yes, that's a different # of ports on the 14z, so you could just try an NVCAP configured for 3 ports instead of 4. The 1340 nvcap:

05010000 00000100 0E000000 0000010b 00000000

with just 3 ports:

05010000 00000100 06000000 0000010b 00000000

and it looks like chameleon would generate:

04000000 00000100 06000000 0000000a 00000000

 

So try those later two

[GAOO]

Omg, thanks a ton bcc9, you are a life saver!!!

 

I will try those NVCAPs as soon as I can!

 

I really appreciate all your help and the time you've invested into all of this!!

 

 

Ok, great. Yes, definitely sounds like a simple NVCAP issue. The latest chameleon beta (r638) has code to extract the nvcap from the video bios, perhaps you could try the GraphicsEnabler feature to get the NVCAP out of the ioreg and then we could correct the NVCAP in the dsdt.

 

 

And yes, that's a different # of ports on the 14z, so you could just try an NVCAP configured for 3 ports instead of 4. The 1340 nvcap:

05010000 00000100 0E000000 0000010b 00000000

with just 3 ports:

05010000 00000100 06000000 0000010b 00000000

and it looks like chameleon would generate:

04000000 00000100 06000000 0000000a 00000000

 

So try those later two

[GAOO]

Unfortunately both of those NVCAPs didn't work for me

 

Do you mind explaining a little bit more details about using the GraphicsEnabler of Chameleon 2 to extract the NVCAP? I have Chameleon 2 installed already, but I can't find out any information on how to get the NVCAP via the GraphicsEnabler=y

 

Thanks a lot!

[bcc9]

Unfortunately both of those NVCAPs didn't work for me

 

Do you mind explaining a little bit more details about using the GraphicsEnabler of Chameleon 2 to extract the NVCAP? I have Chameleon 2 installed already, but I can't find out any information on how to get the NVCAP via the GraphicsEnabler=y

 

Thanks a lot!

Boot chameleon r638 with GraphicsEnabler=y

Once booted, try an ioreg -l -t -x -w100 | grep NVCAP

For me, GraphicsEnabler is not working at all but you may have better luck. If it works I think it'd just spit out the last NVCAP value I wrote above.

[GAOO]

Thanks again bcc9!

 

Unfortunately, the GraphicsEnabler does not work for me. I used GraphicsEnabler=Yes command and I saw that Chameleon reported "Unknown NVidia Device 256MB". Then I tried using your ioreg command but it produced no output, there's no NVCAP value in the ioreg output at all.

 

I saw that you had some success with NVEnabler (they still have yet to release the source..), so I decided to give it a go as well. All 3 probes that the NVEnabler tries to do fails, and it just boots an empty blue screen.

 

BTW, I did not mention this before, but early on (a week or so ago) when I was pretty sure there was something wrong with the NVCAP, I tried using NVFlash to dump the GPU's ROM so I can get the NVCAP. However, the lastest NVFlash 5.80 still does not support 9400M. So it seems like there's no way to get the genuine NVCAP...

 

 

Will continue trying some other kexts and random changes, hoping for the best :censored2: At this point, I'm not sure if there's anything else I can do anymore

 

 

Boot chameleon r638 with GraphicsEnabler=y

Once booted, try an ioreg -l -t -x -w100 | grep NVCAP

For me, GraphicsEnabler is not working at all but you may have better luck. If it works I think it'd just spit out the last NVCAP value I wrote above.

[bcc9]

I saw that you had some success with NVEnabler (they still have yet to release the source..), so I decided to give it a go as well. All 3 probes that the NVEnabler tries to do fails, and it just boots an empty blue screen.

That was the next thing I was going to suggest. Yes, it's not so useful without source. I believe it's just doing the exact same algorithm as natit with the addition of peeking at the bios to generate the nvcap just like chameleon.

BTW, I did not mention this before, but early on (a week or so ago) when I was pretty sure there was something wrong with the NVCAP, I tried using NVFlash to dump the GPU's ROM so I can get the NVCAP. However, the lastest NVFlash 5.80 still does not support 9400M. So it seems like there's no way to get the genuine NVCAP...

I did long ago roll my own program to extract the bios from the shadow copy, so that plus the chameleon code to look at the bios could give an answer.

 

But, it doesn't make much sense to me that your hardware is working fine under snow leopeard (and also what about the other user's report that natit was working, and westep23's report that under 10.5.x it's trying to use the hdmi port as the primary display? If the driver is simply using the wrong video port, then you should be able to just shuffle the bits for channel1&channel2 to change which port is used for channel1. With channel 1 at byte 6 of the NVCAP, and channel2 at byte 8, you've tried:

channel1, channel2:

01,0e # for a an nvidia card with 4 outputs

01,06 # for an nvidia card with 3 outputs

so now try:

02,05 # primary is second device

04,03 # primary is third device

08,07 # primary is fourth device

[GAOO]

Thanks for the suggestion bcc9. I'll try shuffling the bits around tonight, I don't have much confidence in it though. It seems too much of a mess.

 

I really wished HannibalX would clarify on his success with Natit, he hasn't replied back to my 2 messages. Anyhow, I was also thinking, since SL works, can't we just take the NVDAResman.kext and NV50Hal.kext from SL and use it in OSX 10.5.8? There may be compatibility issues of course, but it sounds like it's worth a try.

 

westep23, do you still have SL? Can you extract those 2 kexts and host it somewhere?

 

I really appreciate your help bcc9!

[bcc9]

Thanks for the suggestion bcc9. I'll try shuffling the bits around tonight, I don't have much confidence in it though. It seems too much of a mess.

Really. westep23 has it working in snow leopard and 10.5.x via an external monitor, so you're obviously just a bit or two away from fully working. Trying the different bit positions is how I got the 9400m working for 1340 users via all the different ports after all. Have you even tried an external monitor?

I really wished HannibalX would clarify on his success with Natit, he hasn't replied back to my 2 messages. Anyhow, I was also thinking, since SL works, can't we just take the NVDAResman.kext and NV50Hal.kext from SL and use it in OSX 10.5.8? There may be compatibility issues of course, but it sounds like it's worth a try.

I tried running applehda from 10.5.x under snow and it just crashes the system. I'd assume it's the same with other kexts. 10.6 supports 64 bit kexts so it's no surprise there would be compatibility issues. I can't believe you're suggesting that over the easier approach of grinding out the possible settings for NVCAP.

[GAOO]

Tried the bit changes you suggested, no differences, at least for the internal LCD. I don't have access to an external monitor to try out the bit changes at the moment.

 

Two week ago, I was also thinking that there is something wrong with the NVCAP, atleast for the channel 1 or channel 2 values. So I went to try it out on an external monitor about a week ago. I did get it to output onto the HDMI port (nothing still on the internal LCD of course), but it was extremely buggy. I saw on the console that there were tons of memory allocation error from the driver and there were garbage being rendered on the external screen as well (Expose was pretty much unusable). I also tried a few bit changes for the NVCAP value at that time, but there were no success as well.

 

Based on that, I didn't think the issue was because of the bits for the channel 1 and channel 2 of the NVCAP, but rather some other bits in the NVCAP or even problems with the driver. Of course, I could be wrong. But from the bit changes we're doing for Channel 1, doesn't it seem odd that I can't even get the LCD to display anything?? I mean 01, 02, 04, 08 uses all 4 bits of the last digit. Unless we're going for the upper digit of the channel 1 value now, but I don't recall it having any purpose.

 

I completely forgot SL is 64bits. Are all of the kexts for SL converted to 64bits already? I read that there are still some that are 32bits. If the graphics kexts are still 32 bits in SL, then perhaps we can try it before it gets rewritten into 64bits?

 

Anyhow, I'm stuck without much clues once again, I'll probably try out a few more bit changes tonight and pray it works.

 

Thanks for your help, bcc9.

 

Really. westep23 has it working in snow leopard and 10.5.x via an external monitor, so you're obviously just a bit or two away from fully working. Trying the different bit positions is how I got the 9400m working for 1340 users via all the different ports after all. Have you even tried an external monitor?

I tried running applehda from 10.5.x under snow and it just crashes the system. I'd assume it's the same with other kexts. 10.6 supports 64 bit kexts so it's no surprise there would be compatibility issues. I can't believe you're suggesting that over the easier approach of grinding out the possible settings for NVCAP.

[westep23]

Yes I agree with bcc9, SL can run in 32bit mode also. I'm actually running in 32bit mode due to 32bit airport kext. Anyways I may try them in Leo, but the airport kext wouldn't even load in leo. No errors, no output of any kind from kextload cmd. I also think we need to get the nvcap figured out because when SL goes final the video kext maybe not so forgiving.

[HannibalX]

Hey all -

 

Sorry, I've been out of town - and haven't had a chance to really check in here.

 

I'm still using the natit.kext that bcc9 posted, I haven't had a chance to test his DSDT method yet.

 

Here is the output in the system.log from when the natit.kext loads:

 

Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @0,name=NVDA,Display-A
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,compatible=NVDA,NVMac
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,device_type=display
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,name=NVDA,Display-B
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting NVCAP=<data not shown>
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting device_type=NVDA,Parent
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting model=NVIDIA Geforce 9400M

 

I'm not certain if that is helpful or not.

 

Also, here is the lspci data for my video card:

 

04:00.0 VGA compatible controller: nVidia Corporation Device 0866 (rev b1) (prog-if 00 [VGA controller])
Subsystem: Dell Device 02ba
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at cc000000 (32-bit, non-prefetchable)
Region 1: Memory at d0000000 (64-bit, prefetchable)
Region 3: Memory at ce000000 (64-bit, prefetchable)
Region 5: I/O ports at 4000
Capabilities: [60] Power Management version 2
	Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
	Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
	Address: 00000000fee00000  Data: 4094

 

As I mentioned to GA00, I'm running a vanilla install. I copied the retail OSX 10.5.6 DVD to a 8GB USB stick (see this thread). I'm also using the latest Chameleon RC2 installed using the munky method (see this thread but use the Chameleon files instead).

 

Here is a list of the kexts that I have in my EFI partition:

 

drwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IO80211Family.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 21:12 IOAudioFamily.kext
drwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IONetworkingFamily.kext
drwxr-xr-x   3 root  wheel   102B Jul 24 14:19 IntelCPUPMDisabler.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 13:16 Natit.kext
drwxr-xr-x   3 root  wheel   102B Aug  4 16:52 OSvKernDSPLib.kext
drwxr-xr-x   3 root  wheel   102B Apr  6 20:25 VoodooBattery.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 21:11 VoodooHDA.kext
drwxr-xr-x   3 root  wheel   102B May  8 23:51 VoodooPS2Controller.kext
drwxr-xr-x   3 root  wheel   102B Aug  4 22:38 VoodooPower.kext
drwxr-xr-x   3 root  wheel   102B Jul 24 14:19 dsmos.kext

 

VoodooHDA is *NOT* working, I get sound and everything - but I have the horrible static. The IO80211Family.kext was editted to add my device id for my wireless card. (IONetworkFamily is added because it's a dependency). I want to try the DSDT method instead, so I don't have to edit the kext. My onboard ethernet is not working, I get this error:

 

ug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: Unknown hardware version ID (28000000)
Aug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: probeHardware() failed

 

I know it will work, I had it working when I originally used the netbookinstaller to prepare my USB stick (this was prior to using the above linked method with Chameleon). I think it might be something that can be tweaked via DSDT as well.

 

I hope that helps some, I haven't had a chance to do much with it lately. As a side comment, I am using a GPT disk -- and dual booting Windows 7 and OSX with Chameleon as the bootloader.

 

It doesn't contain much, but here is my com.apple.Boot.plist:

 

?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string></string>
<key>Default Partition</key>
<string>hd(0,3)</string>
<key>Timeout</key>
<string>5</string>
<key>Graphics Mode</key>
<string>1600x900x32</string>
<key>Legacy Logo</key>
<string>yes</string>
<key>device-properties</key>
<string></string>
</dict>
</plist>

[GAOO]

Thank you very much for your informative post, HannibalX. I was worried you may have abandoned us

 

I was looking at your list of kexts, and there's two I'm not familiar with:

- IntelCPUPMDisabler.kext

- OSvKernDSPLib.kext

 

The other kexts doesn't seem like they will affect the Graphcis at all. But I'm not so sure about these two. I'll be looking into them and trying them out with Natit.

 

I also inspected your Boot.plist, and nothing seems out of the ordinary, except for:

<key>Graphics Mode</key>

<string>1600x900x32</string>

 

What happens when you don't have the Graphics Mode key? Also, do you have Quartz Extreme and Core Image working? I would like to assume you do since you said Natit works, but it would be nice to confirm it.

 

 

BTW, I am also using GPT and retail disk, but I do not think it is necessary to get the Graphics working. A near vanilla install (such as with iATKOS) should be compatible as well in my opinion.

 

 

 

Hey all -

 

Sorry, I've been out of town - and haven't had a chance to really check in here.

 

I'm still using the natit.kext that bcc9 posted, I haven't had a chance to test his DSDT method yet.

 

Here is the output in the system.log from when the natit.kext loads:

 

Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @0,name=NVDA,Display-A
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,compatible=NVDA,NVMac
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,device_type=display
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,name=NVDA,Display-B
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting NVCAP=<data not shown>
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting device_type=NVDA,Parent
Aug 12 16:42:12 localhost kernel[0]: Natit: Setting model=NVIDIA Geforce 9400M

 

I'm not certain if that is helpful or not.

 

Also, here is the lspci data for my video card:

 

04:00.0 VGA compatible controller: nVidia Corporation Device 0866 (rev b1) (prog-if 00 [VGA controller])
Subsystem: Dell Device 02ba
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at cc000000 (32-bit, non-prefetchable)
Region 1: Memory at d0000000 (64-bit, prefetchable)
Region 3: Memory at ce000000 (64-bit, prefetchable)
Region 5: I/O ports at 4000
Capabilities: [60] Power Management version 2
	Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
	Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
	Address: 00000000fee00000  Data: 4094

 

As I mentioned to GA00, I'm running a vanilla install. I copied the retail OSX 10.5.6 DVD to a 8GB USB stick (see this thread). I'm also using the latest Chameleon RC2 installed using the munky method (see this thread but use the Chameleon files instead).

 

Here is a list of the kexts that I have in my EFI partition:

 

drwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IO80211Family.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 21:12 IOAudioFamily.kext
drwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IONetworkingFamily.kext
drwxr-xr-x   3 root  wheel   102B Jul 24 14:19 IntelCPUPMDisabler.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 13:16 Natit.kext
drwxr-xr-x   3 root  wheel   102B Aug  4 16:52 OSvKernDSPLib.kext
drwxr-xr-x   3 root  wheel   102B Apr  6 20:25 VoodooBattery.kext
drwxr-xr-x   3 root  wheel   102B Aug  3 21:11 VoodooHDA.kext
drwxr-xr-x   3 root  wheel   102B May  8 23:51 VoodooPS2Controller.kext
drwxr-xr-x   3 root  wheel   102B Aug  4 22:38 VoodooPower.kext
drwxr-xr-x   3 root  wheel   102B Jul 24 14:19 dsmos.kext

 

VoodooHDA is *NOT* working, I get sound and everything - but I have the horrible static. The IO80211Family.kext was editted to add my device id for my wireless card. (IONetworkFamily is added because it's a dependency). I want to try the DSDT method instead, so I don't have to edit the kext. My onboard ethernet is not working, I get this error:

 

ug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: Unknown hardware version ID (28000000)
Aug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: probeHardware() failed

 

I know it will work, I had it working when I originally used the netbookinstaller to prepare my USB stick (this was prior to using the above linked method with Chameleon). I think it might be something that can be tweaked via DSDT as well.

 

I hope that helps some, I haven't had a chance to do much with it lately. As a side comment, I am using a GPT disk -- and dual booting Windows 7 and OSX with Chameleon as the bootloader.

 

It doesn't contain much, but here is my com.apple.Boot.plist:

 

?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string></string>
<key>Default Partition</key>
<string>hd(0,3)</string>
<key>Timeout</key>
<string>5</string>
<key>Graphics Mode</key>
<string>1600x900x32</string>
<key>Legacy Logo</key>
<string>yes</string>
<key>device-properties</key>
<string></string>
</dict>
</plist>

[GAOO]

Found that IntelCPUPMDisabler.kext works just like Disabler.kext, and OSvKernDSPLib.kext is needed for one of the other Audio drivers. So other than Natit.kext, nothing else affects graphics.

 

So far, other than HannibalX, everyone else seems to have the 720p LCD, which has the resolution of 1366x768. HannibalX got Natit.kext working with his 900p LCD, while everyone else with 720p didn't, so could it be that the Natit.kext or its NVCAP requires some tweaking to work with the 720p screen?

 

Well this is also assuming that Natit.kext works perfectly fine for HannibalX (QE&CIworks & doesn't rely on Graphics Mode). Otherwise it may not have to with 720p or 900p...

 

 

Thank you very much for your informative post, HannibalX. I was worried you may have abandoned us

 

I was looking at your list of kexts, and there's two I'm not familiar with:

- IntelCPUPMDisabler.kext

- OSvKernDSPLib.kext

 

The other kexts doesn't seem like they will affect the Graphcis at all. But I'm not so sure about these two. I'll be looking into them and trying them out with Natit.

 

I also inspected your Boot.plist, and nothing seems out of the ordinary, except for:

<key>Graphics Mode</key>

<string>1600x900x32</string>

 

What happens when you don't have the Graphics Mode key? Also, do you have Quartz Extreme and Core Image working? I would like to assume you do since you said Natit works, but it would be nice to confirm it.

 

 

BTW, I am also using GPT and retail disk, but I do not think it is necessary to get the Graphics working. A near vanilla install (such as with iATKOS) should be compatible as well in my opinion.

[HannibalX]

Found that IntelCPUPMDisabler.kext works just like Disabler.kext, and OSvKernDSPLib.kext is needed for one of the other Audio drivers. So other than Natit.kext, nothing else affects graphics.

 

So far, other than HannibalX, everyone else seems to have the 720p LCD, which has the resolution of 1366x768. HannibalX got Natit.kext working with his 900p LCD, while everyone else with 720p didn't, so could it be that the Natit.kext or its NVCAP requires some tweaking to work with the 720p screen?

 

Well this is also assuming that Natit.kext works perfectly fine for HannibalX (QE&CIworks & doesn't rely on Graphics Mode). Otherwise it may not have to with 720p or 900p...

 

Yes, IntelCPUPMDisabler.kext is similar to Disabler.kext. OSvKernDSPLib.kext and IOAudioFamily.kext are stock, but they are pre-requisites for getting VoodooHDA.kext to load out of the EFI partition.

 

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

 

Have you tried generating an EFI String for your graphics card? Obviously, it won't get QE/CI working -- but it would at least display native resolution -- and it might lead you further down the road to getting it fully working.

 

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

[GAOO]

I wasn't quite saying that iATKOS is vanilla. But iATKOS is close to it, and I think that if I can get the graphics driver working for the Boot132+retail disk+Chameleon, then iATKOS may work as well.

 

In any case, if Natit.kext required no changes on your end to get it working, then I think it is most likely something with the LCD screen.. which is extremely odd. Are you sure you didn't touch any of the other drivers, like NVDAResman or the NV50HAL?

 

Not quite sure how to proceed at this point anymore.. BTW, does Natit still work in 10.5.7 or 8 for you HannibalX?

 

 

Yes, IntelCPUPMDisabler.kext is similar to Disabler.kext. OSvKernDSPLib.kext and IOAudioFamily.kext are stock, but they are pre-requisites for getting VoodooHDA.kext to load out of the EFI partition.

 

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

 

Have you tried generating an EFI String for your graphics card? Obviously, it won't get QE/CI working -- but it would at least display native resolution -- and it might lead you further down the road to getting it fully working.

 

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

[bcc9]

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

By having chameleon switch graphics mode on you a few times before the nvidia drivers try to load you may have put your card into a different state than everyone else that's having trouble with 10.5.x on the built-in display. The built-in may simply be in the wrong mode for everyone else. I'd certainly try your different mode (with my original nvcap) if I was the one having problems.

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

And you guys might want to compare versions of the nvidia kexts that you have (among others). There were multiple versions of the nvidia kexts floating around in the 10.5.6 timeframe.