Hervé

What are your current SandyBridge settings? Fake iGPU id 0x01268086? Inject Intel? ig-platform-id xxxxxxxx? SMBIOS macmini5,1 ? You ought to choose one of the following HD3000 layouts in Clover, unless you inject this through DSDT of course:

Hmm... Try and remove all traces of cache before rebuilding it using Jake's commands above: sudo rm -Rf /S*/L*/PrelinkedKernels sudo rm -Rf /S*/L*/Caches/com.apple.kext.caches

You'd be better off replacing this DW1707 which has very poor support by a properly supported card like a DW1560 or DW1830.

I would have expected the HD3000 of your i3-2105 CPU (not i5) to be supported, at worst with faking GPU id of another HD3000 iGPU known to work under OS X (eg: mobile HD3000 0x0116 or 0x0126). When I come to think of it, it reminds me of this IM thread, where the OP had trouble getting graphics acceleration off his desktop HD3000 until he faked id of mobile HD3000 and found the correct layout-id. With regards to 3rd gen CPU/GPU, Bronxteck stated that his own system worked Ok with upgraded IvyBridge CPU, so that answers your question I guess.

KP = Kernel Panic. The crash you mentioned...

For audio to work, you need to: install ALC292 dummy kext (preferably in /L/E) and rebuild your cache inject audio layout-id 1 in DSDT device HDEF patch the vanilla AppleHDA kext as follows: replace 8419D411 by 9202EC10 replace 8508EC10 by 00000000

Moved to correct forum section...

I would not expect so but there is no reason to use VoodooHDA when the ALC292 AppleHDA patch for the E6x40 has been available for the last 4 years... Again, make sure you do not have any duplicate (and incorrect) PS2 controller kexts or settings that could affect your keyboard/trackpad.

Check for other copies of a PS2 controller; sounds like you have conflicting kexts somewhere... That kext works perfectly on all E6xx0, I can vouch for it.

Kext Wizard is a very old tool that probably no longer rebuilds kext cache properly under recent/modern versionsof OS X/macOS. Remove the kext from Clover's EFI folder, copy the kext to /L/E then manually repair permlssions and rebuild your cache. There's a dedicated thread to this matter in the FAQ section.

Yes, will try and patch your tables later.

Here are copies of those extracted ACPI tables renamed to ".aml". M2800_APCI_tables.zip As shown in DSDT: iGPU HD4600 is located at usual address 0x00020000 under device PCI0.GFX0 Device (GFX0) { Name (_ADR, 0x00020000) // _ADR: Address dGPU FirePro W4170M is located at usual address 0x00010000 under device PCI0.PEG0.PEGP Device (PEG0) { Name (_ADR, 0x00010000) // _ADR: Address [...] [...] [...] Device (PEGP) { Name (_ADR, Zero) // _ADR: Address ` Those GPUs are further detailed in SSDT-5 and SSDT-6 tables: In SSDT-5, there is a basic initialisation method that does not do more than attributing sub-address 0 to the dPU under the PCIe graphics #0 at address 0x00010000: Scope (\_SB.PCI0.PEG0.PEGP) { [...] Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (Zero, \_SB.PCI0.PEG0.PEGP._ADR) } [...] } in SSDT-6, there are 2 x methods (=functions) defined to turn the dGPU on and off: Scope (\_SB.PCI0.PEG0.PEGP) { Method (_ON, 0, Serialized) // _ON_: Power On { SGON () Notify (\_SB.PCI0.PEG0, Zero) } Method (_OFF, 0, Serialized) // _OFF: Power Off { SGOF () Notify (\_SB.PCI0.PEG0, Zero) } } ` The 1st step towards patching your tables is to modify SSDT-5 to initialise the dGPU to off. To achieve this, we simply declare the _OFF function as external (i.e. defined elsewhere) at the top of the table before we add it to the _INI method: External (_SB_.PCI0.PEG0.PEGP._OFF, MethodObj) // Declares external method _OFF [...] [...] [...] Scope (\_SB.PCI0.PEG0.PEGP) { [...] Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (Zero, \_SB.PCI0.PEG0.PEGP._ADR) _OFF () // Turns AMD dGPU off } [...] } ` The 2nd step is to add a new EPOF method to that SSDT-5 table so that the dGPU is no longer reactivated on wake from sleep, as configured by default. Indeed, the vanilla DSDT shows the following code: External (_SB_.PCI0.PEG0.PEGP.EPON, MethodObj) // Warning: Unknown method, guessing 0 arguments External (_SB_.PCI0.RP05.PEGP.EPON, MethodObj) // Warning: Unknown method, guessing 0 arguments and Method (_WAK, 1, Serialized) // _WAK: Wake { P8XH (One, 0xAB) WAK (Arg0) ADBG ("_WAK") If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON)) { \_SB.PCI0.PEG0.PEGP.EPON () } If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) { \_SB.PCI0.RP05.PEGP.EPON () } } [...] } NB: You can confirm this through IOReg afterwards but you'll probably find that device RP05.PEGP does not exist, i.e. those lines of code related to _SB_.PCI0.RP05.PEGP.EPON are incorrect. I had the same in my E6440 DSDT and I've seen the same in E6540 DSDT too. Typical example of poorly coded DSDT... As such, these lines can be removed without any side effects. The EPON method is defined in SSDT-5 as follows: Scope (\_SB.PCI0.PEG0.PEGP) { [...] Method (EPON, 0, Serialized) { Store (One, ONOF) Return (Zero) } [...] } There is no EPOF method, so we're simply going to add one that will do the opposite of EPON, i.e. store 0 to ONOF: Scope (\_SB.PCI0.PEG0.PEGP) { [...] Method (EPON, 0, Serialized) { Store (One, ONOF) Return (Zero) } Method (EPOF, 0, Serialized) // New EPOF method { Store (Zero, ONOF) // Stores 0 to ONOF parameter Return (Zero) } [...] } ` Once that is done, we can modify the DSDT to actually turn off the dGPU on wake. This is achieved by replacing the above EPON declarations + WAK method in the DSDT by the following code: External (_SB_.PCI0.PEG0.PEGP.EPOF, MethodObj) and Method (_WAK, 1, Serialized) // _WAK: Wake { P8XH (One, 0xAB) WAK (Arg0) ADBG ("_WAK") If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPOF)) { \_SB.PCI0.PEG0.PEGP.EPOF () } } [...] } ` That should be it. Place copies of the patched tables in your Clover ACPI/patched folder and call them by inserting the following list in your Clover config's ACPI "sorted list" section: SSDT.aml SSDT-5.aml SSDT-6.aml

Mieze's own driver is probably more up to date. https://github.com/Mieze/IntelMausiEthernet This being said, look at the reported issues and report your own (in details) if necessary... https://github.com/Mieze/IntelMausiEthernet/issues

Use latest PS2 controller kext R6 (compiled by Bronxteck) available here.

Make sure to repair kexts permissions to /L/E before you rebuild the cache or it'll be ineffective. There's a dedicated thread to that matter in the FAQ section...

I'd say it's your installation package that's dodgy here. Maybe you should download it again...

Arf! You simply edit the entry in your Clover config.plist. Either through a text editor or Clover Configurator app (ACPI tab). But I don't think this is the cause of your issue because that table appears CPU power related...

Webcam are internal USB connected on those laptops and will work OOB when/if supported. If the camera worked before and no longer does under Sierra, then your USB ports are probably not all recognised. Make sure you've applied the usual ACPI patches (renaming of EHCx devices to EH0x) and installed a USB injector kext. If you want further assistance, please post a zipped copy of your Clover EFI folder so that your settings can be examined.

No, you misunderstood. AppleIntelBDWGraphicsFramebuffer is an existing kext that is currently being used on your system to handle/control your integrated iGPU. You do not install any other version or anything of the sort. Once you have identified the port used by HDMI display through an app like IORegistryExplorer, apply the patch as described above through Clover. Use Clover Configurator app to that effect (in Kernel and Kexts Patches tab).

HDMI audio usually requires a binary patch of the graphics framebuffer layout so that the associated display port is set to HDMI connector-type 0008 0000. Please refer to the R&D->Graphics subsection of the forum for guidance (guides for Haswell HD4600 and/or IvyBridge HD4000 for instance) since we're dealing with integrated GPU here, not discrete GPU. You run on Broadwell HD5500 graphics with BDW framebuffer layout-id 16260006. If you look into your IOReg, you'll notice: Framebuffer@0 on port 0 with connector-type 02000000 (LVDS). You'll see the built-in LCD connected to that display port. Framebuffer@1 on port 5 with connector-type 00040000 (DP). Framebuffer@2 on port 6 with connector-type 00040000 (DP). Plug your HDMI display and check in IOReg which framebuffer/port it registers against. Then, in the Broadwell (BDW) framebuffer kext, patch layout-id 16260006 to change the port connector-type from 0004 0000 (DP) to 0800 0000 (HDMI). In 10.13.3, the layout-id is coded as follows: 06002616 01030303 00002002 00005001 // Layout 16260006 (06002616) 00000060 D90A0000 D90A0000 00000000 00000000 00000000 00000800 02000000 30020000 // FB #0/port #0 (0000), type LVDS (02000000) 01050B00 00040000 07050000 // FB #1/port #5 (0105), type DP (00040000) 02040B00 00040000 07050000 // FB #2/port #6 (0204), type DP (00040000) FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 ` If HDMI is on FB@1/port 5, patch the layout as follows: \/ Find: 01050B000004000007050000 Replace by: 01050B000008000007050000 /\ If HDMI is on FB@2/port 6, patch the layout as follows: \/ Find: 02040B000004000007050000 Replace by: 02040B000008000007050000 /\ ` You can either binary mod the actual BDW framebuffer kext directly with a hex editor (HexFiend for instance) or apply the patch, as described above, in Clover. Kext file is: AppleIntelBDWGraphicsFramebuffer.

What's the reason why legacy boot mode cannot be kept?

Are you latest Clover version? Should be something like r4411 or thereabout.

You can have a look at Jake's post #2 in this recent E6440 thread. Compare your own Clover settings and kexts lists with the contents of the E6440 folder and adjust if necessary.

The E6440 cousin crashes if you plug an HDMI cable without having previously patched the Azul Framebuffer. Could be the same for this mini-DP port on the E7440. You can refer to my HD4600 patching guide and, for DP output, post #2.

High Sierra USB installer is about 8GB, not under 6GB. Which is why you need a 16GB USB key, 8GB models being usually too small. If your own USB installer is just over 5GB, it's not properly made.