Hervé

We would not be suggesting to do so otherwise...

There are only 2 x models of FSB800 T9xxx...

It's always been possible to boot OS X off an external HDD (unlike Windows). But with El Capitan onwards, you have to make sure all your USB ports are operational since Apple modified USB ports management in EC and beyond. Hence the frequent requirements to patch DSDT and rename EHCx devices (USB2.0 controllers) to EH0x devices; this is then followed by the use of a USBInjector kexts to declare all USB ports under the SMBIOS profile used on the computer.

Runs decently if you have a T9xxx but it's no F1 car of course...

Your pack is missing the org.chameleon.Boot.plist... NB: Can you confirm you're actually using the D630 nVidia's DSDT?

Please post your full zipped EFI folder.

I confirm that Conroe E6600 bears no SSE4 instructions sets and, indeed, GeForce GT610 was reported unsupported by several users.

Last edited: 19 Aug 2019 For those who would still encounter issues with CMOS writes and subsequent BIOS resets or long BIOS POST at reboot, the attached pre-patched AppleRTC kexts should cure things. As indicated at InsanelyMac and other places, the patch consists of the following binary modification of the kext binary file: Find: 75 2E 0F B6 Replace by: EB 2E 0F B6 From Mavericks 10.9 to Mojave 10.14, AppleRTC shows a version v2.0. The patched kext can be used "as is" and, because version is up'ed to 92.0, will take precedence over the vanilla kext once placed in /S/L/E, in /L/E or injected through the bootloader from /E/E/ or E/C/k/10.x or E/C/k/Other folders. Patched_10.9_AppleRTC.kext.zip Patched_10.10_AppleRTC.kext.zip Patched_10.11_AppleRTC.kext.zip Patched_10.12_AppleRTC.kext.zip Patched_10.13_AppleRTC.kext.zip Patched_AppleRTC_10.14.3.kext.zip

You'll need to post the identified specs of your hardware so that we can point you towards all necessary kexts. So please list exact model for CPU, graphics, LAN, audio, wireless, SD card reader, etc.

Use the patch detailed in Jake's config.plist for the E6x20. Failing that, I'll send you the pre-patched AppleHDA + IDT 92HD90 definition kext.

NEVER place kexts in EFI/Clover/kext/xxx AND in SLE or LE. Only ever use 1 x single copy of kexts. There are no specific add-on kexts for the Intel chipset, Apple OS already fully supports it since it's used in their own Mac models.

Assuming you have ALC292 patched AppleHDA working, HDMI audio requires DSDT HDAU device + patching of Azul Framebuffer kext as explained here: Find: 01050900 00040000 87000000 Replace by: 01051200 00080000 87000000 ` All this under layout-id 0600260a. More details here.

You can re-use the same kexts you used for Mavericks but I'll make a few comments: Patched_10.7_AppleRTC is obsolete beyond Lion. If you need to patch Mav/Yos/EC/Sierra's AppleRTC kext (all v2.0) because you experience CMOS resets or long BIOS POST at reboot due to CMOS writes, you can patch the vanilla AppleRTC kext as follows: Find: 75 2E 0F B6 Replace by: EB 2E 0F B6 If you can't patch the kext yourself, we can post the modded version. Note that the patched kext can go to /Library/Extensions whilst retaining the vanilla version untouched in /S/L/E. Only the patched kext will load. If you retain NullCPUPowerManagement, you'll have no native CPU speedstep, which is highly undesirable. If you have a C2D or C2Q CPU, you can get native CPU SpeedStep through a combination of FakeSMC tuning + appropriate SMBIOS profile. You can remove the reference to kernelHasswell (should single "s") if you don't have a Haswell CPU/platform. Only use KernelBooter_kexts=Yes if you want to inject kexts placed in /Extra/Extensions. You should copy your add-on kexts there anyway, in case you need to boot without cache since that ignores kexts placed in /L/E. You will need to add boot option CsrActiveConfig to the org.Chameleon.boot.plist and set the value to, say, 3. It's mandatory to disable SIP and load your add-on kexts priot to building the cache. In case you don't already know this, Sierra requires a CPU with SSE4 instructions set. You have not provided your XPS210 specs but if your CPU does not meet that key criteria, you'll be limited to El Capitan until you upgrade your CPU to a SSE4-capable model. I know XPS210 could be fitted with Allendale models (eg: C2D E4500) and these won't do.

There were 2 x VoodooSDHC kext implementations: one with dma, one without. I guess Griftopia should try them both. From memory, they're still available on the Voodoo web site, failing that Google is our friend as usual...

Use the Dr Hurt's final driver from updated p1 of the thread. For audio, you should use patched AppleHDA instead of VoodooHDA Do you use VoodooSDHC kext at all for the SD card reader? If so, that'll explain the issues on wake. Get rid of the kext and patch your DSDT instead as the card reader can work OOB if DSDT device is defined as compatible with Apple's default device. You can search for this on the forum.

attachements need to be zipped.

Last update: 20 July 2017 For those who need an extracted copy of Sierra kernels to build their manual Chameleon/Enoch-based USB installers, here are copies of the various kernels that have come out so far. I also include copies of the patched AppleIntelCPUPowerManagement kexts that are necessary on SandyBridge/IvyBridge CPUs. Patches courtesy of Pimentel and his tools as published at IM. Vanilla kernels for Core2Duo/Core2Quad, Arrandale and Sandy/Ivy Bridge CPUs: Vanilla_kernel_10.12.zip (Darwin 16.0.0) Vanilla_kernel_10.12.1.zip (Darwin 16.1.0) Vanilla_kernel_10.12.2.zip (Darwin 16.3.0) Vanilla_kernel_10.12.3.zip (Darwin 16.4.0) Vanilla_kernel_10.12.4.zip (Darwin 16.5.0) Vanilla_kernel_10.12.5.zip (Darwin 16.6.0) Vanilla_kernel_10.12.6.zip (Darwin 16.7.0) Patched kernels for Haswell, Broadwell, Skylake CPUs: N/A (Clover and Enoch can patch the vanilla kernel on the fly) Patched AppleIntelCPUPowerManagement kexts for Sandy/Ivy Bridge CPUs: Patched_AICPUPM_10.12.zip Patched_AICPUPM_10.12.1.zip Patched_AICPUPM_10.12.2.zip Patched_AICPUPM_10.12.3.zip Patched_AICPUPM_10.12.4.zip Patched_AICPUPM_10.12.5.zip Patched_AICPUPM_10.12.6.zip NB: kernels go to /System/Library/Kernels as kernel; patched AICPUPM kext goes to /System/Library/Extensions

Erm, for the kernel, do not use El Capitan's, obviously! Use Sierra's. Arf, never posted them... Bear with me...

VoodooSDHC is known to cause Wake issues. I know of no fix unfortunately. That's why we've been lucky the DSDT patch to inject compatibility with Apple's device works on the Latitude Series. Good luck with your future experimentations.

The IOReg shows various devices under PCIE@1E: * ethernet@0 -> Broadcom LAN card * CRD0@1 -> Ricoh Co Ltd R5C832 IEEE 1394 Controller (1180,832) * FRWR@1,4 -> Ricoh Co Ltd xD-Picture Card Controller (1180,852) so DSDT _DSM method seems inappropriate to me then 3 x Ricoh devices: * 1180,822@1,1 -> Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter * 1180,843@1,2 -> Ricoh Co Ltd R5C843 MMC Host Controller * 1180,592@1,3 -> Ricoh Co Ltd R5C592 Memory stick Bus Host Adapter In the DSDT, only CRD0, FRWR and CRD1 are defined. You do not necessarily need to inject anything for those missing devices in the DSDT. The LAN card is the vey proof of it; you just need the correct driver. Use DPCIManager->PCI List tab to identify which kext is used for each device. You may have to add the other device 843 + 592 to the kext too. Experiment... I take it you initially worked according to this, right? This being said, you could also give a try to a DSDT Patch that injects a device for the card reader and declares it compatible with Apple's default SD card reader. This would be placed alongside the existing devices under PCIE and would look like this: Device (SDXC) { Name (_ADR, 0x00010001) Method (_INI, 0, NotSerialized) { SMI (0x95, 0x04) // or SMI (0x9D, 0x04) } Name (_S1D, Zero) Name (_S3D, 0x03) Method (_DSM, 4, NotSerialized) { Store (Package () { "device_type", Buffer () { "Media controller" }, "AAPL,slot-name", Buffer (0x09) { "Built-in" }, "model", Buffer () { "Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter" }, "compatible", Buffer () { "pci14e4,16bc" }, }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } No guarantees of course, these are just pointers/ideas for experimentation... I've got one question though: is the DSDT you posted of Inspiron1720 origin or does it come from another computer like the D630 (because it really looks like it does!)? I would not mind the raw table...

Your SSD is partitioned MBR so you will need to apply the MBR patch in order to be able to install OS X on that disk. Yes, you can normally install OS X and Windows on the same disk in a dual-boot arrangement. Clover will support this. Have a look at Jake's guide for the installation process and necessary files. No need to re-invent the wheel. Note that it's the same process between El Capitan and Sierra.

It's the exact same model as fitted to the good old D430: D430_ML:~ admin$ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01) 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01) 00:1c.1 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 2 [8086:27d2] (rev 01) 00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 3 [8086:27d4] (rev 01) 00:1d.0 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) 00:1d.1 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) 00:1d.2 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) 00:1d.3 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) 00:1d.7 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller [8086:27cc] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e1) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation N10/ICH 7 Family SMBus Controller [8086:27da] (rev 01) 02:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev b4) 02:01.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] (rev 09) 02:01.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 18) 09:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express [14e4:1600] (rev 02) 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4311 802.11a/b/g [14e4:4312] (rev 01) D430_ML:~ admin$ From memory, we could get it detected through VoodooSDHC kext but could not get it to work properly because the device apparently shares an IRQ with the Ethernet. I cannot say whether it would be the same on the 1720 of same generation but an older VoodooSDHC kext may work provided it can load under Sierra. Griftopia, try this fat binary kext: VoodooSDHC.kext.zip

Alternatively, you can simply switch to latest Enoch bootloader and retain all your existing Chameleon setup. The differences will be: the new kernel.plist in /Extra (with specific new kernel parameters) the need to copy (not move) kexts to /Library/Extensions to load/cache them (kext from /E/E will only be injected if new boot option KernelBooter_kexts=Yes is used. Useful as a backup when you want to boot without cache which ignores /L/E...) ideally remove defacto-obsolete myHack.kext in /S/L/E You can check my D630/E6220/E6230 guides for El Capitan to that effect (Sierra uses exact same process).

Just a little update after all this time: the patch still runs in El Capitan and Sierra. NB: Rather than patch CellPhoneHelper directly or use a patched copy of the kext, the patch can also be added as an entry to FakeSMC Info.plist and Bob's your uncle! No need to patch the kext any more, except if the kext Info.plist file gets syntax changed throughout OS X versions of course...

Don't confuse the HDD partition scheme (the type of partitioning) and the partition formatting (NTFS, OS X Journaled, etc.). OS X default partitioning scheme is GUID whereas, with Windows, it used to be MBR. MBR is not natively supported by OS X, hence my asking. If you can boot your OS X USB installer, the Disk Utility will show you the current scheme.