Hervé

I knew this would be your next question, so I anticipated a little! https://osxlatitude.com/index.php?/topic/8739-patching-airportbrcm4360-kext-for-unsupported-mac-models/

We've had many posts from users who have a wireless card controlled (and sometimes natively supported) by the AirPortBrcm4360 kext in their laptop Hackintosh but are not able to get it to work unless they opt for, say, the MacBookAir5,2 SMBIOS. The DW1520 wifi card is one of those for instance: 14e4:4353 is supported OOB but only with some SMBIOS such as MBA5,2. It's also been stated that reason for this was "whitelisting" by Apple in the kext, i.e. Apple have specified a set of Mac models for which the card would work (and would not work for others as a consequence). Those who want to get their cards working without switching to MBA5,2 SMBIOS have little choice but patching the kext in order to "inject" their specific profile. In this case, we're not talking about a simple traditional PCI id injection in the kext's Info plist, we're talking about binary patching the kext's binary file. NB: some cards are not natively supported by the kext and PCI device patching (injection) is then required in the Info.plist file, i.e. "double" patching so to speak... Let's look at the kext binary file to start with (it's located in the Contents/MacOS folder inside the kext package). Here, we'll look at the file from El Capitan 10.11.3 but the principle remains the same for other OS X versions/releases. The file contains a list of supported Mac models (aka a whitelist), a list expressed with references to product board in the form "Mac-<Hexadecimal string>". In the above picture, we can clearly see the reference to MacBookAir5,2 board id "Mac-2E6FAB96566FE58C", something we can confirm with Chameleon Wizard or Clover Configurator SMBIOS tab if required: In order to modify the kext to support an unsupported model, we're going to binary patch it by replacing an existing board reference by that of the targeted/desired Mac model. For instance, if we want to add support for the MacBookPro6,2 Mac model, we're going to replace all the octets referring to the MacBookAir5,2 board id (but we could replace another model of course) by those referencing the MacBookPro6,2's. There are various ways to binary patch the kext: use a hex editor such as 0xED or Hex Fiend for instance, use a perl command from Terminal, or even use the Clover on-the-fly mechanism. Whilst a hex editor will support text (ASCII) replacement as well as hexadecimal replacement, perl will require sole use of hexadecimal octets. It is therefore necessary to convert the text string to hexadecimal in that case. Whilst the computer-literate people would be able to do this manually, non-IT people would find this rather tedious; fortunately there are various conversion tools around these days, including online (e.g.: http://hex.online-toolz.com/tools/text-hex-convertor.php). Generally speaking, it's always recommended to proceed with the hexadecimal replacement to avoid any confusion in text/ASCII. In the case of the MacBookPro6,2 (board product: Mac-F22589C8), we obtain the following hex string: 4D 61 63 2D 46 32 32 35 38 39 43 38 (i.e. the hexadecimal notation of each ASCII character) We can also notice that this particular board product contains 8 digits, i.e. less than the 16 digits of the models listed in the kext. With regards to binary patching, we'll therefore replace the "missing" 8 digits by null octets set to 00, making the replacement string: 4D61632D46323235383943380000000000000000 ` The binary patch can therefore be applied in the following manner: For those using Clover, on-the-fly patching is done through the usual Find/Replace method. For instance: Kext: AirPortBrcm4360 Find: 4D61632D32453646414239363536364645353843 --> MacBookAir5,2 Replace: 4D61632D46323235383943380000000000000000 --> MacBookPro6,2 Here's an example previously posted by JakeLo for injection of MacBookPro8,2 reference (text in Clover's config.plist): <dict> <key>Comment</key> <string>DW1520 Whitelist Patch (MBP8,2)</string> <key>Find</key> <data> TWFjLTJFNkZBQjk2NTY2RkU1OEM= </data> <key>Name</key> <string>AirPortBrcm4360</string> <key>Replace</key> <data> TWFjLTk0MjQ1QTM5NDBDOTFDODA= </data> </dict> Like many other plist files, Clover's config.plist makes use of Base64 code for data. As such, test must be converted to Base64 code before it's entered through a text editor. Again, there are online tools to help with this (e.g.: http://online-toolz.com/tools/text-base64-convertor.php). The Clover Configurator app will provide a much easier mechanism to program this patch as plain text can be used instead, the app doing the conversion for you. In a nutshell, in order to binary patch the AirPortBrcm4360 for an unsupported Mac model, one needs to: identify the board product id of the targeted/desired model convert that board id from text to hex add any necessary trailing null (00) octets to obtain the required 20bytes string binary modify/patch the kext to replace the 20bytes string of an existing model the 20bytes string of the desired model NB: As usual, always keep a backup of the vanilla kext somewhere. To patch the kext, make a copy of the vanilla kext outside /S/L/E (like on the desktop) and patch that copy. The patched kext can then be copied/moved to /S/L/E, permissions repaired and cache/prelinked kernel rebuilt. Direct patching of a kext located in /S/L/E (or /L/E) is usually not allowed due to permission restrictions.

Sounds like you need a DSDT patch for USB devices (EHCx)... Post your DSDT.

There are no kext (or kext-related info) to extract or inject in a SMBIOS file per sé, but maybe it was an excess of language on your part. In the context of Hackintoshing, a SMBIOS plist file is "just" a text file used to pretend your computer is the targeted Mac model. The limitation experienced with this particular wifi card model is within the vanilla wireless kext, not within the MBA5,2 SMBIOS file in which there's nothing you can extract to inject in the MBP6,2. As indicated by Jake, it's the Broadcom kext that needs patching to support non-MBA5,2 profiles. Forgive the analogy but consider it like trying to get an elephant through a cat door. Not much you can take from the cat for the elephant, it's the door that needs a bigger hole!

You have landed on this Hackintosh forum so I take it you're aware of what a Hackintosh is, aren't you? Can you confirm your Precision model as the high-end Tower 7910 workstation (no 9710 as far as I can see)? Post your detailed hardware specs (chipset, LAN, Audio, graphics card) so that we get a better idea re: potential as a Hackintosh.

I would not expect everything to run on a VM, especially tricky apps such as iMessages that rely on real hardware elements (serial numbers, Ethernet interface, etc) and for which Apple introduced locking mechanisms some time ago. Why not opt for a proper Hackintosh installation instead?

Following up on my experiments with the PCIe x1 Marvell 88SE9123 controller, I tested the Syba SD-PEX50055 card (which has also been mentioned on other forums). It offers 2 x SATA-III ports + 2 x USB3.0 ports on a PCIe 2.0 x4 card. The card is based on the ASMedia ASM1062 SATA-III controller and the Etron EJ168A USB3.0 controller. The SATA-III controller works OOB in Snow Leopard, Lion, Mountain Lion, Mavericks and Yosemite. It just requires power (using a floppy-type connector). 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 supporting PCIe slot (x4, x8 or 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 speed and, for SSDs, enable Trim. USB ports only operate as USB2 speed when the card is fitted in a PCIe v1.0 slot. In addition, they are not supported in SL 10.6, only from Lion 10.7. http://www.sybausa.com/index.php?route=product/product&path=64_77_85&product_id=177 WS670:~ admin$ lspci -nn pcilib: 0000:08:00.0 64-bit device address ignored. [...] 04:00.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 05:01.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 05:02.0 PCI bridge [0604]: Pericom Semiconductor Unknown device [12d8:2304] (rev 05) 06:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 01) 07:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01) [...] WS670:~ admin$ ` Although coming on a x4 format, the card is actually PCIe x2 (i.e. limited to 2 x PCIe lanes). Still, I was holding high hopes of being able to gain improved performance at full or near-full SATA-III (600MB/s) speed off my SSD in my ancient PCIe 1.0 workstation. Unfortunately it proved not to be the case. The card only seems to operate at 1 x PCIe lane per SATA port in my PCIe v1.0 x8 slot (operating at x4). BlackMagic speed test gave somehow disappointing results with a read speed of 200MB/s and a write speed of 166MB/s, i.e. it's a little slower reading than the Marvell controller but a little quicker writing.

https://osxlatitude.com/index.php?/topic/2513-i-must-be-dumber-than-a-mule/?hl=%2Bmodcd+%2Bd630&do=findComment&comment=18890 https://osxlatitude.com/index.php?/topic/2897-someone-please-direct-me-to-an-appropriate-guide/?hl=%2Bmodcd+%2Bd630&do=findComment&comment=22207 Old stuff of course, but generally 95% still applicable. I highly recommend that you skip the EDP part and use the full packs I provided instead. But it's up to you of course...

HDMI audio if you have HDMI.

Try the attached 10.11.3 AppleHDA kext (v272.51.3) patched for IDT 92HD71 (you'll have to remove VoodooHDA + AppleHDADisabler kexts). You may need to add EAPDFix + CodecCommander in order to gain jack/headphone output and audio after sleep (but check without 1st). If audio works with patched AppleHDA, try re-instating SpeedStep in BIOS too. AppleHDA_IDT692HD71.kext.zip EAPDFix.kext.zip CodecCommander.kext.zip

Don't know, that may depend on the trackpad/PS2 controller you're using. Did you also check if the parameter was enabled in the trackPad PrefPane?

Or install the lspci binaries available in myHack... No info in BIOS at all?

What's the audio chip or codec on the E6500? It may show in the BIOS information page, if not, a lspci -nn Terminal command or DCPIManager will list the hardware ids. Once you've identified it, you may easily patch the AppleHDA kext.

Fn-UP/Fn-Down on the D630 throughout. No reason for this to be different on the D830, unless the DSDT was modified to that effect...

Only compressed files can be attached. kext-dev-mode and rootless are defunct/useless boot parameters with ElCapitan. You have to use the CsrActiveConfig parameter to disable SIP or none of your add-on kexts will load...

Then install SL with ModCD... Look it up on the forum or the web.

The patch code would go into a DSM method within your Device (DGFX) section. You'll find hundreds of sample nVidia DSDT patches on the web. You'll find one such sample here for instance.

Can't do much if you're not able to read what's written...

To gain DVI output in addition to HDMI (no VGA support), apply the Azul Framebuffer patch detailed here.

Since audio appears to be working with ALC269-patched AppleHDA, you may want to try adding EAPDFix + CodecCommander kexts to your system to gain headphone/jack output, including after wake.

Are you sure you removed the IntelHD graphics kexts and cache as indicated in the guide? I'm not entirely sure as I'm seeing AGPM loading for Intel HD 8086:0046 on your screenshot... See post #53 and #56 of that thread.

You boot off the USB driver right after Yosemite installation on your HDD/SSD because, at that initial stage, the bootloader is not installed on the disk/partition. Once it's installed, you no longer require to boot via the USB key.

EDP->Documentation...

No, why? https://osxlatitude.com/index.php?/topic/2120-inventory-of-unsupported-and-supported-wireless-cards/

The D630 is a better machine (GM965 chipset vs. GM945, Merom/Penryn CPUs @FSB800 vs. Merom @FSB667, GMA X3100 vs. GMA950), but all Intel GMA chips of that era are only supported in 32bit kernel mode, i.e. up to Lion 10.7.5. It does not matter that CPUs are 64bit capable (other than being a requirement for Lion), there's no graphics support for those systems in 64bit mode.