Hervé

No.

Simply boot through your original USB installer (assuming you still have it of course).

It's a high-end GCN4.0 card, probably in the USD $150-$200 price range these days. Good for Mojave too. It really depends on what you want to do with it. For a fraction of the price (say USD $50), you can probably get a Kepler GT730 which will roughly provide similar performance as the GTX460 and is Mojave compatible too. Higher Kepler cards will do great too. I would have loved to recommended Pascal cards (I have a low-end GT1030 in my Vostro200 for High Sierra) but these are not Mojave compatible...

It's a Fermi card (GF104). https://www.techpowerup.com/gpu-specs/geforce-gtx-460.c265 I've no personal experience with that model but, afaik, like many other Fermi cards (eg: GT610, GF108), it does not work beyond El Capitan.

Which is basically the same as what I experienced with the Foxconn T77H649.... All in all, the only model which really appears to work perfectly is the 0VW3T3 model with subsystem id 1028:0021. The others simply aren't reliable.

Back in 2015 , when Apple introduced SIP protection in El Capitan, I quickly had a look at the SIP settings and associated CsrActiveConfig 8bit values in Enoch: nibble: 4 3 2 1 | 4 3 2 1 bits: - - - - | - - - - | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | \ Dev. Prot. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Prot. / \ Task Prot. Apple Int. Kernel Debug. Source: csr.h (in bsd/sys folder) of 10.11's published XNU source code at https://opensource.apple.com/ On the basis/assumption that Apple Internal & Device Configuration could be kept disabled by default (bit set to 0), CsrActiveConfig could be set to: 0000 0011 in binary, i.e. 0x03 (3 in decimal) to disable kext signing and filesystem protection 0110 0011 or 0110 1111 in binary, i.e. 0x63 or 0x6F (103 or 111 in decimal) to disable all protections that mattered If I booted Enoch in verbose mode with CsrActiveConfig=103 (i.e. 0x63), the displayed info showed: System Integrity Protection status: enabled (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state. At time of writing, in the days of Clover and Catalina, most people still use CsrActiveConfig 0x63 and that's fine. But there are also more flags to control SIP than there used to be in El Capitan: Sierra added a 9th flag for Any Recovery OS High Sierra added a 10th flag for Unapproved Kexts Mojave added an 11th flag for Executable Policy Override SIP is therefore arranged as follows: nibble: #3 | #2 | #1 nibble bits: 4 3 2 1 | 4 3 2 1 | 4 3 2 1 bits: 12 11 10 9 | 8 7 6 5 | 4 3 2 1 - - - - - - - - - - - - N/A | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | | | | | Policy Over. / | | | | | | | | | Kext App. / | | | | | | | | Recov. OS / | | | | | | \ Device Config. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Rest. / \ Task for PID Apple Int. Kernel Debug. where: Bit #1 = Allow untrusted kexts Bit #2 = Allow unrestricted FileSystem Bit #3 = Allow task for PID Bit #4 = Allow kernel debugger Bit #5 = Allow Apple internal Bit #6 = Allow unrestricted DTrace Bit #7 = Allow unrestricted NVRAM Bit #8 = Allow device configuration Bit #9 = Allow any recovery OS Bit #10 = Allow unapproved kexts Bit #11 = Allow executable policy override Bit #12 = N/A Source: csr.h (in bsd/sys folder) of Mojave 10.14's published XNU source code at https://opensource.apple.com/ Whilst the original CsrActiveConfig of 0x03 or 0x63 remains valid by far and large to most hackintoshers, some folks may also want to allow unapproved kexts on top of unsigned kexts. Keeping the same flags as for CsrActiveConfig 0x63 alongside, this would lead to a new value of 0010 0110 0011, i.e. 0x263 or 611 in decimal.

@wtv1234, yes, you inject the compatible statement through the Clover Properties injection, otherwise, the Brcm4360 kext won't load since PCI id 14e4:43a3 is not natively supported by that kext. Basically, in order for the Brcm4360 kext to load, you either inject the compatible statement as per my guide or you manually patch the kext's Info.plist file to add the PCI id of the card. Obviously, former is easier and more sustainable than the latter.

All is working fine here. I updated through the update PrefPane offer. The difference on my 7490 is that I don't inject kext through Clover, I cache them from /L/E (as I always do). Regarding TouchPad, I have noticed that, on occasions, it just won't work after system has started/booted/rebooted and that it sometimes take a couple of reboots to be active again. Given the current state of I2C support, I live with it and use an external mouse most of the time anyway.

Are you using the pack I posted in y guide? My update to 10.14.5 was a piece of cake.

Glad that you're experiencing the same as I did; it's consistent. Regarding speed, I guess it'll depend on whether your wireless network is setup for DFS, 5GHz, etc. I'm getting connections to my 5GHz network at 867Mbps consistently with the various cards I've tested, then my Internet speed tests cap at 300Mbps which is the limit of my fibre subscription. Therefore, all is well on that front. NB: Let's keep this thread on-topic. If you have other issues, please open up a separate thread.

It's a pity... Now let's wait for muttonhead411's tests feedback.

Ok, all is fine; I was just wondering if "Wake for network access" was not enabled; but it is not...

Behaviour is identical with or without the brcmfx-country boot option and whether declaring compatibility with Broadcom card 14e4:4353 or 14e4:4331. I've been using the CN-096JNT card for well over 1hr now and, apart from those odd brief disconnections, all is Ok.

Please post a screenshot of your Energy Saver PrefPane.

Clearly, those USB3.0 ports are not setup properly. Maybe the XHC SSDT you use is not entirely appropriate to your model. I have not checked.

Are you sure it's a USB3.0 dongle for a mouse? What speed does it report at in SysProfiler/SysInfo->USB?

Did you check your power management settings (Terminal command pmset -g + Energy Saver PrefPane)?

Well, it's been over 20mins and the CN-096JNT has not killed the laptop. That's a huge difference! However, it's not entirely kosher because, in that period of time, I experienced 2 x wireless disconnections accompanied brief and partial system freezes until the wireless reconnected automatically. During the short freeze, my external USB mouse was unresponsive but my TouchPad was still active. Will have to look in the longer term and, possibly, just remove the brcmfx-country=#a option I went with. To be continued...

Not much guidance needed, come on! Inject or cache AirportBrcmFixup kext and add those 2 x boot options visible in DalianSky's Clover config. That's the only things that differ, the properties injection detailed in my guide are otherwise strictly identical. I'm now testing this with my CN-096JNT model which caused issue usual overload/freeze issues when initially tested in my 7490.

Same thing for @muttonhead411: the sticker of your card does not match the hardware specs and the real MAC @ differs from the sticker's ! So, no, it's not a DW1820a 0VW3T3 model. This being said, it's interesting that you report that the 1028:0023 model works for you. You're using AirportBrcmFixup + boot option brcmfx-driver=1 as I had suggested a few weeks ago and I'm wondering if you could test it without AirportBrcmFixup + the associated boot options and tell us how it goes. It may well be that, for those cards that end up clogging the Hackintosh to a halt, It's actually required. I'm going to try that with the CN-096JNT model I recently acquired.

Battery status disappearing is very common on those older Latitude models (eg: E6x30, E6x40, E7x40). It's probably due to some missing battery DSDT patch required for Rehabman's ACPIBatteryManager kext to work properly. No idea about the patch, never looked into it.

You may refer to the wikidevi link provided in our wireless inventories for details of the DW1820a (not to be confused with DW1820).

WWAN antennas are too short for the WLAN slot in the 7490. DW1560 is a better alternative than the DW1830. NB: I purchased my DW1820a off the well-known auction site; I'll send you details of the seller by PM.

CPU model does not matter, except in the the case where you would try to re-use the CPU-related power management SSDT of another CPU. That would not work. Now, don't get confused. Pike R Alpha's SSDT generator script is ONLY for CPU power management. Nothing else. So, if you wanted to modify other items such as USB ports or dGPU via SSDT, you need to create/add further tables. HWMonitor works with FakeSMC plugins. There are several of them: ACPISensors CPUSensors GPUSensors LPCSensors SMMSensors to name those that accompany Rehabman's latest versions of FakeSMC. These plugin kexts can be located alongside FakeSMC or inside a PlugIns subfolder within FakeSMC. If you only have a subset of them, the info displayed by HWMonitor will be reduced accordingly.

Topic title modified accordingly.