Hervé

The graphics card determines the OS X version supported by the laptop: https://osxlatitude.com/index.php?/topic/8081-full-packs-for-d620d630-snow-leopard-lion-mountain-lion-mavericks-yosemite-el-capitan/ myHack-based installation up to Mavericks; manual Chameleon/Enoch/Clover based installations thereafter.

Last updated: 28 Mar 2020 This guide is a follow-up to similar work previously posted by EmlyDinesh for HD3000 and HD4000. It is based on the excellent research work published by many other well-known Hackintosh gurus such as Pike R Alpha, Toleda, RampageDev, Rehabman and several others (whose name eludes me and for which I apologize) and for which they must be once again thanked. Their work is readily available through a Google search with keywords that include "Azul", "Framebuffer", "HD4x00", etc (brain usage is expected here). I did not do anything other than study this existing literature and experiment with the Intel HD4600 fitted to my Dell Latitude E6440 laptop (SMBIOS MBP11,1 Profile) in order to gain DVI output off an E-Port Plus/PRO2X docking station/port replicator, having previously obtained HDMI output through a binary patch handed over to me (a patch I wanted to understand). The E6440 comes fitted with a VGA port + a HDMI port. This being stated, the information below should be considered as that -experimentation results- and guidance for experimentations for those seeking to gain DVI, DP or HDMI video output on their Haswell GPU-based Hackintosh. Haswell integrated GPUs include Intel HD (4th gen)/HD 4200/HD 4400/HD 4600/HD P4600/HD P4700/HD 5000 as well as Iris 5100/5200. In OS X, display ports are managed by the framebuffer (FB) kext and for the Haswell family, we're talking about AppleIntelFramebufferAzul.kext (Azul FB). The Azul FB binary file contains various tables associated with each layout, each being identified by its own id (layout-id/ig-platform-id/ etc.) and, usually, about 7 x 16bytes long (I'm not 100% certain of the specific table length and end for each layout). These FB layout ids are the values that most of us have to inject in DSDT or bootloader setup to obtain full graphics acceleration, for instance 0x0600260a for laptops or 0x0300220d for desktops. 1) Azul framebuffer analysis / layout ids Let's look at a few tables of El Capitan 10.11.3 Azul FB kext (latest at time of writing), including those specific to the above 2 ids. Using a Hex editor, they're found at offsets 48xxx/49xxx. The 1st 4 x bytes identify the layout id and the rest includes data such as number of ports, VRAM allocation, connector indexes, connector types, etc.. The layout details are available in the attached extract: EC_10.11.03_AzulFB_layouts.zip The 1st layout is found at Offset 48CD0: 0000 060C 0003 0303 0000 0004 0000 0001 layout id 0000 F000 0000 0040 9914 0000 9914 0000 VRAM allocation 0000 0000 0000 0000 0000 0800 0200 0000 connector index / BusID 3000 0000 0105 0900 0400 0000 0400 0000 pipe 0204 0900 0008 0000 8200 0000 FF00 0000 connector-type 0100 0000 4000 0000 0400 0000 0000 0700 0400 0000 0000 0000 0000 0000 0000 0000 ... ... ... At Offset 49130, we have: 0600 260A 0103 0303 0000 0002 0000 3001 layout id (usual layout for mobile HD4600 Hackintosh) 0000 6000 0000 0060 D90A 0000 D90A 0000 VRAM allocation 0000 0000 0000 0000 0000 0800 0200 0000 connector index / BusID 3000 0000 0105 0900 0004 0000 8700 0000 pipe 0204 0900 0004 0000 8700 0000 FF00 0000 connector-type 0100 0000 4000 0000 0F00 0000 0101 0000 0400 0000 0000 0000 0E00 0000 0000 0000 ... ... ... At Offset 492F0, we have: 0300 220D 0003 0303 0000 0002 0000 3001 layout id (usual layout for desktop HD4600 Hackintosh) 0000 0000 0000 0060 9914 0000 9914 0000 VRAM allocation 0000 0000 0000 0000 0105 0900 0004 0000 connector index / BusId 8700 0000 0204 0A00 0004 0000 8700 0000 pipe 0306 0800 0004 0000 1100 0000 FF00 0000 connector-type 0100 0000 4000 0000 0204 0000 0101 0000 0400 0000 0000 0000 0E00 0000 0000 0000 ... ... ... What interests us here, in the matter of display output ports, are the above highlighted parameters. * In terms of connector indexes, they appear to range from 0 to 3, depending on mobile or desktop GPU version, 0 looking reserved for built-in LCDs. We also notice that each layout caters for 3 x ports only, each output port-related line beginning with a similar form made of a pair of bytes: 0000 ... for connector #0 / port #0 0105 ... for connector #1 / port #5 0204 ... for connector #2 / port #6 0306 ... for connector #4 / port #7 * In terms of pipe, I've read that the lower byte right after the FB index apparently operates in conjunction with some activation delay: when 2 ports have an identical pipe value, the port with the highest delay takes precedence, thereby disabling the other. If ports have their own unique pipe, they will be all enabled/available. I'll have to try to hook DVI + HDMI at the same time to confirm this behaviour. * In terms of connector-type, there are several known values: 0100 0000 for VGA 1000 0000 for VGA 0200 0000 for LVDS/eDP (built-in LCD of laptops) 0400 0000 for digital DVI 0002 0000 for analog DVI 0004 0000 for DP 0008 0000 for HDMI When using the vanilla Azul FB kext, my E6440 reports the following in IOReg: AppleIntelFramebuffer@0 (built-in LVDS display showing attached to this) port-number: 0x0 connector-type: 02 00 00 00 AppleIntelFramebuffer@1 port-number: 0x5 connector-type: 04 00 00 00 AppleIntelFramebuffer@2 port-number: 0x6 connector type: 04 00 00 00 One could easily imagine a direct translation of the connector index + its adjacent BusId byte in the layout tables with the display port number as reported in IOReg; that'd be incorrect, as stated in the existing literature. If, indeed, the layout id tables show pairs "00 00" for port #0 and "01 05" for port #5, one would quickly notice that pair "02 04" translate to port #6 and pair "03 06" to port #7. Therefore, except for port #0, the rule seems to be that port number = connector index + 4. 2) HDMI and DVI display output When experimenting with my mobile HD 4600-based Latitude E6440, no HDMI output was obtained OOB with the vanilla Azul FB kext. In fact, the laptop immediately crashed the moment a HDMI cable was hot-plugged. It would not even boot with a HDMI cable plugged in. However, HDMI works perfectly after applying the binary patch to the kext where the hex string 01050900 00040000 87000000 is replaced by 01051200 00080000 87000000. We can see that this patch modifies: a) the pipe lower byte 2) the connector type In IOReg, the HDMI display showed attached to connector index #1 with port-number 0x5 and connector-type 0008 0000. We can see that, in the vanilla kext, connector indexes #1 and #2 of layout id 0x0600260A use the same pipe value after the id and the same connector-type. Building on the technical information gathered from the literature and the above observations, I tried to enable the DVI port off my docking station to use a 2nd DVI screen (lack of VGA support oblige). I first applied the following patch to layout id 0600260A located at offset 49130, keeping the above HDMI patch untouched. before: 02040900 00040000 87000000 FF000000 after: 02040900 00020000 87000000 FF000000 This failed to enable DVI output off my E-Port Plus. I then tried to adjust other parameters such as pipe byte, to no avail. Keeping in mind the availability of connector index #3, I then applied the following patch, again leaving the HDMI patch untouched: before: 02040900 00040000 87000000 FF000000 after: 03060900 00020000 87000000 FF000000 This proved successful and brought me DVI output off the E-Port Plus/PRO2X . However, HDMI appeared broken as system froze as soon as HDMI cable got plugged in. After several adjustments of the pipe byte, HDMI and DVI outputs are obtained when the pipe is set to 0x12 for both ports. This makes for the following Azul FB binary patch: At Offset 49130, patch vanilla table: 0600 260A 0103 0303 0000 0002 0000 3001 0000 6000 0000 0060 D90A 0000 D90A 0000 0000 0000 0000 0000 0000 0800 0200 0000 ; connector index #0/port #0, connector-type LVDS 3000 0000 0105 0900 0004 0000 8700 0000 ; connector index #1/port #5, connector-type DP 0204 0900 0004 0000 8700 0000 FF00 0000 ; connector index #2/port #6, connector-type DP 0100 0000 4000 0000 0F00 0000 0101 0000 0400 0000 0000 0000 0E00 0000 0000 0000 to: 0600 260A 0103 0303 0000 0002 0000 3001 0000 6000 0000 0060 D90A 0000 D90A 0000 0000 0000 0000 0000 0000 0800 0200 0000 ; connector index #0/port #0, connector-type LVDS 3000 0000 0105 1200 0008 0000 8700 0000 ; -> pipe 0x12 and connector-type HDMI 0306 1200 0002 0000 8700 0000 FF00 0000 ; -> index #3/port #7, pipe 0x12, connector-type DVI 0100 0000 4000 0000 0F00 0000 0101 0000 0400 0000 0000 0000 0E00 0000 0000 0000 These patches are applicable to all versions of OS X and macOS supporting Haswell graphics. 3) VGA display output VGA output is simply not supported on Haswell iGPUs to the exception of HD4400 with which such output is known to work OOB on some laptops and shows as a DP output in IOReg. HD4400 is the only iGPU of the Haswell family to present such behaviour. There is no patch, no workaround, no solution for VGA output for the others. Edit: 28 Mar 2020 - - - - - - - - - - - - - Thread cleaned up to retain only the useful info.

The app works (preferably but not necessarily) with the associated HWSensors package (FakeSMC + PlugIns (ACPI/CPU/GPU/LPC sensors)). Once your've installed the kexts, simply run the app. It's as simple as that! I recommend Kozlek's packages: http://sourceforge.net/projects/hwsensors/files/

OS X support dynamic partition resizing in DU. You can adjust existing partitions size albeit with certain limitations. For instance, you can't move the starting point of a given partition. If you want to revert from 2 partitions to 1, delete the defunct one. That won't delete the remaining one; it may resize it. Warning: DU of El Capitan and later is a lot less flexible than earlier versions.

Yes, because webcams are connected through an internal USB port.

For those who would need a copy of the Mavericks kernel, here are copies of the various kernels that have come out so far: Vanilla kernels for Core2Duo/Core2Quad, Arrandale and Sandy/Ivy Bridge CPUs: Vanilla_kernel_10.9.0.zip (Darwin 13.0.0) Vanilla_kernel_10.9.1.zip (Darwin 13.0.0) Vanilla_kernel_10.9.2.zip (Darwin 13.1.0) Vanilla_kernel_10.9.3.zip (Darwin 13.2.0) Vanilla_kernel_10.9.4.zip (Darwin 13.3.0) Vanilla_kernel_10.9.5.zip (Darwin 13.4.0) Patched kernels for Haswell CPUs: Haswell_kernel_10.9.0.zip (Darwin 13.0.0) Haswell_kernel_10.9.1.zip (Darwin 13.0.0) Haswell_kernel_10.9.2.zip (Darwin 13.1.0) Haswell_kernel_10.9.3.zip (Darwin 13.2.0) Haswell_kernel_10.9.4.zip (Darwin 13.3.0) Haswell_kernel_10.9.5.zip (Darwin 13.4.0) Good working AMD kernels: Bronya_10.9.5_kernel.zip (Darwin 13.4.0) -> more of those available at InsanelyMac Patched AppleIntelCPUPowerManagement kexts for Sandy/Ivy Bridge CPUs: Patched_AICPUPM_10.9.2.zip Patched_AICPUPM_10.9.3.zip Patched_AICPUPM_10.9.4.zip Patched_AICPUPM_10.9.5.zip NB: Mavericks kernels go to root as "mach_kernel"; patched kexts go to /System/Library/Extensions Patches courtesy of Rehabman & Pimentel and his tools as published at InsanelyMac. Mavericks kernel patch : perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05..\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g' mach_kernel

I meant shortcuts.

That'll depend on the hardware you have... Did you check the FAQ? https://osxlatitude.com/index.php?/topic/8696-is-my-wireless-card-compatible-with-os-x/

It's not the 1st time such a request is made. Unfortunately, none ever got satisfied. If such porting were feasible, I guess it would have long been by now done and for all sorts of Intel cards. Last attempts to produce such Mac OS X drivers date back to Tiger/Leopard era (we're talking 7 or 8 years ago!) and success was somehow limited with little stability. You can search the Net for this. Don't wait for an elusive OS X driver that you'll never get and swap out your card for a supported model or use a supported wireless dongle. https://osxlatitude.com/index.php?/topic/8696-is-my-wireless-card-compatible-with-os-x/?p=56509

You can use installation tools such as Kext Wizard or manually install them. For the latter: copy your kexts to /System/Library/Extensions or /Library/Extensions repair kexts permissions with the following Terminal commands sudo chmod -Rf 755 /System/Library/Extensions (or /Library/Extensions) sudo chown -Rf 0:0 /System/Library/Extensions (or /Library/Extensions) rebuild cache sudo touch /System/Library/Extensions (or /Library/Extensions) sudo kextcache -Boot -U /

Dell Latitude D630 with Intel 330 Series 240GB SATA-III 2.5" 9mm SSD (SATA-II connection @3.0Gb/s): Performance is obviously limited by SATA II (300MB/s) interface of ICH8-M controller. NB: Activating TRIM on this SSD brings it close to a halt. As such, avoid enabling it.

The described behaviour will not be linked to hibernation mode at all. It's more of an issue either with CPU power management or DSDT patching, probably for USB devices. Do you have CPU power management properly working (min/max/intermediate CPU frequencies + Turbo boost)? No sleep possible under NullCPUPM.

Those are actual folders in the home directory, not links or mounted folders from say another disk. You could always remove those I suppose and replace by links pointing to folders on your other HDD.

Create your USB installer with myHack v3.1.2 or v3.3.1 and/or install /Extra using the appropriate full pack available here.

USB are handled differently in El Capitan. Make sure to start by renaming your EHC devices to EHC1/EHC2 in your DSDT for instance.

Your E5520 is probably not too far off the E6x20 Series, so you can use the same installation method as listed in the various guides we have on this forum for those models. You'll have to generate your own CPU-specific SSDT for CPU power management if you can't find an existing one.

Then I would say your bootloader did not install properly. Re-install using default settings.

The kernel file goes under the name "kernel" in a folder called "Kernels", itself located in /System/Library. The "Kernels" folder does not exist by default and needs to be manually created for the Enoch / Chameleon based method.

Not really, the issues really seems to be related to the eDP/Intel HD graphics matter. This being said, we don't really know the method you used to create your USB installer, nor the list of add-on kexts you used. As an absolute minimum, you'd probably get away with a minimum set made of PS2 controllers + FakeSMC. And of course, as advised by Jake, remove the IntelHD graphics kexts so that they're not even loaded as the system boots up.

That cache and relinked kernel rebuilt ran Ok.

You can follow my ElCapitan guide for the D630 nVidia, using the D830 bootpack (or not). The only difference is that Yosemite does not require the CsrActiveConfig parameter (no SIP issue in Yos like in EC), just the kext-dev-mode parameter that you set to 1.

Just fitted one of those in the PCIe x8 (operates at x4 max) slot. Great cheap PCIe add-on card for this older SATA-I/PCIe 1.0 workstation. PCIe x4 may be a must for maximum/SATA-III performance. Made some quick performance comparisons with the BlackMagic app in Mav 10.9.5 and Yos 10.10.5: SSD off the integrated ICH5 SATA-I (150MB/s) non-AHCI controller (no Trim) Read: 132MB/s Write: 127MB/s SSD off the PCIe x1 (v1.0, i.e. 250MB/s) Marvell SATA-III (600MB/s) AHCI controller (Trim enabled) Read: 215MB/s Write: 145MB/s Looking forward to try out a PCIe x4 controller now.

These have been mentioned on other forums before but I got an opportunity to buy one of those PCIe SATA controllers for a few Euros. The card was advertised as based on Marvell 88SE9128 chipset but the model I received turned out as a 88SE9123. It certainly does not seem to make a difference and I reckon that most if not all Marvell 88SE9xxx-based SATA controllers would work exactly as this one does. The card comes as a basic and very compact PCIe x1 card with 2 x SATA-III 6Gb/s ports. Variants with 4 x ports or more exist too (there are various manufacturers offering SATA controllers based on those Marvell chipsets on PCIe x1/x2/x4 cards: Syba, Startech, IOCrest, etc.). It works OOB in Snow Leopard, Lion, Mountain Lion, Mavericks and Yosemite. By default, it's listed as "Unknown AHCI controller" under SL and as "Generic AHCI controller" in more recent OS X versions such as Mavericks or Yosemite, which can easily be fixed through a little patch of AppleAHCIPort kext. Just insert the card in a PCIe slot (x1, x4, x8 or even x16) and attach the disk(s). Perfect for older desktop PCs that do not have a SATA-II/SATA-III/AHCI capable controller and wish to enjoy SATA HDDs or SSDs at PCIe x1 speed (250MB/s for v1.0, 500MB/s for v2.0) and, for SSDs, enable Trim. WS670_SL:~ admin$ lspci -nn pcilib: 0000:05:00.0 64-bit device address ignored. [...] 04:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller [1b4b:9123] (rev 11) 04:00.1 IDE interface [0101]: Marvell Technology Group Ltd. 88SE91A4 SATA 6Gb/s Controller [1b4b:91a4] (rev 11) {...] WS670_SL:~ admin$ ` The PCIe bus obviously drives the overall controller performance. As such, the true speed obtained on drives (and especially SSD) depends entirely on the PCIe version. As a reminder, theoretical unidirectional speeds per PCIe lane (in MB/s) are as follows: version\slot x1 x2 x4 x8 x16 PCIe 1.0 | 250 500 1000 2000 4000 PCIe 2.0 | 500 1000 2000 4000 8000 PCIe 3.0 | ~1000 ~2000 ~4000 ~8000 ~16000 (round-up values, real rates are about 1.5% lower) ` Performancewise, I obtained the following Blackmagic results on my old Precision 670 (PCIe v1.0, i.e. 250MB/s lane) with my Toshiba SATA-III SSD (Trim enabled) : Read: 215MB/s Write: 145MB/s 'not a huge improvement compared to results obtained with the SSD off the integrated SATA-1 (150MB/s) controller, but at least Trim is available.

Rest assured that trying to install a webcam driver on a computer that does not have such hardware is as effective in terms of destroying power as toilet paper in terms of protection againt nuclear explosion!

Maybe those tools have any issue with ElCapitan or you're not using the correct value to disable SIP. With a CsrActiveConfig boot parameter set to 3, I can personally copy/replace kexts in /S/L/E and/or in /L/E, then repair permissions and rebuild cache using the usual well-known Terminal commands.