Hervé

Your config did not contained the correct compatibility statement: you specified pci14e4,43a0 when our guide (on which daliansky's blog is actually based) clearly stated to use pci14e4,4353 or pci14e4,4331 in order to bypass AirPortBrcmNIC kext. This does not match what you actually posted above... By declaring compatibility with pci14e4,43a0, you actually totally annuled the desired bypass objective and, instead, returned macOS to load AirPortBrcmNIC since that's where 14e4:43a0 is declared alongside DW1820A's own id 14e4:43a3... Try this revised version: config.plist.zip

Did you check your Embedded Controller device in ACPI/DSDT? You apply EC0 to EC renaming but since you updated your BIOS, did you check if the device name remained the same? You could easily verify the behaviour by disabling the EC0 to EC renaming from Clover main screen Options menu with BIOS 01.09.01 and check if it hangs at the same place...

KP on AirPortBrcmNIC -> clearly the device properties injected in Clover are not used. They're either incorrectly applied (eg: wrong PCI target as suggested by Jake Lo) or conflict with AirportBrcmFixup which I clearly recommended NOT to use in our BCM4350 guide.

KP on KBL graphics framebuffer. Try -disablegfxfirmware boot arg during installation/upgrade.

Basically, you're trying to cache VirtualSMC and it appears unsupported/incompatible with your Hack for whatever reasons (kext version, bootloader config, applied patches, etc.). I'd switch to FakeSMC instead (and ACPIBatteryManager of course). And you appear to have the same with WEG. You really need to update your add-on kexts to latest versions before you upgrade to Catalina! You're right to cache your kexts from /L/E.

And don't forget the Embedded Controller patch as detailed in our promoted thread (see Our Picks column). Imperative for Catalina.

@bluedogmike, please post your debug files.

Indeed, your Clover config injected properties to avoid the system freeze/CPU hogging with the DW1820A. Now that you've replaced the DW1820A by a fully natively supported card, you can removed those injected properties from your Clover config.

You could try the hard way and follow the same process as detailed in my Latitude D630 guides for High Sierra, Mojave or Catalina: Obviously, some of the files won't be re-usable (like the DSDT or kexts related to specific hardware like LAN card) but the overall process can be applied. Or there is the easy way where you just follow the recent guides posted at InsanelyMac. A simple forum search on E6410 threads or a basic Google search will lead you there. Of course, High Sierra is the last macOs version that supports your Tesla graphics natively and to the full. Mojave and Catalina require the specific tricks detailed on the guides to support Tesla graphics in OpenGL-only mode (no support for Metal). NB: as per our published rules, no references to distros please; stay away from them, they're full of crap.

Incorrect settings, you should: remove Generate C States and Generate P States (these are for C2D, C2Q, 1st gen Core CPUs) enable PlugInType and that's it, nothing else. No need to enable NoOemTableId or NoDynamicExtract afaik.

Well, it would seem that there is something missing or incorrect with regards to your Sapphire RX580 graphics card config then, not the HD4600 iGPU. I'm afraid I won't be of much help on that front since my hands-on experience with AMD cards is most limited. I only ever kept the old ATI Radeon HD X1300 of my old C2D Vostro 200 desktop Hackintosh for a short time back in 2012/2013 given that it was last supported in Snow Leopard. I then replaced the card by an nVidia model for subsequent OS X/macOS versions.

We recently posted an article about Realktek PCIe card readers (click on Home to get there) and there is also a dedicated thread about them in the Card Readers section. Please refer to that. Of course, without an SD card, you won't be able to do/test much thereafter... NB: quoting messages as a reply facility is not appropriate nor desired. Please use the Reply box available at the bottom of each thread. Thank you.

Did you setup your config correctly for HD4600 iGPU? Because the hanging at gIOScreenLockState messages usually means that graphics are not initialising and system keeps retrying.

Check your BIOS settings against the posted recommended ones and adjust as/if necessary.

Up until this time last year, I had a Latitude E6440, a Haswell laptop fitted with HD4600 iGPU and AMD dGPU. The AMD dGPU was not supported and therefore disabled via DSDT/SSDT patching. There never was anything to be done on the iGPU front regarding performance per sé. Booting off the mSATA SSD was just about the same as with any other of my Hacks: ~20s from start to finish. I'm a little surprised to read that, on your Haswell desktop, enabling the HD4600 iGPU increases your boot time by almost 20s. I can't say ever heard of such an impact before. Did you try and analyse what happens at boot time through verbose mode when iGPU is on? Other than my Sandy Bridge Latitude E6220 and it's crappy HD3000, I find no particular performance issue on my other laptops running iGPU: whether it'd be my Ivy Bridge Latitude E6230 and its HD4000 iGPU or my Kaby Lake R Latitude 7490 and its UHD620 iGPU. Same applied to the Broadwell Latitude E7250 + HD5500 iGPU I had for a brief spell.

Hi @arsradu, yes we're aware of this recent issue and we're trying to solve this.

Please consult the FAQ section. I'm sure you can do it without assistance.

We have a dedicated thread on the matter in our FAQ section.

Tested with r5118 and confirmed.

I see: no display detected on 1st output port. I would suggest 2 x things: try MBP11,3 SMBIOS inject boolean property @0,AAPL,boot-display (set to 1) to 1st output port

You could possibly try and inject properties for the 1st output port NVDA,Display-1@0 in an attempt to redefine its properties; can't say if it'd work but nothing to lose really. Also, in order to avoid all confusion on the matter, I'd rename GFX0 (@00020000) to iGPU, then PEGP (@00010000) to GFX0. Try and post a zipped copy of your IOReg if you can.

eDP models were out of luck as far as built-in LCD is concerned (see @nsmartin last post in M4800 thread I linked above). I've not seen anything that changed this in the last 4 years. @Xeon3D quite clearly confirms this too... This being said, I remember the days when Precision M4600 with nVidia graphics would too end up in a black screen when using MBP8,x Sandy Bridge SMBIOS. See here (Chameleon/Enoch) and here (Clover) for instance. People obtained a black screen unless they using a specifically tuned MBP6,x SMBIOS where the board-id was replaced by that of nVidia GPU-based MBP10,1 (Credits to @DuongTH from memory). MBP8,x models were either HD3000 (MBP8,1) or dual HD3000 + AMD Radeon HD 6xxx graphics (MBP8,2/MBP8,3). So, given that: MBP6,x were Arrandale platforms running with dual 1st gen Intel HD + nVidia GeForce GT 330M (Tesla 2.0 GT216) graphics MBP10,1 was Ivy Bridge platform running with dual Intel HD4000 + nVidia GeForce GT 650M (Kepler GK107) graphics MBP11,1 was Haswell platform running with Intel Iris 5100 graphics only MBP11,3 was Haswell platform running with dual Intel Iris Pro 5200 + nVidia GeForce GT 750M (Kepler GK107) graphics MBP11,5 was Haswell platform running with dual Intel Iris Pro 5200 + AMD Radeon R9 M370X (Tropo GCN1.0) graphics and that: Precision M4800: nVidia Quadro K1100M is Kepler GK107 nVidia Quadro K2100M is Kepler GK106 AMD FirePro M5100 is Venus GCN1.0 Precision M6800: nVidia Quadro K3100M is Kepler GK104 nVidia Quadro K4100M is Kepler GK104 nVidia Quadro K5100M is Kepler GK104 AMD FirePro M6100 is Saturn GCN2.0 it may be worth looking into the SMBIOS matter again even as a desperate last attempt. Can't remember if that were ever considered or looked into in the past. NB: MacBookPro11,x were last Mac laptops fitted with nVidia graphics to date.

If you're installing 10.15.4, that's normal because my pack contained an XCPM-enabled Clover config. 10.15.4 breaks this as stated in our article about the update. You need to revert to good old SSDT-based power management method using the attached config + your CPU-specific SSDT generated using Pike R Alpha's well-known script: config.plist.zip The guide has just been amended to that effect.

As stated in our March 2020 news article, 10.15.4 breaks XCPM capability. If you used that, revert to good old CPU-specific power management SSDT generated by Pike R Alpha''s well-known generator script. Revised Catalina pack #2 provided to that effect. But, as suggested by @Bronxteck, XCPM should be back with Clover r5117 or above. I certainly verified this with r5118. Clover_r5118.pkg.zip

Broadcom BCM43224 14e4:4353 is subject to whitelisting: And, very obviously, those DW1820A-related injected properties do not apply to your Apple card so remove them. It's always essential to pay attention to full computer's hardware specs, especially when re-using someone else's config files...