Hervé

That's a card based on Apple's own BCM94360 models and it works OOB without any add-on kexts; I've got one in my Latitude 7490 now. No issues to report whatsoever. Make sure you connect to a 5GHz wireless network to enjoy full Wifi 802.11ac speed (if your router supports it of course). You may experiment with wireless channels as different ones may provide different speeds. Like Wifi, Bluetooth should work OOB as long as you're not using any add-on kext...

As far as your renaming are concerned, they look Ok but it's true that the native BIOS tables provide 2 x PEGP devices: 1 x under PEG0 which is the nVidia dGPU and 1 x under PEG1 which seems to be the ThunderBolt port. Hence why you may notice in IOReg a GFX0 device under PEG0 + a 2nd GFX0 device under PEG1; but that's Ok. iGPU device @2 is correctly renamed as IGPU. Your dGPU is Pascal (mobile GTX 1070) and therefore requires the nVidia Web Driver which you've clearly installed and enabled. A quick look at your screenshot reveals that, if your highlighted video output is your built-in screen, setup is incorrect. Why? Because: display0 is listed as AppleDisplay, i.e. an external monitor, not AppleBacklightDisplay, the expected value for a built-in LCD display0 is listed under 2nd output port Display-B@1, not the expected Display-A@0, and as an HDMI monitor (connector-type set to 0008 0000) not a built-in LVDS or eDP screen As long as your built-in screen is seen as an external monitor, you won't be able to adjust brightness, that's quite normal. You may have to look into injecting properties for the dGPU but I think the choice of SMBIOS is the issue. Bear in mind that the last Mac laptop fitted with an nVidia dGPU was the Haswell/Crystalwell MacBookPro11,3. You may try that but note that, by far and large, brightness control was hardly ever obtained on Hackintosh laptops with nVidia graphics; imo, even more so with a non-natively supported dGPU... Other items to address in your setup: you've generated USBPorts kext but you've installed SSDT-UIAC table in ACPI/Patched folder. That's wrong: you either use USBPorts on its own or SSDT-UIAC.aml + USBInjectAll kext. If you use an incorrect setup, your USB ports may not work properly. you inject FakePCIID kext; that's useless and you can get rid of it. you inject nVidiaGraphicsFixup kext; I'm pretty sure that's also useless given that you inject Lilu + WEG PlugIn alongside; I'd get rid of it. you inject dAGPM kext; afaik, this applies to natively supported dGPUs which your Pascal chip is not; I'd get rid of it too.

Try not to exceed Clover version r5122; there are many people reporting issues with subsequent versions; I certainly can confirm this through own experience on my existing Hacks. Then post your system's specs if you want adequate/appropriate feedback on the Clover setup you're using. I see stuff that could need revisiting but only once you've detailed your laptop's hardware components. Do like most of us: post them in signature.

Please consult our FAQ section where you'll find existing answers to your 2nd question.

As long as it's a Kepler GK208 model (PCIe 2.0 x1 / PCIe 2.0 x8), yes but I believe macOS-incompatible Fermi models (PCIe 2.0 x16) are rare. A Kepler GT710 will be supported OOB and with all output ports, exactly like with a Kepler GT730. https://www.techpowerup.com/gpu-specs/?generation=GeForce+700&sort=generation It's a low-end/entry level card so performance will be far behind that of your previous GTX 650Ti but it's not necessarily an issue if you're not doing any fancy like video editing or gaming or anything else that requires a minimum of graphics power.

GeForce GTX 650Ti is Kepler (GK106) and allows you tu run OS X up to most recent macOS Catalina/Big Sur versions. On top of this, it is supported OOB. If you want to assess the status of the card, try and test it in another PC. You'd soon find out if it works or not. I'd also check the Precision T1650 BIOS settings to ensure video is set to PEG (PCI Express), not PCI or otherwise. Radeon HD 5750 will not be supported beyond High Sierra, if it is supported at all (but probably given that models such as HD 5730 or HD 5770 are). It's unlikely it'll work OOB and will require you to find the AMD5000 framebuffer that gives you graphics acceleration and may require to fake id. So it really depends on the OS X/macOS version you're currently running. But I'll tell you this; there are much newer and arguably better cards than the ageing HD 5750 that'll probably compare in terms of price and performance and that would let you run all recent macOS versions. For instance the Kepler GK208-based DDR5 GT730 which can be obtained for anything between, say, 30/35 and 60/70 $/€. Since it's Kepler, it works OOB too and all output ports are supported (VGA, DVI, HDMI) even concurrently... https://gpu.userbenchmark.com/Compare/Nvidia-GeForce-GT-730-vs-AMD-HD-5750/m12582vsm7753

HibernationFixup should not be required. E7450 normally sleeps & wakes Ok with hibernation disabled (see our FAQ section for details) and proper native CPU power management. Brightness keys should also be fully working with either the DSDT patch detailed in my E7250 guide or the SSDT-BRT6 table provided by JakeLo in numerous threads.

You're gonna have to provide more details than that. For now, I can only assume you're trying to boot the USB installer and it's hanging. Please specify 1) if your E6430 is fitted with Optimus/dual graphics or Intel HD4000 only 2) how you built your installer 3) what bootloader you're using and which version and 4) post a zipped copy of the bootpack you used (EFI folder) or your debug files Given the amount of guides and threads related to the E6x30 family models, it's a little surprising that you've not found something that would get you running out of the box so to speak... Make sure you'e also configured your BIOS as per the recommended settings.

You have to declare that kext in your OC configuration, like the rest of your add-on kexts. I did not see that either. All in all, you should read the OpenCore + Intel Wireless solution documentation with all due attention: https://dortania.github.io/OpenCore-Install-Guide/ https://openintelwireless.github.io/ Then proceed as per the published recommendations. For instance: If you deviate, as you appeared to have done, expect problems...

Moved to own topic since this is totally unrelated to the thread it was initially posted in. A nice and obvious start would be that you state the model of Intel card you're running with... Wouldn't you agree? Then, quickly looking at your posted OpenCore EFI folder, there is no sign of that itlwm kext, so, indeed, it's unlikely you'll get working Intel wireless... I suggest you read the documentation available on OpenIntelWireless Github repo. And, of course, you're expected to use the Heliport client app too.

If you build your USB installer as per my 7490 guide and set your BIOS as per the recommended settings, I can't see any reason why you would not be able to boot the installer. Just follow the detailed instructions without deviations or shortcuts.

@Justin Wallis, please use the Reply box at the bottom of the pages rather than use the quoting facility to post replies. Former is expected, latter is most annoying. Off-topic, by exception: Apple do not release alpha versions, only betas. So far 11 x betas for Big Sur since June. GM or final release expected next week. End of off-topic.

The DSDT should no longer cause any issue (but it's for a 7490, I can't say if it can apply to a 5590) and the Clover pack is CPU agnostic. Please post your system's specs, especially the make and model of your SSD. If it's a SATA model, you should have no issue but if it's NVME, note that not all models are supported.

See our FAQ section... You may also have to regenerate your USBPorts kext or USB-related SSDT if you use any of those.

Added new note about Intel wireless cards.

Thread sanitised and locked to avoid further mixing of OpenCore and Clover, causing confusion on what was effectively an OC-related thread.

Can't be done from either OS disk utility/disk management tools. These can only reduce (or increase) a partition size from its end but they cannot move a partition which is what you'd need here. According to what you described, your disk is organised as follows: 1st partition with OS X El Capitan 2nd partition with Windows 10 Partitions cannot be split across separated disk areas so what you effectively need to do here is: reduce Win10 partition move reduced Win10 partition to end of disk recover the space liberated between end of OS X partition and moved/reduced Win10 partition to reallocate to OS X partition You'll have to look for dedicated 3rd party apps such as GParted, Paragon and many others to do this. The only other alternative would be to make an image of your Win10 installation (or clone the partition) before you delete the 2nd partition from El Capitan Disk Utility app, after which you would be able to re-create a smaller 2nd partition on which you'll restore your Win10 image.

Yes, you're one of many with such issues. It's not a straight update given that r5125 brings changes for Big Sur and you need to take Quirks and new drivers into consideration. So, unless you intend to run Big Sur now, stick to r5119.

No, Jake gave you the correct values to reflect your Skylake iGPU rather than the Kabylake iGPU of the OP. Use them.

Yes, the SSDT table generated for any given CPU can of course be re-used on any Hackintosh fitted with the exact same CPU model, i.e. no need to regenerate when you already have the applicable (generated) SSDT. The platform on which you generate the CPU power management SSDT does not really matter. By default (i.e. without any parameters), the script generates a table for the host's CPU and active SMBIOS data (Mac model + board-id) but, if you've installed the complete package with CPU models database, you can add parameters to target a totally different CPU & Mac model. All parameters and instructions are explained in the documentation available on that GitHub repo or if you type: ./ssdtPRGen.sh -help For instance: 1) to generate the SSDT for an i7-3540M CPU fitted to an Ivy Bridge laptop running OS X/macOS with MBP10,2 SMBIOS ./ssdtPRGen.sh -target 1 -p i7-3540M -m MacBookPro10,2 -b Mac-AFD8A9D944EA4843 2) to generate the SSDT for an i5-5300U CPU fitted to a Broadwell laptop running OS X/macOS with MBP11,2 SMBIOS ./ssdtPRGen.sh -target 3 -p i5-5300U -m MacBookPro11,2 -b Mac-E43C1C25D4880AD6 You can get board-id of any Mac Model from Clover Configurator app, SMBIOS tab.

Re: DrHurt's VoodooPS2 kext, you were meant to take it from here: https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/ Use the kext's version recommended in post #1 and do consider generating your USBPorts kext with Hackintool app as I experienced a TrackPad issue last year in relation to that matter as detailed here.

aka Telit LN930. 4G LTE 100Mbps WWAN module (M.2 format). Given that it is based on an Intel XMM 7160 chipset, I'd say there is very little chance -not to say zero- that'll be supported as a WWAN interface. We've certainly never discussed this module here in the past. I expect you'd have to dig into its specs, work out its various operating modes and then experiment with potential WWAN module profiles (from CellPhoneHelper kext) if any were applicable at all (but I doubt it)... http://www.adaptivemodules.com/assets/telit/Telit-xN930-Hardware-User-Guide.pdf You say it is seen as a WLAN card -which I very much doubt- but maybe it's actually seen as a dial-up modem. It may work that way.

Yes and you can look that up, it's well documented in numerous places/threads/posts. Your Crucial model is not affected.

Clover setup shows several mistakes. For instance, you've installed SMCHelper.efi driver (which is only required if you use FakeSMC kext) when you use VirtualSMC set of kexts. If you want built-in ALPS TrackPad to work and be recognised, you need to use Dr Hurt's VoodooPS2Controller kext. It's available in Dr Hurt's dedicated thread and in the Clover packs posted in the various guides we have for the E7x50 models. I can't remember which ALPS version these E7x50 are fitted with but I don't remember specific issues with them when I had an E7250 in my hands. Re: SSDT, if you're talking about the CPU power management one, you have to make sure you use one that was generated for your own specific CPU. If you (re)use an existing one meant for a different CPU mode, you'll encounter trouble, of course. If in doubt, boot without such SSDT and generate your own one using Pike R Alpha's well-known and good old generator script.

I suggest you investigate what a DW1506 card is based on.