Contribute
Register

<< Solved >> Dell Optiplex 7020 - 4K monitors on Intel 4600 Integrated GPU

Status
Not open for further replies.
Ok, re. "patchless" 4k (i.e., instead of a patch, getting 4k working directly with WhateverGreen [WEG] using DeviceProperties in the OpenCore config.plist).

A few different attempts:

Interestingly, this list included some of the settings that the 4k-Patch patched (e.g., Framebuffer Memory, DVMT allocation) and looked promising. I also noticed framebuffer-cursormem showed up here and was turning up in a few searches related to HD4600. That was a solid lead because when I tried to replicate the 4k patch in my WEG config.plist settings earlier I experienced some glitchy/artifacty cursor stuff. I went back and added the two 4k patch values then added a third cursormem value (set at 00009000 because that's what it was in the list I linked to) but that caused a panic. I went back and tried adding the entire WEG HD600 patch equivalent (nothing). Then, I played around with a few specific combinations of the settings to replicate the 4k-patch again (no success, occasional panics).

I don't really know what the cursormem value (or the other values) should be anyways so really I'm just danger-pasting stuff around and crossing my fingers.

Summary of initial findings:
I've posted this before, but as far as I can tell the original 4k patch does the following to AppleIntelFramebufferAzul.kext:
  • Finds the PlatformID (0300220D), and the pipe and port count (0030303) but makes no changes to them.
  • Finds and replaces the DVMT from 00000002 to 00000004 to set a 64MB DVMT allocation (which matches the changes we made in the bios)
  • Finds and changes the Framebuffer memory size from 00003001 (32MB) to 00000003 (48MB).
  • Alternatively, both of these changes can be accomplished in the DeviceProperties for WhateverGreen in the config.plist. However, that method doesn't enable 4k for me (stays 2k).
  • It's still a solid approach, but I'm at a stage where I don't actually know how to interpret the more in-depth WEG Framebuffer stuff, or what combination of properties and settings in WEG would enable 4k.
Next steps:
  • Moved from 14,3 -> 15,1 (which is a 27" 5k 2015 iMac).
  • This should allow for Big Sur installation (and is stable for me right now - clarification: Catalina is stable with 15,1 I haven’t tried the beta)
  • Nope, 4k doesn't work by default (too bad), patch still required but it's otherwise stable
TL;DR, I can't figure out a way to get 4k working via WhateverGreen, but I posted a bunch of info/trials here in case it inspires someone who actually knows what they're doing
 
Last edited:
@mgrimace
can you try below device properties?
framebuffer-stolenmem -> data 00000006
framebuffer-fbmem -> data 00000003

4k works perfectly for me with above setup.
 
0xd1ab10 said:
@mgrimace
can you try below device properties?
framebuffer-stolenmem -> data 00000006
framebuffer-fbmem -> data 00000003

4k works perfectly for me with above setup.
Click to expand...

++ initial testing with above is working without patch(!!!), going to double check on my main system EFI and a few reboots to make sure!

Update
Changed framebuffer-stolenmem -> data 00000006 (96mb) to 00000004 (64mb) to match my DVMT BIOS settings. Working!

Nicely done solving this @0xd1ab10 !!

Update 2
@nicksoph - I've attached my OpenCore config.plist so you/others can take a look! Note it's been anonymized (i.e., serials/MAC address removed). Note also that I've changed from iMac14,3 to iMac15,1 to be Big Sur compatible, but that should not be necessary for this to work.
 

Attachments

  • config (anon).plist
    17.1 KB · Views: 218
Last edited:
Good stuff @0xd1ab10, @mgrimace. My ignorance prevents saying more.

Are there any outstanding issues on yours ?

Thanks
 
nicksoph said:
Good stuff @0xd1ab10, @mgrimace. My ignorance prevents saying more.

Are there any outstanding issues on yours ?

Thanks
Click to expand...

No outstanding issues!

Summary:

Previously, to enable 4k we patched AppleIntelFrambufferAzul.kext directly. This new/alternative method replicates the function of that patch directly in WhateverGreen's settings in DeviceProperties in the config.plist. The benefit of this method is that our 4k won't break when Apple changes the AppleIntelFramebufferAzul.kext in an update.

The three values that I added to DeviceProperties in the config.plist:
  • The first value framebuffer-unifiedmem with data 00000080 increases the video memory to 2gb which I have found helpful on a dual-monitor setup.
  • The second value framebuffer-stolenmem sets the framebuffer stolen memory. It's best to match the value of this data to your BIOS DVMT:
    • If you've set your BIOS DVMT to 64mb use the value 00000004
    • If you followed the original post, you likely have your DVMT set at 96mb, if so use the value 00000006 instead.
  • The final value framebuffer-fbmem with data 00000003 sets the Framebuffer memory size to 48MB.
The second and third values accomplish the same function of what the 4k patch was doing.

What I was missing earlier and what 0xd1ab10 identified was that I was using the value framebuffer-memorycount but it should be framebuffer-fbmem instead. Switching that last piece was able to fully replicate the function of the patch and enable 4k.

What's working:
  • My 27" 4k monitor is correctly displaying in 4k
  • I'm using dual monitors (i.e., 27" 4k and a vertical 24" 1080p) both are connected via DisplayPort.
  • The 4k monitor is connected to the DisplayPort closest to the VGA connector and it is recognized as Built-In Retina display (this is expected behaviour).
Additional Details:

Here is my full DeviceProperties section (with a 64mb stolenmem value):

Code: 
<dict>
    <key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
            <dict>
                <key>alc-layout-id</key>
                <data>
                EAAAAA==
                </data>
            </dict>
            <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
            <dict>
                <key>AAPL,ig-platform-id</key>
                <data>
                AwAiDQ==
                </data>
                <key>device-id</key>
                <data>
                EgQAAA==
                </data>
                <key>disable-external-gpu</key>
                <data>
                AQAAAA==
                </data>
                <key>disable-hdmi-patches</key>
                <data>
                AQAAAA==
                </data>
                <key>enable-hdmi20</key>
                <data>
                AQAAAA==
                </data>
                <key>framebuffer-con0-alldata</key>
                <data>
                /wAJAAAAAACHAAAA
                </data>
                <key>framebuffer-con0-enable</key>
                <data>
                AQAAAA==
                </data>
                <key>framebuffer-con3-alldata</key>
                <data>
                /wAAAAAAAABAAAAA
                </data>
                <key>framebuffer-con3-enable</key>
                <data>
                AQAAAA==
                </data>
                <key>framebuffer-patch-enable</key>
                <data>
                AQAAAA==
                </data>
                <key>hda-gfx</key>
                <string>onboard-1</string>
                <key>framebuffer-unifiedmem</key>
                <data>
                AAAAgA==
                </data>
                <key>framebuffer-stolenmem</key>
                <data>
                AAAABA==
                </data>
                <key>framebuffer-fbmem</key>
                <data>
                AAAAAw==
                </data>
            </dict>
        </dict>
        <key>Delete</key>
        <dict/>
    </dict>
</dict>
</plist>

Other considerations:
  • I am using OpenCore; however, this should work fine in Clover. Device Properties are defined in Clover's config.plist Devices -> Properties section. Source for WhatEverGreen IGPU manual configuration:
    https://www.tonymacx86.com/threads/an-idiots-guide-to-lilu-and-its-plug-ins.260063/
  • This should work fine if you're on either the iMac14,3 or iMac15,1 SMBIOS
  • I mentioned earlier that I'm using iMac15,1 SMBIOS for eventual Big Sur compatibility. I'll note I have not tested the Big Sur Beta yet, and the above is confirmed working on my 7020 SFF Catalina system.
  • FYI: The SMBIOS iMac15,1 will show up in about this Mac as iMac (Retina 5K, 27-inch, Mid 2015).
  • Interesting finding: following Zearp's progress with Big Sur testing, it looks like both 14,3 and 15,1 have a 200mhz grfx base clock. According to the Intel spec this should be 350mhz. This means we're essentially under-clocking our graphics.
 
Last edited:
mgrimace said:
No outstanding issues!
Click to expand...
So for all the Dell Optiplex 7020/9020 owners reading this. To prevent confusion in beginners would you clarify whether what you are doing requires the cfg unlock via the firmware modification that nicksoph has shown in the original post ? Also is this only possible with OC bootloader and not with Clover ?
 
Last edited:
trs96 said:
So for all the Dell Optiplex owners reading this. Can you clarify whether what you are doing requires the cfg unlock via the firmware modification that nicksoph has shown in the original post ?
Click to expand...

As far as I can tell yes.

In setting up my system initially, I performed the following BIOS firmware modifications:
  • Disable CFG Lock: setup_var 0xDA2 0x0
  • Set DVMT pre-alloc to 64MB: setup_var 0x263 0x2
I see in @nicksoph's OP that the DVMT pre-alloc was set to 96 mb setup_var 0x263 0x3. That means that for consistency your framebuffer-stolenmem data probably should be set at 00000006 (which will set it to 96mb to match your BIOS changes).

Note above, I personally set my DVMT to 64mb in the BIOS therefore I also set framebuffer-stolenmem to 64mb using the value 00000004. Basically, it seems like it would make the most sense to keep these values matched unless someone knows better (i.e., BIOS and stolenmem). FYI I tested both values and didn't run into any problems.

I'm on a Dell 7020 SFF on Bios A18, and I booted into modGRUBShell.efi to make the firmware changes. I use ProperTree to add/change the values in my system's EFI config.plist
 
mgrimace said:
Basically, it seems like it would make the most sense to keep these values matched unless someone knows better (i.e., BIOS and stolenmem).
Click to expand...
Yes, it would be best to keep them matched. I would also agree that 64MB DVMT setting is the best choice. If dual 4K monitors work with no problems, then the 96 MB change isn't really necessary. Not possible to connect more than two 4K monitors. The extra 32MB probably isn't going to help in any way.
 
trs96 said:
Yes, it would be best to keep them matched. I would also agree that 64MB DVMT setting is the best choice. If dual 4K monitors work with no problems, then the 96 MB change isn't really necessary. Not possible to connect more than two 4K monitors.
Click to expand...

Excellent, thanks for clarifying that - I updated my summary post above to reflect that info
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top