Jump to content

Dell Precision 470 / 670 workstation - Snow Leopard/Lion/Mountain Lion/Mavericks/Yosemite


Hervé

Recommended Posts

  • Administrators

Dell_WS670.png          Precision_670.png
 
Now, that's a bit of a relic of the past (released in 2004!), but it was a powerful beast in its days! Building on previous unfinished ModCD SL installation back in 2011, I've (again) put Snow Leopard 10.6.8 on my Precision 670 workstation.
 
Specifications:

  • BIOS A07
  • Intel E7525 chipset (ICH5R, PCIe v1.0a, PCI v2.3, PCI-X v1.0b, SATA 1.0, Ultra ATA/100, USB2.0)
  • 2 x 64bit single-core Irwindale Xeon @3.8GHz FSB-800MHz then replaced with 2 x dual-core Paxville DP Xeon @2.8GHz
  • 4Go DDR2-400 ECC registered RAM
  • nVidia Quadro FX1400 128MB with dual DVI-I outputs, hooked to 2 x 1280x1024 19" LCDs (ven id 0x10de, dev id 0x00ce)
  • nVidia GeForce 9800 GT 512MB with dual DVI-I outputs hooked to 2 x 1280x1024 19" LCDs (ven id 0x10de, dev id 0x0614)
  • integrated Adaptec Ultra320 SCSI RAID controller (ven id 0x9005, dev id 0x808f)
  • integrated Ultra ATA (ICH5 SATA-I) + EIDE controller (ven id 0x8086, dev id 0x24d1 + 0x24db)
  • 1 x 320Go SATA-I + 1 x 160Go 10k SCSI HDDs + 1 x 40Go IDE HDDs
  • integrated Intel Pro/1000 MT Gigabit Ethernet (ven id 0x8086, dev id 0x1026)
  • integrated Intel 82801EB AC'97 SoundMax (codec: ADI AD1981B ?) audio controller (ven id 0x8086, dev id 0x24d5)
  • USB 2.0 + Firewire ports

These old Xeon CPUs, although SSE3 capable, appear incompatible with the vanilla kernel. As such, installation was started with retail SL 10.6.3 + legacy kernel Darwin 10.4.0 as per ModCD (knowing that Nawcom's legacy kernel numbering follows SL mach kernel numbering: for instance 10.7.0 for SL 10.6.7 or 10.8.0 for SL 10.6.8 - don't try to install SL 10.6.3 with Darwin 10.8.0, that will not work).
 
I first tried Nawcom's ModCD method and got SL 10.6.3 installed without problem. Even the audio worked OOB. I then tried myHack installation with generic Extra and also installed SL 10.6.3 without problems. I now need to finalise update to 10.6.8 with that 2nd installation.
 
With legacy kernel, both CPUs are seen and with their multithread capabilites. System boots 64bit kernel OOB.

Link to comment
Share on other sites

  • Administrators

Small update with progress to date...

 

Working:

  • MyHack (& ModCD/ModUSB) installation of SL 10.6.3 + combo update to 10.6.8
  • IDE & SATA controller (with IOATAFamily kext containing ICH5-capable AppleIntelPIIXATA plugin)
  • audio (with AppleAudioAC97 kext)
  • 32 & 64bit kernel mode with ModCD/ModUSB installation
  • various legacy kernels (from Darwin 10.4.0 to 10.8.0 v2)
  • full CPUs detection (2 CPUs, 2 threads if/with 2nd CPU + Hyperthreading are enabled in BIOS)
  • native CPU power management (no NullCPUPowerManagement kext)
  • restart & shutdown

 

Not working:

  • audio in 64bit kernel mode (would-be 64bit AC'97 kext does not appear to work in 64bit kernel mode)
  • built-in Adaptec AIC-7901 Ultra320 SCSI adapter is not recognised/detected at all (haven't found a kext for it)
  • nVidia FX1400 support (I can only force resolution through Cham boot plist, no acceleration or FrameBuffer support)

With myHack installation, the Precision 670 does not appear to support NullCPUPowerManagement + PState kexts (it accepts default NullCPUPowerManagement with ModCD installation though). NullCPUPowerManagement resets the computer during startup and causes boot loop and PState will render it unbootable. This could be due to the fact that the Xeon Irwindale CPUs are of an unsupported/unknown type for Chameleon, I'm not sure.

 

Keeping this in mind, updating from 10.6.3 to 10.6.8 works OOB.

 

For some reason, I cannot get the nVidia Quadro FX1400 to work properly. I've used a Chameleon bootloader that supports the card and I've patched the GeForce + NVdaNV40Hal + NVdaResMan kexts to include the card device id (0x00ce), but that remains unsuccessful. More work to be done on that, or that card will have to go (well, I have a spare ATI Radeon Pro X1300 that I now know to be fully supported in SL).

 

I more or less achieve identical results installing through Nawcom's ModCD/ModUSB or myHack + Generic /Extra. I can update both installations to 10.6.8 without issue but, contrary to its ModCD/ModUSB's counterpart, the myHack installation cannot boot in 64bit kernel mode for some unknown reason.

Link to comment
Share on other sites

  • Administrators

After some trials, obtained full QE/CI + dual-screen with a Twintech-branded nVidia GeForce 9800GT (512MB DDR3, 2 x DVI + 1 x S-Video). Got the card to work with NVEnabler_64 kext, the rest being vanilla/standard (i.e. no patching of any nVidia kexts whatsoever). Works in 32bit and 64bit kernel mode.

 

Ge9800GT_QE:CI_64bit.jpg

nVidia_9800GT_dual-DVI.jpg

Link to comment
Share on other sites

  • Administrators

I've been playing with DSDT patching these last few days and decided to try and get rid of the NVenabler64 graphics enabler kext used for the nVidia 9800 GT; that meant a DSDT patch of course. I first extracted the DSDT through Chameleon Wizard since I was not using any patched one. Then, I checked PCI devices in IORegistryExplorer and found the nVidia card to be located at PCI5@4, under PCI3.

 

I therefore patched the DSDT as follows:

. under _WAK method, I added:
   Method (DTGP, 5, NotSerialized)
    {
        If (LEqual (Arg0, Buffer (0x10)
                {
                    /* 0000 */ 0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
                    /* 0008 */ 0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
                }))
        {
            If (LEqual (Arg1, One))
            {
                If (LEqual (Arg2, Zero))
                {
                    Store (Buffer (One)
                        {
                            0x03
                        }, Arg4)
                    Return (One)
                }
                If (LEqual (Arg2, One))
                {
                    Return (One)
                }
            }
        }
        Store (Buffer (One)
            {
                0x00
            }, Arg4)
        Return (Zero)
    }

. within PCI5 device, under Method (_ADR, 0, NotSerialized) { [...] Store (0x00040000, Local0) [...] } section, using info from the IORegistry extract, I added:

                Device (GFX0)
                {
                    Name (_ADR, Zero)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x1A)
                            {
                                "AAPL,slot-name", 
                                "PCIe x16", 
                                "@0,compatible", 
                                Buffer (0x0B)
                                {
                                    "NVDA,NVMac"
                                }, 
                                "@0,connector-type", 
                                Buffer (0x04)
                                {
                                     0x00, 0x08, 0x00, 0x00
                                }, 
                                "@0,device_type", 
                                Buffer (0x08)
                                {
                                    "display"
                                }, 
                                "@0,name", 
                                Buffer (0x0F)
                                {
                                    "NVDA,Display-A"
                                }, 
                                "@1,compatible", 
                                Buffer (0x0B)
                                {
                                    "NVDA,NVMac"
                                }, 
                                "@1,connector-type", 
                                Buffer (0x04)
                                {
                                     0x00, 0x08, 0x00, 0x00
                                }, 
                                "@1,device_type", 
                                Buffer (0x08)
                                {
                                    "display"
                                }, 
                                "@1,name", 
                                Buffer (0x0F)
                                {
                                    "NVDA,Display-B"
                                }, 
                                "NVCAP", 
                                Buffer (0x14)
                                {
                                    /* 0000 */   0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00,
                                    /* 0008 */   0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A,
                                    /* 0010 */   0x00, 0x00, 0x00, 0x00
                                }, 
                                "VRAM,totalsize", 
                                Buffer (0x04)
                                {
                                     0x00, 0x00, 0x00, 0x20
                                }, 
                                "device_type", 
                                Buffer (0x0C)
                                {
                                    "NVDA,Parent"
                                }, 
                                "model", 
                                Buffer (0x17)
                                {
                                    "nVidia GeForce 9800 GT"
                                }
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                }

Note that most of this derives from RampageDev's excellent blog page on graphics cards DSDT injection. Thank you Andrew!

 

After removing the enabler kext and re-running myFix (quick), I rebooted but system remained without QE/CI, as if graphics card DSDT injection was ineffective. On checking the IOreg a little deeper, I found the system to have a PCI root level I was not expecting... 

Mac-Pro:~ admin$ ioreg -l | grep -15 "AppleACPIPCI\ " | grep UID
Result -->    | | |   "_UID" = "4"

 

Rebooting with boot option PciRoot=4 subsequently resolved the graphics card DSDT injection issue and got me full QE/CI! The Chameleon boot plist was therefore amended to that effect.

 

Whilst on the Precision 670, I also searched deeper into the Ethernet port issue (seen and recognized, but always down with "Cable disconnected"). I finally found an old universal 32bit (PPC & i386) AppleIntel8254XEthernet kext on the Net and it proved to fix the issue! Yeeha! That old kext is v1.1.2 and possibly from Tiger but that's not important. It made the LAN port work, that's important!

WS670_Ethernet.jpg WS670_MAC@.jpg WS670_ifconfig.jpg

 

I also patched the DSDT to be able to show the Ethernet port + Firewire in the System Profiler->PCI cards section by adding the following sections derived from an IOReg scan.

 

.For Intel Pro/1000MT NIC, within PCI3 device, I added:

                    Device (LAN0)
                    {
                        Name (_ADR, 0x000E0000)
                        Method (_DSM, 4, NotSerialized)
                        {
                            Store (Package (0x0C)
                                {
                                    "AAPL,slot-name", 
                                    Buffer (0x09)
                                    {
                                        "Internal"
                                    }, 
                                    "class-code", 
                                    Buffer (0x04)
                                    {
                                         0x00, 0x00, 0x02, 0x00
                                    }, 
                                    "name", 
                                    Buffer (0x17)
                                    {
                                        "10/100/1000BT Ethernet"
                                    }, 
                                    "model", 
                                    Buffer (0x1A)
                                    {
                                        "Intel Pro/1000MT Ethernet"
                                    }, 
                                    "device-id", 
                                    Buffer (0x04)
                                    {
                                         0x26, 0x10, 0x00, 0x00
                                    }, 
                                    "vendor-id", 
                                    Buffer (0x04)
                                    {
                                         0x86, 0x80, 0x00, 0x00
                                    }
                                }, Local0)
                            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                            Return (Local0)
                        }
                    }

. For Firewire, within PCI6 device, I added:

                Bad idea - all removed!

SystemProfile_PCIcards.jpg

 

---------

EDIT - 15Jan2014:

Modifying DSDT code for Firewire is actually a very bad idea because, as stated by RampageDev, it breaks Sleep! As such, Firewire patch was totally removed.

Link to comment
Share on other sites

  • Administrators

I made some additional DSDT edits for the (unsupported) built-in Adaptec SCSI controller + AC'97 audio.
 
. For Adaptec Ultra-320 adapter, within PCI2, I added:

                    Device (SCSI)
                    {
                        Name (_ADR, 0x000E0000)
                        Method (_DSM, 4, NotSerialized)
                        {
                            Store (Package (0x0C)
                                {
                                    "AAPL,slot-name", 
                                    Buffer (0x09)
                                    {
                                        "Internal"
                                    }, 
                                    "class-code", 
                                    Buffer (0x04)
                                    {
                                         0x00, 0x04, 0x01, 0x00
                                    }, 
                                    "model", 
                                    Buffer (0x2A)
                                    {
                                        "Adaptec AIC-7901 Ultra320 SCSI Controller"
                                    }, 
                                    "name", 
                                    Buffer (0x15)
                                    {
                                        "RAID SCSI Controller"
                                    }, 
                                    "device-id", 
                                    Buffer (0x04)
                                    {
                                         0x8F, 0x80, 0x00, 0x00
                                    }, 
                                    "vendor-id", 
                                    Buffer (0x04)
                                    {
                                         0x05, 0x90, 0x00, 0x00
                                    }
                                }, Local0)
                            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                            Return (Local0)
                        }
                    }

. For AC'97 audio, within PCI0, I added:

            Device (HDEF)
            {
                Name (_ADR, 0x001F0005)
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x10)
                    {
                        "AAPL,slot-name",
                        Buffer (0x09)
                        {
                            "Internal"
                        },
                        "class-code", 
                        Buffer (0x04)
                        {
                            0x00, 0x01, 0x04, 0x00
                        },
                        "codec-id",
                        Buffer (0x04)
                        {
                            0x74, 0x53, 0x44, 0x41 /* ADS74 */
                        },
                        "built-in",
                        Buffer (One)
                        {
                            0x00
                        },
                        "name", 
                        Buffer (0x11)
                        {
                            "Audio Controller"
                        }, 
                        "model", 
                        Buffer (0x21)
                        {
                            "AC'97 (AD1981B) Audio Controller"
                        }, 
                        "device-id", 
                        Buffer (0x04)
                        {
                            0xd5, 0x24, 0x00, 0x00
                        }, 
                        "vendor-id", 
                        Buffer (0x04)
                        {
                             0x86, 0x80, 0x00, 0x00
                        }
                    }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }

This is all cosmetic, but I like it...  :)

WS670_revisedSysProfiler.jpg

Link to comment
Share on other sites

  • Administrators

The need to set PCI root to 4 can be avoided by patching the DSDT so that PCI root is set to 0 by default. This is done by changing PCI0 _UID from 4 to 0 as shown below.

-> Before:

       Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, 0x04) /* old default UID */
            Name (_ADR, Zero)
-> After:
        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, Zero) /* new modified UID */
            Name (_ADR, Zero)

System can then be used with default PCI root UID (0) without any adverse effects.

Link to comment
Share on other sites

  • Administrators

Thanks to RampageDev & Bronxteck's help, final DSDT patching was made to support Sleep & Wake functionalities, the only outstanding matters that remained on my Precision 670.

 

The cosmetic patch made previously for Device (FRWR) had to be entirely removed (editing Firewire DSDT entry breaks sleep) and the following code added to each USB device (from USB0 to USB3):

            Method (_DSM, 4, NotSerialized)
            {
                Store (Package (0x0B)
                    {
                        "AAPL,clock-id", 
                        Buffer (One)
                        {
                             0x01
                        }, 
                        "device_type", 
                        Buffer (0x05)
                        {
                            "USBn" /* where n=0 to 3 */
                        }, 
                        "AAPL,current-available", 
                        0x04B0, 
                        "AAPL,current-extra", 
                        0x02BC, 
                        "AAPL,current-in-sleep", 
                        0x03E8, 
                        Buffer (One)
                        {
                             0x00
                        }
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }

In addition to the DSDT patch, it turns out that SleepEnabler kext is also required to support sleep. SleepEnabler caused issues in the past when I was experimenting with installation, so it's probably best to add it as a post-install item during fine-tuning phase, not at initial installation phase. With SleepEnabler kext added to /E/E as a last item and installed through myFix (quick), everything now works 100% and without any problems.

 

So, as a final recap:

Working:

  • MyHack installation (in my case installation of retail SL 10.6.3 + combo update to 10.6.8) with Nawcom's legacy kernels (tested with 10.3.0-10.8.0 v2)
  • 32 & 64bit kernel modes
  • IDE & SATA controller (with IOATAFamily kext containing ICH5-capable AppleIntelPIIXATA plugin)
  • audio in 32bit kernel mode only (with AppleAudioAC97 kext - :excl: may cause KP in 64bit kernel mode)
  • built-in LAN in 32bit kernel mode only (with old PPC/x86 AppleIntel8254XEthernet kext)
  • USB & Firewire
  • full Nocona/Irwindale CPUs detection (2 CPUs, 2 threads if/with 2nd CPU + Hyperthreading are enabled in BIOS)
  • native CPU power management (native speedstep appears supported with Kozlek's recent FakeSMC kext)
  • restart & shutdown (CMOS reset avoided through DSDT Patch or usual RTC fix kexts)
  • sleep & wake (with DSDT patch & SleepEnabler kext)
  • Full QE/CI graphics acceleration with the right graphics card and all eventual kext + DSDT patches (for instance: ATI Radeon Pro X1300/X1550, nVidia GeForce G210, nVidia GeForce 9800GT)

 

Not working:

  • AC97 audio in 64bit kernel mode -> corrupted audio
  • unsupported built-in Adaptec AIC-7901 Ultra320 SCSI adapter
 
Below are the revised packs, IOReg output and extracted/patched DSDT tables:
Link to comment
Share on other sites

  • Administrators

A behaviour change with recent Chameleon trunk versions (post r2290) highlighted a small defect in the boot plist settings provided in above pack and the kernel handling. I have set boot option UseKernelCache to Yes and refer specifically to the legacy kernel, not to standard/vanilla mach kernel.
 
This leads to the generation of an incorrect kernel cache as, by default, cache is built with vanilla mach_kernel. Leaving such kernel unchanged at root level therefore leads to a kernel cache that is incompatible with legacy kernel and which causes a system reset/boot loop when loaded, unless the cache is built with option -K (or -kernel ...). This was not an issue up to Chameleon r229x because these versions would ignore kernel cache when non-standard mach kernels were used. I've come to realise this changed with post r229x Chameleon trunk versions and kernel cache will be loaded whatever the kernel.

 
To fix this, proceed as follows:

  • at HDD root level, rename vanilla mach_kernel file to something else such as mach_kernel_bak (or remove entirely)
  • at HDD root level, rename legacy kernel Darwin_10.8.0 (or whatever name the legacy kernel bears) to mach_kernel
  • using Chameleon Wizard, uncheck Kernel case in the boot plist or replace the named Darwin kernel by mach_kernel

The result is that kernel cache will no longer be built on original/vanilla mach kernel but actually on the now-renamed legacy kernel. Any cache refresh/rebuild made manually, through myHack or any other tool will subsequently be totally safe to load.

 

Oh, I've never mentioned this but boot time from the moment bootloader kicks in to desktop is about 30s and shutdown/restart nearly-instantaneous at about 2-3s. Good old Snow Leopard! It's the most stable Hack I've ever had so far.

Link to comment
Share on other sites

  • Administrators

I was given 2 x dual-core Xeon DP 2.8GHz (SL8MA Paxville DP, suitable for XC837 or XC838 motherboards only), so I tried them last night. No problem to report and performance naturally increased a little despite significant frequency drop compared to the single-core Irwindale Xeon 3.8GHz CPUs I previously had. GeekBench (32bit) reported a 20% improvement on resulting index and, with HyperThreading enabled in BIOS, OS X does report a total of 8 cores on the system :). These dual-core Paxville Xeon CPU are reported as Core2Duo CPUs but, unfortunately, remain incompatible with Snow Leopard vanilla kernel; as such, modified/AMD kernels prevail...

 

WS670_Dual-Paxville-DP-2.8GHz.jpg

WS670_dual-Paxville-DP_GB32.jpg

 

I'll have to see if Lion or newer OS X versions can be installed now...

Link to comment
Share on other sites

  • Administrators

With Paxville dual-core Xeon in place, I was able to install Lion with myHack using Bronya's RC13 AMD kernel + boot pack from my previous SL installation. I installed Lion 10.7.2 with myHack v3.1.2 + 10.7.5 Combo update. System seems to have an issue with native power management, so I had to revert to NullCPUPowerManagement to stabilize things. Other than that, everything seems to be working well, except Sleep (probably needs Lion-specific SleepEnabler kext). Running in 32bit mode to retain Intel LAN + AC'97 audio support.

 

WS670_Lion.jpg

 

WS670_Lion_pack.zip Bronya_10.7_kernel_RC13.zip

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...