Hervé

If you really want to be on the safe side of things, you may of course try/test your revised setup out of a USB boot key, then apply the proven setup to your internal disk. But we're only talking kexts updates here, not experimentation with new kexts.

I suggest you read up the Dortania documentation as a general refresher course.

Why consider complicated routes for kexts when all you need is the simplest path? Just make sure to reset NVRAM at OC Picker when you reboot.

 

Re: HD4600 iGPU, all you need is the usual that's been used for the last 10 years and nothing else:

AAPL,ig-platform-id        0600260A        DATA
device-id                  12040000        DATA
framebuffer-patch-enable   1               NUMBER
framebuffer-con1-enable    1               NUMBER
framebuffer-con1-pipe      12000000        DATA
framebuffer-con1-type      00080000        DATA

 

Graphics settings are incorrect with no need to patch fbmem or stolenmem on HD4600 iGPU.

Update your add-on kexts to latest versions, you're using old or very old versions.

Re: Ethernet, the Latitude E6440 is fitted with an Intel i7-217LM Gigabit Ethernet interface. The certainly was supported, either by Miele's IntelMausi kext (make sure you use the latest version ) or good old AppleIntelE1000e kext. You'l find the former in the Web and the latter in the packs I has posted in my old E6440 guide.

 

Re: Sleep, it should work as long as you have properly configured CPU power management. With Big Sur, you should no longer have to disable hibernation either.

 

But, again, unless you post a zipped copy of your OpenCore setup (EFI folder with config file + ACPI folder + kext folder), not much we can analyse and not much we can provide in terms of assistance.

The only thing likely to be wrong is not your laptop but your setup...

Can't see why you have some of those properties injection, especially the framebuffer flags.

Try to use only the following:

AAPL,ig-platform-id        00001659        DATA
framebuffer-patch-enable          1        NUMBER
framebuffer-con1-enable           1        NUMBER
framebuffer-con1-type      00080000        DATA

This assumes MBP14,1 SMBIOS for Ventura of course, MBP15,2 for Sonoma.

Didn't catch the personality used but you may try and inject any of the following ones that may apply:

 

FYI, it's a Latitude 7490, not an E7490. E Series stopped at Skylake E7x70.

Look at the properties listed under your AMD graphics card device. Can't say what and where it'll be on your desktop computer. Alternatively, save your IOReg from the app, zip it and attach it.

You'll see it in IOreg with apps such as IORegistryExplorer.

Hi, pretty sure we've got several threads on this matter for the Latitude 7x90 series. You may also experiment/test the Alps driver I used for my 7490; details are in the guide I had posted in the Guides section.

Graphics initialisation issue. Try and add boot-arg radpg=15.

https://github.com/acidanthera/WhateverGreen/tree/master

Check which AMD personality is selected in El Capitan/Sierra and try to inject this through properties in your config for High Sierra or later. Or experiment with the various personalities that apply to AMD 7xxx cards..

Problem fixed? Grey screen no more?

You do reset NVRAM from the OC Picker after each config change, right?

Beta4 update published 31st July.

Build 23A5301h.

Try and inject your screen's EDID.

 

If you've not done so already, I also suggest you patch your BIOS to increase DVMT size to 64MB or 96MB. It's explained in our FAQ tuto on the matter as well as on that Git repo you followed. You'll then be able to remove the injected properties that restrict fbmem to 9MB and stolenmem to 19MB. You would no longer need them and would gain 4K output alongside.

I don't fully understand why you inject some graphics properties that are the same as natively defined in KBL framebuffer 0x59160000; sure, it's harmless but why don't you try a more basic config?

AAPL,ig-platform-id        00001659        DATA
framebuffer-patch-enable          1        NUMBER
framebuffer-fbmem          00009000        DATA
framebuffer-stolenmem      00003001        DATA
framebuffer-con1-enable           1        NUMBER
framebuffer-con1-type      00080000        DATA

 

Your issue may also come from the use of kexts that I don't believe required: CpuTscSync + ECEnabler; I would recommend you disable/delete them.

@KazuDante KBL HD620 is natively supported in Sonoma with the usual settings. The KBL graphics drivers remain provided as detailed in my Sonoma beta #1 thread.

 

You must be using an incorrect config, especially if you have no success in Ventura. Please post your system's hardware specs, a zipped copy of your Sonoma EFI config (config file + kexts folder + ACPI folder, the rest is not needed) and, ideally, an IOReg extract too.

 

You should be using the settings recommended in the Whatevergreen User Manual, i.e. KBL frame buffer layout 0x59160000, default being 0x591B0000.

ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B
TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00080000 87010000

 

ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B
TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 136 MB, MAX OVERALL: 137 MB (144191488 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI
[3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 02000000 98000000
02040A00 00080000 87010000
03060A00 00040000 87010000

 

Framebuffer 0x59160000 natively supports HDMI output out of connector con1 but you'll need to patch the connector's type to HDMI (00080000) to obtain HDMI audio.

Framebuffer 0x591B0000 requires to patch con1's Index and Bus Id from 0204 to 0105.

If your laptop's BIOS sets DVMT to 32MB by default, you'll have to inject the properties that patch fbmem to 9MB and stolenmem to 19MB. See our dedicated thread on the matter ins our FAQ forum section for details. No such patches are required if DVMT is set to 64MB or above.

 

Intel i5-7200U CPU integrates HD620 iGPU with id 0x5916 which is natively supported by the KBL driver so absolutely no need to fake any iGPU device.

 

Finally, make sure you use MBP15,2 SMBIOS for Sonoma. In Ventura, it should be MBP14,1.

OCLP v0.6.8 now provides support for Broadcom legacy wireless cards that Sonoma officially dropped. Good news for all of us relying on BCM4350/BCM4360xx cards for Wireless and Bluetooth services.

 

Not tried it yet but process is understood to be as follows with OpenCore (cf. dedicated Sonoma beta threads at Insanelymac.com):

1. add boot-arg amfi=0x80 (or amfi_get_out_of_my_way=1)
2. disable SIP with csr-active-config set to 0x803 (0x0FEF is Ok too)
3. block vanilla kext IOSkywalkFamily kext in the config file
4. disable SecureBoot if applicable
5. inject older kexts IOSkywalkFamily + IO80211FamilyLegacy kexts (in that specific order)
6. once booted with those settings, apply OCLP root patching and reboot
7. Broadcom wireless cards that were previously supported in Ventura are then expected to be operational again

Not sure this works with Clover given the lack of system's kext blocking facility afaik. Will try to test asap with OpenCore on my E7270.

Edit: This is fully supported with Clover r5157 and later.

Released July 25th, 2023.

Build 23A5301g.

 

 

As usual, no OTA update offered when running with MBP15,2 SMBIOS and had to reboot temporarily with iMac19,1 SMBIOS. Otherwise, completely smooth update.

 

 

That's entirely up to you, we cannot guess your ability or not in that respect. You may simply follow the documentation available on Dell's support web site, it's not very difficult.

See my old Latitude 7490 guide available in the Guides section. To me, you're injecting incorrect properties for your iGPU:

 

I can't see why you'd patch con0's pipe to 0x12 for instance.

There will be no need to enable TRIM in recent macOS versions such as Big Sur, Monterey or Ventura. It'll be enabled by default.

in 2023, it's kind of irrelevant... There are many PCs with bugged BIOS tables (DSDT and/or otherwise), Dell is not a unique actor in that respect. Yet, Dell laptops remain ideal platforms by far and large (especially Latitude laptops) when it comes to running OS X/macOS on them.

The brightness keys ACPI patch I posted does not apply to the Sandy Bridge Latitude E6x20 as is. I tried it to no avail on my E6220, whether BIOS operating in legacy of UEFI mode. Instead, I called on a different patch I had found on the web that I adapted for my E6220. I posted the details in my E6220 Mojave guide; look it up.

 

It's a simple ACPI renaming patch in the Clover config file + a patched SSDT-Q66 table. With Mojave, I completely moved away from a patched DSDT to a simple and basic set of a few patched SSDTs + associated ACPI patches in the bootloader's config file. It's very minimal and very efficient.

 

In a nutshell, all you do is replace the original _Q66 event handling method:

            Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
            {
                If (LNotEqual (ECRD, One))
                {
                    Return (Zero)
                }
                NEVT ()
                Return (Zero)
            }

by this revised code:

        Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
        {
            If (LNotEqual (\ECRD, One))
            {
                Return (Zero)
            }
            NEVT ()
            \_SB.AMW0.WED0 (One)
            Mid (\_SB.AMW0._WED (0xD0), Zero, 0x06, Local2)
            If (LEqual (Local2, Buffer (0x06)
                    {
                         0x02, 0x00, 0x10, 0x00, 0x50, 0x00             
                    }))
            {
                Notify (\_SB.PCI0.LPCB.PS2K, 0x0365)
            }
            If (LEqual (Local2, Buffer (0x06)
                    {
                         0x02, 0x00, 0x10, 0x00, 0x48, 0x00             
                    }))
            {
                Notify (\_SB.PCI0.LPCB.PS2K, 0x0366)
            }
            Return (Zero)
        }

making sure not to forget the ACPI renaming in your config file which is necessary to bypass the original _Q66 method of the (native) DSDT table and inject its replacement through SSDT:

Find: 5F513636 (="_Q66")
Replace: 5F583636 (="_X66")

 

And that's it.

As long as it's the same motherboard model (even with a different CPU if it's soldered provided you're not using a CPU-specific power management SSDT but the PlugIn method), all should work upon straight replacement and without any need to re-install macOS at all. Just make sure the replacement motherboard has same or latest BIOS version and adequate/same BIOS settings as the old one.