Hervé

And full of bugs...

You probably to redefine your USB ports mapping correctly with Hackintool app.

Nope, unsupported; that'll be High Sierra minimum...

Make sure you're using a vanilla USB installer, not a distro (for which you'll find no support here). If so, please post your zipped Clover EFI folder. Consult our existing guides related to other Haswell Latitude laptops such as the E6x40 or E7x40 family for guidance. You should also read the existing E5540-related threads.

Excellent this screw thingie if it weren't laughable! Though not sure this is what the OP was writing about (no mention of poor system performance). As for iGPU idling at 0MHz, I confirm that it's not possible. If using Intel Power Gadget, maybe OP confused OS required graphics frequency and actual iGPU frequency... Here's the registered behaviour of the HD4000 iGPU of the i7-3540M of my idle Latitude E6230 under Catalina 10.15.6: https://ark.intel.com/content/www/us/en/ark/products/71255/intel-core-i7-3540m-processor-4m-cache-up-to-3-70-ghz.html http://www.cpu-world.com/CPUs/Core_i7/Intel-Core i7-3540M (PGA) Mobile processor.html OP did not indicate anything on his E7240 specs or post an IOReg extract, so maybe it's just a matter of having an AMD dGPU fitted but not disabled... Who knows?

Please read our Catalina Requirements thread pinned to "Our Picks" list on forum main page. Make sure you've done the necessary re: Embedded Controller.

No, iGPU does not run at 0MHz when idle; lookup your CPU specs on Ark Intel web site or CPU World. iGPU frequency range is usually detailed. It's a dGPU that you disable if fitted and unsupported. I'd say your battery drain issue has more chance to result from your incorrect CPU power management settings: You have a Haswell platform so all you need is: ACPI tab: Plugin Type set to 1 PluginType enabled Kernel & Kext Patches: KernelPm (you can keep AppleRTC patch of course!) Nothing else. So remove those incorrect SSDT drops (especially as you're not using any CPU-specific generated SSDT) and those C-States you've enabled. Also, what is that SSDT-PNOT table you use? Not necessary to me...

Pike R Alpha's well-known ssdt generator script.

@Lego, can you please try and write everything in a single post than keep this very annoying trend of posting a new message every 30s? Maybe wait a few mins from now on... Or use the "Edit" button... Thank you.

Everything looks good to me now in that IOReg of yours: Can't see why you'd have Bluetooth issues. Try and disconnect that wireless USB adapter just in case it interferes...

No, Bluetooth chipset BRCM20702 is supported OOB. Do you have any other built-in BT device in that computer? If so, disable Bluetooth in BIOS. Your screenshot does not show any transport controller kext loaded so there's clearly something wrong with the module or, maybe, your OC configuration (can't help you with that)... Did you connect your module to an internal USB port? That's obviously required. Here's what you would normally expect to see in IOReg: I've checked Catalina 10.15.6's BroadcomBluetoothHostControllerUSBTransport kext and it does cover your device (0x821f, i.e. 33311 in decimal) so all is Ok on that side. Could you please post a zipped copy of a saved output?

As stated in our wireless cards inventories, BCM43224 (14e4:4353) cards such as your BCM943224PCIEBT2 are subject to whitelisting; so you either patch the associated kext to replace a supporting Mac model by that of your elected SMBIOS model you use or you change your SMBIOS by that of a model supported by the whitelist. Please consult the pinned dedicated patching guide on this matter which is available in this very Wireless & Bluetooth forum section. Re: Bluetooth, same story as for the Wireless,; it's an Apple card so no add-on kext required, it should be natively supported.

A zipped copy of your Clover EFI folder for instance... I fear you might be using the i5-5300U CPU power management SSDT posted in my pack rather than your own generated one for your i7-5600U. Make sure your BIOS is also configured as per the recommended settings.

Why don't you write a guide describing the procedure you followed instead? And share a copy of the OC EFI folder you used along the way?

No! https://en.wikipedia.org/wiki/PCI_Express

Model with eDP LCD connector-type it would seem and 3K display. Ace.

If you already have High Sierra, then it's a "simple"' matter of following the 1st gen Intel HD guide and adjusting the graphics settings for 10.13 and your screen resolution. Discussions about support for 1st gen Intel HD graphics started on p68 in the bible thread. Read on, I'm sure details are provided throughout the subsequent pages. https://www.insanelymac.com/forum/topic/286092-guide-1st-generation-intel-hd-graphics-qeci/?page=68

No such files and/or folders were posted here. Looks like the only proper guide we have for this model is Jake Lo's Mavericks guide which dates back to many years ago. T410s is an ageing laptop with 1st gen Intel HD graphics iGPU or Tesla nVidia graphics dGPU. As you probably know, this iGPU always required specific tuning to be supported on Hackintosh and this support was only under conditions (see Bible on 1st gen Intel HD at InsanelyMac). 1st gen Intel HD graphics are last officially supported in macOS High Sierra; abandoned in Mojave/Catalina due to lack of support for Metal as are nVidia Tesla GPUs and Intel HD3000. There are tricks that can be implemented to obtain partial and OpenGL-only graphics acceleration on those dropped GPUs. My advice would be to go for macOS High Sierra to begin with and build a working Clover setup before you attempt any more recent versions like Mojave or Catalina. Please post your laptops full hardware specs (CPU, graphics, screen resolution, audio, LAN, wireless, etc.) and we'll try and help you build a Clover setup. Is the BIOS legacy only or does it support UEFI mode?

I've never seen anyone booting Clover via OC ! Anyway, your OC setup is clearly what's causing your issue since you do not experience it when booting Clover directly. I'd say some incorrect settings under the Kernel section.

The FB mem. size patch is detailed in our HD4000 patching guide In the R&D->Graphics forum subsection. You can look it up. I've never used OC myself but you would implement the patch either as a property injection under DeviceProperties (may be difficult for you) or as a kext patch under Kernel->Patch (you have existing patches you can refer to).

Startup and shutdown glitches, you'll have to live with. They're totally negligible and can be ignored. For the other stuff you've filmed, you may try the Capri framebuffer memory size reduction from 16 MB to 8MB. I could not see any Capri FB patching in your OC config so no idea which patches your meant above...

For the sake of clarity: posts relating to Catalina were split to their own thread here. Clover r5119 Catalina EFI folder attached to Baio77's original (Catalina) thread here. this thread, obviously relating to Big Sur beta, was moved to this macOS Preview section. Guys, please refrain from mixing topics/versions, Catalina and Big Sur beta being 2 x different OS requiring very different configs to say the least!

Better later than never... As explained in past system/model-specific threads, there are further patches that may be used to modify the framebuffer memory size (useful on Latitude E6x30) and the VRAM allocation (nice to increase). Of course, WhateverGreen supports property injection (through DSDT/SSDT patches or bootloader configs) as a more efficient alternative to rather old-fashioned framebuffer kext binary patching. Those parameters are defined in the 2nd line of the sample Capri layouts we've illustrated throughout this thread (bearing in mind the reversed byte order of kexts' binary code). For instance: LoRes mobile layout 0x01660003: 03006601 01020402 00000004 00000001 00000060 10070000 HiRes mobile layout 0x01660004: 04006601 01030101 00000002 00000001 00000060 10070000 Desktop layout 0x0166000a: 0A006601 00020302 00000002 00000001 00000060 10070000 Desktop layout 0x0166000b: 0B006601 00020302 00000002 00000001 00000060 10070000 1) Framebuffer memory size: This is defined in the 4th 32bit parameter of the layouts. Default value is 0x01000000 (reversed code 00000001), i.e. 16777216 in decimal which, when divided by 1024*1024 (=1MBytes), equates to 16MB. Some laptops such as the Dell Latitude E6x30 models suffer from corrupt/garbled display on screen unless this value is reduced to 8MB, i.e. 0x00800000. The patch required to change this is: Find: xxxxxxxx [...] xxxxxxxx 00000001 xxxxxxxx [...] xxxxxxxx Replace xxxxxxxx [...] xxxxxxxx 00008000 xxxxxxxx [...] xxxxxxxx For instance, to reduce the FB mem. size of layout 0x01660003 to 8MB, use this patch: \/\/ Find: 03006601010204020000000400000001 Replace: 03006601010204020000000400008000 /\/\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA 2) VRAM allocation: This is defined in the 5th 32bit parameter of the layouts. In most recent versions of OS X/macOS, the default value usually is 0x60000000 (reversed code 00000060), i.e. 1610612736 in decimal which, when divided by 1024*1024 (=1MBytes), equates to 1536MB (i.e. 1.5GB). This is shared memory and systems with, say, 8GB of RAM, may want to increase this. The patch required to do this is: Find: xxxxxxxx [...] xxxxxxxx 00000060 xxxxxxxx [...] xxxxxxxx Replace xxxxxxxx [...] xxxxxxxx 000000YY xxxxxxxx [...] xxxxxxxx -> where YY = desired VRAM Qty Reminder: 256MB = 1000 0000 in hex 384MB = 1800 0000 in hex 512MB = 2000 0000 in hex 768MB = 3000 0000 in hex 1024MB = 4000 0000 in hex 1536MB = 6000 0000 in hex 1792MB = 7000 0000 in hex 2048MB = 8000 0000 in hex For instance, to increase VRAM allocation of layout 0x01660003 to 2048MB (i.e. 2GB), use this patch: \/ Find: 0300660101020402000000040000000100000060 Replace: 0300660101020402000000040000000100000080 /\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-unifiedmem 00000080 DATA Naturally, those framebuffer modifications can be combined in a single patch. For instance, to reduce FB mem. size to 8MB and increase VRAM to 2GB, layout 0x01660003 is patched as follows: \/\/ \/ Find: 030066010102040200000004000000010000006010070000 Replace: 030066010102040200000004000080000000008010070000 /\/\ /\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-unifiedmem 00000080 DATA

Replace your Intel wireless card by a supported model.