Hervé

It should not be required with Mojave but try and add the following boot arg if it's still valid: -disablegfxfirmware Failing that, I've no idea why my posted Mojave bootpack would no longer work. I no longer have a Latitude 7490 so won't be be able to help much any more. Check the logs for potential hints regarding the KP and subsequent reset you mentioned.

OS X/macOS does not support disk in RAID mode, you have to set it to AHCI as indicated in my BIOS thread. Can't remember if this also applies to NVME disks rather than just SATA disks but, yes, you should follow the recommendations posted in that thread.

It's good practice to keep threads on-topic... This being said, what do you mean by "don't detect HDMI"? HDMI video & audio output require tuning/patching on Haswell systems. Video output requires: patching pipe of HDMI port/connector (usually con1) to change it from 0x09 to 0x12 (or system will freeze/hang on connecting/disconnecting the HDMI cable) patching HDMI port/connector (usually con1) to change connector-type to HDMI (00080000) is recommended though usually only necessary for HDMI audio Audio output requires: patching HDMI port/connector (usually con1) to change connector-type to HDMI (00080000) injecting hda-gfx property to iGPU device renaming B0D3 device to HDAU You'll find sample configs in our HD4600 graphics R&D topic as well as in most if not all our guides for Haswell laptops or threads pertaining to HDMI output on Haswell laptops.

I would not have expected any downgrade to be required given that the 7490, when I had it, never suffered any issue related to BIOS upgrades and I did a few. You can safely go back to the latest version.

With OpenCore, I found that I had to re-install beta1 from scratch and set SecureBoot to "disabled" (instead of "default") to be able to update to beta2 without hiccup. But all is well now. Once initiated, the update to beta2 completed all by itself.

Did you set your BIOS according to the recommended settings?

The patched DSDT I had posted often gave problems so if it's still in the bootpack, remove it. Its sole purpose was to enable the brightness keys but there are other ways to achieve this.

2nd beta available. Build 21A5268h. A few little improvements like the return of GPU info in About This Mac or the refresh button in Safari. Bluetooth still buggy, especially after wake. We'll see what other improvements and new bugs it brings... Straight & easy update with Clover r5133 on my Skylake/HD520 Latitude E7270. Much more more complicated affair with OpenCore v0.7.0 on my Haswell/HD4400 Satellite Pro R50-B. From the 3rd reboot of the temp installation partition, laptop goes into a boot loop. On rebooting the original Monterey partition, system went through "xx minutes remaining", hinting the update was actually going through but, on reaching the Monterey desktop, back to beta1.

There would be so much to. say about your Catalina setup (especially the set of add-on kexts and the Clover config!) but, at least, you correctly used USBInjectAll kext + SSDT-UIAC table. These defined the USB ports of your E6440 laptops. You also used a patched DSDT in which specific power settings for your EH01 & EH02 USB2.0 controllers + XHC USB3.0 controller were also defined in dedicated _DSM methods: "AAPL,current-available", 0x0834, "AAPL,current-extra", 0x0898, "AAPL,current-extra-in-sleep", 0x0640, "AAPL,device-internal", 0x02, "AAPL,max-port-current-in-sleep", 0x0834 For Big Sur, you made a few additional mistakes: you did not use your previous patched DSDT -ok, why not?- and that would probably be Ok had you not made the choice of injecting SSDT-EC-USBX table (which is for Skylake & later systems) AND SSDT-EC table (which is for Broadwell and earlier systems). The trouble is that SSDT-EC-USBX injects the following power settings for USB ports: "kUSBSleepPowerSupply", 0x13EC, "kUSBSleepPortCurrentLimit", 0x0834, "kUSBWakePowerSupply", 0x13EC, "kUSBWakePortCurrentLimit", 0x0834 which are totally different settings the what you injected before. I would recommend you start by removing SSDT-EC-USBX table and all references to it in your OC config. I'd bet square prunes that your USB ports will work much better afterwards and that you'll no longer have power-related problems with your USB keys/storage devices. In addition, given that you've generated your USBMap kext, I'm not sure you still need the SSDT-UIAC table. Check that out but to me, it's either USBInjectAll kext + SSDT-UIAC table or USBMap kext (as it were with Hackintool-generated USBPorts kext).

Had a quick look at your posted EFI. your Kexts set is quite a mess with all sorts of kexts for LAN (no less than 8!). You would really need to sanitise this. Start by identifying your hardware. you said your were using patched UHD530 graphics for iMac17,1, yet your config shows you're using macPro7,1 SMBIOS. Why? iMac17,1 or MacPro7,1 are both compatible with Monterey. As such, no need for -no_compat_check boot-arg though it does no harm of course, just prevents macOS OTA update. you use a single patched SSDT table from Olarilla to patch ACPI; never seen that one before so can't really comment nor say if all is applicable to your own platform, it's not very common.

Are you using Heliport client too? Alternatively, try AirportItlwm https://openintelwireless.github.io

I meant whatever driver you may have added wherever to get your BT dongle working, what else?

Monterey normally boots with the exact same settings and config as Big Sur. Only Lilu & plugins are recommended for updates, failing what the -lilubetaall boot-arg & associates are required. If you believe your issue is Bluetooth related -and it could be of course-, unplug your dongle and remove all associated kexts you may have installed.

1st off all, you need to provide your system's specs (computer model, BIOS version, chipset, CPU, GPU, audio, LAN, wireless, etc.). Then you need to specify the boot loader you're using and its version Finally, post a zipped copy of your boot loader EFI No assistance can be provided without this minimum requirements. The only thing I can confirm is that Bluetooth is often problematic under Monterey beta1 so don't hesitate to disable it to begin with.

I'm tempted to say you're looking at brightness and brightness control the wrong way. Look up existing guides & threads related to the Latitude Exx70 models. Keep things simple and focused on the Latitude families. NB: As per our stated rules, which I invite to read if you've not done it yet, no links to forbidden sites and easy on the quoting!

Those values are the expected ones but you could always tried the other values that have been posted/mentioned for other various Dell models. Note that you would need to engage in complex technical analysis if you wanted to verify the ACPI codes returned by the Fn-Fxx key combinations for brightness control. Former Hackintosh expert Rehabman detailed the process on one of his GitHub repos. Alternatively: revert to the original SSDT-BRT6 table (with IGPU device for iGPU) rename GFX0 to IGPU in SSDT-PNLF-CFL table add renaming of GFX0 to IGPU in your OC config and test again. I would also suggest you test switching from SSDT-PNLF-CFL to SSDT-PNLF table, the one applicable to models of previous generations.

Monterey usually works with the exact same settings as with Big Sur. On the various laptops I installed it on (Latitude E6230/E7270, Satellite Pro R50-B): Screen brightness works the same in Monterey as it does in Big Sur (brightness level should be retained if you have a fully working NVRAM) Brightness control works the same in Monterey as it does in Big Sur Sleep & wake work the same in Monterey as they does in Big Sur DW1820A works the same in Monterey as it does in Big Sur (Tosh R50B & Lat E7270) Touchscren stopped working in Big Sur on my Skylake E7270 whilst it worked OOB in Mojave and Catalina; such Toushcreens are USB-based and fully detected/reported in SysInfo->USB As for TouchPad, it really depends on the model fitted to your laptop but I2C models are limited

I see a likely issue with regards to brightness keys: the SSDT-BRT6 patched table refers to IGPU device for the iGPU the SSDT-PNLF-CFL patched table refers to GFX0 device for the iGPU there is no renaming of GFX0 to IGPU in your OC config Lilu probably renames GFX0 to IGPU after that all tables have loaded and SSDT-BRT6 may not be properly applicable as a result Given that you have brightness control overall (although not through the expected keys), it's fair to say that SSDT-PNLF-CFL is fully operational. As such, do try and rename IGPU to GFX0 in SSDT-BRT6 table, recompile it and save it. That should hopefully fix the brightness keys.

You may experiment with other layouts specified for that ALC295 codec in the AppleALC wiki. I would also recommend you 1st add CodecCommander kext to your kexts set during your experimentation.

Much has been written for years and is known about Apple wireless cards based on the Broadcom BCM4360 chipset. Having been using BCM94360CD cards for years with mini-PCIe adapters in my old Latitude E6220 and E6230 laptops, I looked at the best possible Apple alternative for my Latitude E7270 fitted with 1 x Key A/E M.2 WLAN slot. Until now, I had been using 1st a BCM4350-based Dell DW1820A, then a Fenvi BCM94360NG card in this Skylake laptop. But I recently had the opportunity to buy an Apple BCM94360CS2 card for a handful of € and M.2 adapters for Apple BCM94360xxx cards cost pennies so I went ahead with it. Having received my Key A/E M.2-to-Apple adapter from China after a very very long wait, I proceeded to install the Apple Card in my E7270. It's easily achieved at the cost of a couple of minor and less minor limitations. 1) WLAN slot size and card size: the E7270 offers a classic M.2 WLAN slot that supports a Key A/E 2230 card (22x30mm). the BCM94360CS2 card is a little narrower than 22mm (about 17/18mm) but longer than 30mm (about 37/38mm). the M.2 adapter is 22mm wide but much longer than 30mm (about 46mm). as such, the adapter+BCM94360CS2 card package's length extends beyond the 30mm limit of the E7270 WLAN slot. 2) rubber piece: there is a piece of rubber lightly glued to the motherboard between the WLAN slot and its neighbouring WWAN slot. this rubber piece supports the top end of any M.2 2230 WLAN card, right under the securing metal bracket. this rubber piece gets in the way of the M.2 adapter and BMC94360CS2 card and needs to be removed; thankfully, it can simply be easily unglued and moved aside rather than cut out. 3) WWAN slot: the length of the M.2 adapter and BCM94360CS2 card mean that, once fitted in, they end up occupying part of the WWAN slot. impact is that no WWAN card or other M.2 card (eg: 2240 NVME SSD) can be fitted into the slot. Benefits with the recent and sustained price increase of M.2 DW1820A, Fenvi BCM94360NG or DW1560 cards, Apple BCM94360CS2 has become quite attractive because, at the time of writing, it can be obtained 2 to 3 times cheaper on the 2nd hand market (15 to 20 $/€). being dual-antenna, BCM94360CS2 makes a perfect alternative to the aforementioned M.2 cards and Apple's own BCM94360CS/BCM943602CS cards which are 3 x antennas and therefore often unsuitable in laptops. the card is fitted with same MHF4 antenna connectors as most M.2 wireless cards. it's an Apple card so 802.11ac wireless + bluetooth 4.0 work OOB and perfectly. Drawbacks the card's length: whilst using an M.2 adapter is not usually an issue (most offer a removable section), the length of the card may not allow to fit it into all laptops. There are of course M.2 extenders with ribbon cables + antenna extenders but these still require to find free space within the laptop. This has the merit to exist but will not be suitable in many if not most cases.

Re: USB mouse, assuming the device is fully working/not defective, you need to ensure you've mapped all your USB ports, internal and external. You may use tools such as Hackintool to that effect or follow the USB mapping guidance available in the Dortania documentation. You should also consult the extensive literature posted by @tanya about her own Latitude 3400. She certainly achieved great success.

Try and experiment with the various CFL mobile device ids and mobile layout ids specified in the WEG user manual. You may find a combination that works. Failing that, you may also try the settings that applied to 8th gen Kaby Lake R platforms like the Latitude 7490. This being said, there are several people who posted about their Latitude 7400 laptop also fitted with Whiskey Lake i7-8665u CPU. If you run a search for 7400-related threads/posts on the forum, you'll find a few. Afaik, they all had graphics acceleration fully running with CFL layout 0x3E9B, CFL fake iGPU id 0x3E9B and MBP15,2 SMBIOS. You've got to properly configure the properties you inject of course, it clearly was not the case in the last screenshot posted by @tommyluco ("deviceID" instead of "device-id"). This particular post is pretty limpid on the matter to me.

If Firewolf's kext results in KP, try the previous kext developed by Cholonam's. Both normally support Realtek RTS525A readers. Re: brightness keys, your DSDT shows: 1) usual BRT6 brightness control method for Dell laptops Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) } } 2) BRT6 called from EV5 method as usual Method (EV5, 2, NotSerialized) { \_SB.PCI0.GFX0.BRT6 (Arg0, Arg1) } 3) EV5 called from SMEE if OSID returns a value greater of equal to 0x20 as usual Method (SMEE, 1, NotSerialized) { Store (Arg0, Local0) Store (GENS (0x11, Zero, Zero), Local0) If (LGreaterEqual (\_SB.OSID (), 0x20)) { If (And (Local0, 0x04)) { EV5 (One, Zero) } If (And (Local0, 0x02)) { EV5 (0x02, Zero) } } If (And (Local0, 0x08)) { Store (GENS (0x1D, Zero, Zero), Local0) EV15 (Local0, Zero) } } 4) SMEE called from SMIE method as usual Method (SMIE, 0, NotSerialized) { Store (GENS (0x10, Zero, Zero), Local0) If (And (Local0, 0x04)) { SMEE (Local0) } If (And (Local0, 0x02)) { EV7 (Zero, Zero) } If (And (Local0, 0x08)) { EV9 (Zero, Zero) } If (And (Local0, 0x40)) { EV8 (Zero, Zero) } If (And (Local0, 0x80)){} If (And (Local0, 0x10)){} } 5) SMIE called from NEVT method as usual Method (NEVT, 0, NotSerialized) { Store (ECG1 (), Local0) Store (ECGD (), Local1) Store (Add (ShiftLeft (Local1, 0x10), Local0), Local2) [...] If (And (Local0, 0x80)) { SMIE () } } So, given that all is exactly as per other previous generations of Latitude (E6x30, E6x40, E7x50, E7x70, etc.), you can apply the same patches as we've detailed in our various guides: 1) in your bootloader ACPI config rename OSID to XSID -> to avoid bug after _OSI renaming rename _OSI to XOSI -> to bypass _OSI rename "BRT6,2" to "BRTX,2" -> to bypass vanilla BRT6 method 2) inject the following SSDT tables: SSDT-BRT6.aml -> injects new BRT6 method with correct key values for brightness control SSDT-XOSI.aml -> ensures OSID returns the required value You'll find those in, say, my E7270 guide. You should then have working brightness keys

Yes, though it's always better to obtain the IOReg extract from an app like IORegistryExplorer than provide a text-based one that is most difficult to analyse. Did you use this? https://osxlatitude.com/forums/topic/10209-how-do-i-generate-debugging-files/?tab=comments#comment-97908

-> moved to Monterey beta section where this thread belongs; please make sure to post in the forum's relevant sections. Thank you. With regards to your observations and experiments: 1) Monterey is at initial 1st Developper Preview stage at this point of time 2) Monterey carries no native support for HD4000 graphics that have now been officially dropped from macOS 3) HD4000 can only be supported after patching Monterey beta1 with tools such as OCLP v0.1.7 and later 4) Automatic login must be enabled after 1st boot and until you patch Monterey, failing what you end up with the graphics initialisation failure loop you currently experience I had already mentioned this in my Monterey beta1 thread posted in this very section. Please note that you're highly likely to experience reduced performance, very high temperatures and regular crashes with Monterey; it's very early stages and it does not run too great on dropped Ivy Bridge/HD4000 platforms for the moment. Best is to wait for subsequent beta versions and further development on the patching side.