Hervé

One has to wonder why you'd follow a guide for AMD Ryzen desktop where the guy clearly states "this will not work for a laptop"... We've got existing guides available for E7x50 in our Guides section and I would suggest you consult them. Eg: https://osxlatitude.com/forums/topic/8514-dell-latitude-e7450-uefi-only-clover-and-opencore Our FAQ section also contains hints and tips re: making an installer from Windows.

Nice little toy! Make sure to select "French PC" keyboard. Then you may obtain the "@" character through either [ALT][à] or [Win][à] depending on whether you've swapped Option and Command keys or not. Regarding your OpenCore setup, you may seek inspiration from the Big Sur guide I posted for my Toshiba Satellite Pro R50-B. It's a similar type of Haswell platform with i5-4210U & HD4400 graphics. Obviously not all kexts are applicable to your HP laptop since it has different audio/LAN/wifi/etc. but most of the OC config should be re-usable, especially the Quirks. One parameter that I expect you'll specifically require will be Lapic kernel patch (because it's a HP platform).

Can you please post the detailed specs of the computer? Touchscreens usually are USB-based so if yours does not work after sleep, it's indeed a USB-related problem.

All Latitude E6x30 with Intel HD4000 graphics can run macOS Big Sur without any trouble. Update your BIOS from very old A02 to latest version to begin with. Then follow any existing Big Sur guide for the E6x30 models, there are a few on the forum. These Latitude models are 100% supported (with a fully compatible Wireless/Bluetooth card of course).

The only alternative to the kexts mod or FakeSMC injection (by far the best method to me) I can think of would be to apply an on-the-fly Info.plist patch for the target kext through your bootloader config. The patch would consists of replacing the vendor and device ids of an existing model entry by the Intel ones.

New version v2.5 released. Minor update to display a different SD card icon.

Index 1 would be con0. I'm a little surprised with stated BusId 1 and Pipe 18 as there is no such native thing in any CFL framebuffer layouts, nor in any KBL or ABL layouts.

No, that's impossible. What you're dealing with is NVRAM.

Can't say more; wrong settings somewhere for sure... Maybe undesired add-on kexts in /S/L/E or /L/E. Check those out and clean-up as required..

Surely, it couldn't be just that! More likely some mistakes or conflicting settings given that OP stated he's mixing 2 x different set of configs and, ouch!, that set of kext patches! @Ahmadfini start by removing those AppleHDA patches... Can't understand why you made those ACPI & Kext patches changes. Rest assured the config posted in my guide works 100% for all E6220 as long as you follow the posted process.

No, DW1820 is unsupported. Don't go for that and don't confuse that card with the DW1820A.

The error message you get is an indication from OpenCore that something is wrong with your setup in relation to CodecCommander kext injection: either the kext or its Info.plist is missing in your OC EFI kexts folder or it is incorrectly defined in terms of PlistPath in the OC config. If you look into what you downloaded, you'll notice that OC EFI kexts folder does not contain no CodecCommander kext. So you either download it from the Web and install it in the folder or you remove the injection of that kext in your OC config (kernel section). OpenCore is without pity on kexts injection. Get anything wrong in the slightest way and it just won't boot. A true lesson of rigor...

Yes, you're expected to disable that unsupported Maxwell dGPU with that SSDT. If you don't, your battery will just drain out quicker.

You need to inject the required properties for your Broadwell HD5500. Follow the configuration you'll find in existing guides for Broadwell laptops that are available on the forum. You may also consult the WhateverGreen manual for guidance. Not much further we can provide until you post a zipped copy of your bootloader EFI folder or config for checkup. Given that HD5500 iGPU of i3-5005U CPU carries id 0x1616, all you would normally require in terms of properties injection for iGPU@2 would be: framebuffer-patch-enable 01000000 DATA framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA WhateverGreen kext then taking care of everything, including the correct BDW framebuffer layout. SMBIOS MBP12,1 of course!

Values for DATA type properties are specified in reverse byte order and, usually, as WORDs of 32bits (i.e. 8 x hexadecimal characters). If you look at the specs of your Intel i7-6820HQ CPU, you'll see that its HD530 iGPU carries id 0x191b. In order to obtain graphics acceleration on Skylake (SKL) HD530, you must: changed iGPU id to 0x1916. use layout 0x19160000 Since these values are injected as 32bit hexadecimal WORD in reverse byte order, you must use 16190000 and 00001619 respectively. If you look at the other injected properties: framebuffer-fbmem = 00009000 -> 00009000 equates to hex 0x00900000 which is 9437184 in decimal, i.e. 9*1024*1024 or 9MB framebuffer-stolenmem = 00003001 -> 00003001 equates to hex 0x01300000 which is 19922944 in decimal, i.e. 19*1024*1024 or 19MB You can read all about graphics framebuffers and injected properties in the WhateverGreen manual. Be careful as -again- most DATA properties are entered as 32bit WORDs, i.e. 8 x hexadecimal characters. In that respect, the 9 x character value you posted for framebuffer-stolenmem (000030001) was incorrect but that was clearly just a typo since it was Ok in your config file. The other important part you need to understand with regards to property injection is the location/device at/to which you apply the injection; it's the left part of the injection screen in tools such as Clover Configurator or OpenCore Configurator. This must be right or you may inject properties at the wrong place which may result in undesired side-effects and may lead to operating system crash/KP. These locations are related to chipset and manufacturers choices of hardware implementation. For instance, in a laptop, the integrated GPU (iGPU) is always located at IO address 0x00020000 (or @2) and the discrete GPU (dGPU) is always located at IO address 0x00010000 (or @1). When you inject properties in your bootloader config, this is expressed as: PciRoot(0x0)/Pci(0x1,0x0) PciRoot(0x0)/Pci(0x2,0x0) In the same respect, the audio controller is often found at IO address 0x001b0000 (or @1b); again this is expressed as: PciRoot(0x0)/Pci(0x1b,0x0) LAN card can often be found at 0x00190000 which is expressed as: PciRoot(0x0)/Pci(0x19,0x0) Sometimes, devices are located under secondary root bridges. This typically applies to hardware accessories such as SD card reader or wireless card; for instance you could find a card reader located at 0x0 under a root bridge located at address 0x001c0005 or a wireless card located at 0x0 under a root bridge located at address 0x001c0000; in such instances, this is expressed as: PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0) To identify the location of any given device of the PCI bus (or in IO), you may use tools such as IORegistryExplorer, IOJones or other such as Hackintool, etc. Or you may open up your DSDT with tools such as MaciASL but this is a little more tricky and requires more computing knowledge.

Not necessarily but no point in wasting your time. It's been written dozens of times on this forum: E6410 with Intel graphics is unsuitable/unsupported. Do think of searching the forum before posting next time.

You'll find a thorough guide re: Catalina (& Mojave) on the E6410 nVidia model at InsanelyMac. Tesla dGPU is not officially supported past High Sierra but patches can be installed to obtain OpenGL-only graphics acceleration (as was described in my D630 guide and our unsupported GPUs thread if you're interested). Note that, past-10.15.3, you need to use the dosdude1's patcher. The model with 1st gen Intel HD graphics (aka GMA HD) is unsuitable as a Hackintosh because graphics are unsupported (due to eDP screen connector). See the old 1st gen Intel HD bible at Insanelymac.

Why don't you keep Firevault aside until you obtained a properly working Hack? You can work on enabling FireVault subsequently.

Unless you have specific issues related to the errors reported in the log, I suggest you just ignore those; remember that you're running a Hack, not a Mac...

You Clover setup is incorrect and your config therefore needs to be revisited and adjusted. In particular, remove that "Drop OEM" for SSDT and remove those "Generate P states" + "ASPN" + "APLF". These are not applicable to a Haswell laptop. In addition, there should be no need to apply "Patch APIC" + "DisableASPM" + "FixIPIC" + "FixSATA". On the other hand, unless you've patched your DSDT to that effect, you'll need "FixDarwin7" to have USB3 working. God only knows what else may need revisiting... NB: Please don't quote messages to post direct replies; use the Reply box at the bottom of the pages; thank you.

So, you wake to a dark screen. It's therefore a wake issue, not a sleep issue. It really is necessary to be specific when dealing with Hackintosh matters you know... 3 x things: you could wait up to 5mins and see if the screen lits up (I experienced this on my E6440 when I still had it) experiment with darkwake=n boot arg to your config (where n=no|1|2|3|4|8|10) add boot arg igfxonln=1 to your config

According to Dell's own documentation, Haswell E5540 is fitted with regular (not I2C) Alps Touchpad; as such: try Dr Hurt's VoodooPS2Controller R6 to begin with add the SSDT-BRT6 to your config in parallel

The BRT6 ACPI patch, whether implemented as a DSDT patch or a dedicated patched SSDT, has worked on all my recent Dell Hackintosh laptops: E6230, E6440, E7250 and 7490. I would therefore expect it to be applicable to your Haswell E5540 too. It's totally unrelated to USB ports (you posts were moderated to that effect in order to avoid all possible confusion) and it's not related to the PS2 kext used either; why? Because, if I use/used DrHurt's R6 kext on my E6230/E6440/E7250, I had to use a different kext on the I2C-based Latitude 7490 and the BRT6 patch was still effective.

EFI appears a little odd: you use the EC SSDT patched table for a laptop rather than desktop you apply the IOHIDFamily patch for -SingleUser function which usually only applies to OpenCore on legacy BIOS systems Anyway, please describe what the sleep issue is exactly. For instance: computer does not engage any sleep action at all (everything stays as is) or computer tries to go to sleep, screen goes off but computer wakes immediately; things like that.

2 x comments: Microphone is under the control of the audio driver, whether you use AppleALC (which works with AppleHDA) or VoodooHDA (which disables AppleHDA). Then, it's down to a matter of the kexts having the correct definitions for the Codec. No such thing as a "microphone EFI". Please search the forum before posting as your issue has already been reported and addressed here.