Hervé

Nothing strange re: Preboot and Recovery, that's what you obtain since Big Sur when using Clover; it'd be the same with Monterey or Ventura. You'll be booting the Preboot partition. Re: Intel Wireless, consult the usual online documentation. Re: screen brightness, all is explained in the dedicated thread I posted here some time ago and the bootpacks I posted in my E6230 guide all contain the necessary ACPI patches in the provided DSDT. Look these up.

Perfectly normal, you can't install Big Sur with the SMBIOS of an unsupported Mac model. As such, you have to use something like SMBIOS MBP11,x or MBP12,1 during installation before switching back to MBP9,x/10,x afterwards. In the same respect, note that you won't get offered any Big Sur updates until you use the SMBIOS of a supported Mac model.

Target macOS release: Monterey 12.x. This is a Clover-based installation based on the standard vanilla method detailed below, followed by OCLP basic root patching to bring back support for HD4000 graphics. Working: full graphics acceleration on Intel HD4000 graphics (with Lilu v1.6.3 + WEG v1.6.3 + OCLP v0.5.3 root patching) multi-display with HDMI after OCLP patching audio, including jack microphone input and headset output (with AppleALC v1.6.4 & layout 12 + CodecCommander v2.7.2) HDMI audio (with Capri Framebuffer properties injection) built-in GigEthernet LAN connection (with AppleIntelE1000e v3.1.0 or latest IntelMausiEthernet kext) wireless and bluetooth with any compatible card integrated webcam (OOB) full CPU power management, including Turbo boost (with CPU-specific generated ssdt) sleep (Lid, Energy Saver settings, Apple menu, Fn-F1, PWR button) & wake (Lid, PWR button) battery management (with ACPIBatteryManager v1.90.1) SD card reader (with DSDT patch or property injection, for compatibility with Apple's default card reader) keyboard (with Dr Hurt's VoodooPS2Controller R6 + DSDT patch for brightness control) touchpad including tap-to-click (with Dr Hurt's VoodooPS2Controller R6) left combo eSATA/USB2.0 + right USB3.0 ports (with Hackintool's generated USBPorts; optional FakePCIID kexts v1.3.15, published here, for multiplexing) ExpressCard slot OOB Not working: VGA output unsupported Not tested: SmartCard reader fingerprint scanner 1) 12.x USB installer creation Using a USB key of 16GB minimum, create a Monterey USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Monterey.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Monterey installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_16GB) The process will take several minutes. Once completed: install Clover boot loader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI drivers Recommended Drivers (optional) EnglishDxe Human Interface Devices (optional) PS2MouseDxe USBMouseDxe FileSystem Drivers ApfsDriverLoader FAT (optional) Memory fix drivers OpenRuntime Additional Drivers (optional) PartitionDxe Themes (optional) BootLoader Chooser (optional) CloverConfigPlistValidator (optional) you may use version r5150 attached below Clover_r5150.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip add the (unzipped) HFSPlus driver attached below to the EFI/CLOVER/drivers/UEFI folder HFSPlus.efi.zip open the EFI partition and transfer the files and folders from the Latitude E6230 Monterey Clover pack below to the EFI/CLOVER folder Clover_Pack_E6230_Monterey.zip /!\ If your E6230 is fitted with a different CPU than the i7-3540M, please remove the Power Management SSDT of the pack until you replace it by one applicable to your model (whether an existing SSDT or your own generated one) in the post-install phase. 2) 12.x installation boot the Monterey USB installer at the Clover main menu, go to the "Options->configs" menu and select the "config_MBP11,4" config file. This is required to install (and later update as/when required) Monterey on a supported Mac model. Press [ESC] twice to return to Clover main menu. at the Clover main menu, select the "Install macOS Monterey" partition and press [ENTER] at Monterey main installation screen, select Disk Utility to create & format APFS the target Monterey disk/partition/volume. Note that installation won't work if target disk/partition/volume is formatted HFS+ exit DU and return to Monterey main installation screen, then proceed with installation the installation process will reboot a temporary macOS installer partition to complete the installation. repeat this until the temporary partition is replaced by a final <Monterey partition name> on Preboot entry. Each time, reboot via your USB installer and make sure to select the "config_MBP11,4" config file. when the partition <Monterey partition name> on Preboot is displayed at Clover main menu, no need to call on the "config_MBP11,4" config file, the default one will do (MBP10,2 SMBIOS + -no_compat_check boot arg). 3) Post-installation tuning Once the finalised Monterey installation has booted, complete the 1st boot configuration tuning. This will be very slow due to lack of graphics acceleration, HD4000 having been dropped in macOS Monterey. Once at the desktop, mount the EFI partition of your Monterey disk Copy the EFI folder of the E6230 Monterey Clover pack to the mounted EFI partition You may then modify your SMBIOS info using Clover Configurator app and ensure you have unique numbers or unique combination of numbers (MLB, ROM, SystemSerialNumber and SystemUUID). Please note that, with MBP10,2 SMBIOS, Monterey will not offer any updates because it'll be running on an unsupported platform. You'll only get updated offered if you boot with the MBP11,4 config file, MacBookPro11,4 being a supported model. 4) Post-installation OCLP patching OpenCoreLegacyPatcher (OCLP) app may be used to patch the Monterey build on the E6230 to recover support for HD4000 graphics. Best is to use the latest version of the tool available here. Run the tool and set it up as follows in order to apply post-installation root patching: click Settings button select MacBookPro10,2 SMBIOS, then return to Settings select SIP settings and tick all cases except "CSR_ALLOW_APPLE_INTERNAL" in order to set SIP to 0xFEF, then return to Settings select SMBIOS Settings and make sure everything is left blank, then return to Settings select Misc Settings and tick everything off, leaving Feature Unlock Status as "Enabled, then return to Settings select Non-Metal Settings and make sure everything is ticked off, then return to Settings select Developper Settings and make sure everything is ticked off, then return to Settings return to Main Menu Click Post Install Root Patch, then Start Root Patching OCLP root patches will then be installed. Once completed, reboot into Monterey and you'll have graphics acceleration running on HD4000. Note that OCLP root patching will be required after each Monterey update.

Hmm, might want to use latest Clover release r5150 by now. I never updated my guide since it was 1st published for Big Sur initial release back in 2020... I had been running with r513x for yonks before updating to r5141 some time ago. Very recently replaced my Big Sur build by Monterey 12.6.2 with r5150 (applied basic OCLP root patch for HD4000 graphics). Would have to try out Big Sur installation again on the basis that current package (at time of writing) will indeed be version 11.7.2. Points to note: make sure you update Lilu & PlugIns (AppleALC, WhateverGreen, etc.) to latest versions. good old FakePCIID + FakePCIID_XHCIMux kexts for USB2.0/USB3.0 multiplexing will be Ok up to Big Sur but need replacing by this version for Monterey. Bear with me and I'll post something soon but if you can't wait, update your setup according to the above.

Not sure it'll make much difference using MBA6,2 or MBP11,1 compared to MBP11,4 for CPU Power Management but you may want to observe this and make some comparison; can be an interesting experiment to make, it certainly used to make a difference on old C2D Merom/Penryn laptops.

Absolutely, HD 5500 iGPU of i7-5500U carries device id 0x1616 (i.e. PCI id 8086:1616). Aso, Whatevergren's default BDW framebuffer layout being 0x16260006 for Broadwell mobile graphics, it's not necessary to specify that either with SMBIOS MBP12,1. See the WEG user manual: Re: audio, you inject full AppleALC kext that goes with Lilu. Recommendation is to use latest versions of the kexts. How did you establish that audio was ALC290? If in doubt, remove AppleALC and replace, even if only temporarily, with VoodooHDA (+AppleHDADisabler accompanying kext). You may then check the audio codec in Hackintool or, better, DPCIManager app. https://github.com/MuntashirAkon/DPCIManager

Support for old Tesla cards stopped at High Sierra. No drivers were provided in subsequent macOS versions. The patch was a pretty easy thing in Mojave and early versions of Catalina up to 10.15.3. From 10.15.4, Apple changed things and the patch required to adjust/change many additional things (to cover for issues such as AMFI). See my (old) D630 guide for instance. From 10.15.4 onwards, you'll need to use special patching tools such as dosdude1's Catalina patcher. You need the Tesla patch and the boot arg amfi_get_out_of_my_way=1 to bypass AppleMobileFileIIntegrity (AMFI) to be able to boot Catalina 10.15.4 and subsequent 10.15 updates. https://dosdude1.com/catalina/ For Big Sur & later, you'll need to look for OCLP, which is a much better tool. https://github.com/dortania/OpenCore-Legacy-Patcher/ If your system can run Catalina, you might just go for Big Sur or Monterey and apply the OCLP Tesla patch, that'd probably be better and easier; unless you absolutely need to run old and abandoned Catalina of course.

Please add your system's specs in signature. Looks like your settings are correct: SMBIOS MacBookPro12,1 BDW framebuffer layout if 0x16260006 Re: EDID, as I said, you need to look it up on the web. Extract it with tools/apps such as Monitor Asset Manager, then inject it by adding the following property to the graphics settings of your bootloader's config: AAPL00,override-no-connect <XXXXXXXXX> DATA where <XXXXXXXX> is your 20bytes (or so) EDID info in one long consecutive hexadecimal string. See the WhateverGreen user manual. PS: Thanks for the donation offer. You can do this off the main page, there's a button for it.

I don't know what you mean by "bad screen refresh" but, yes, you indeed have a display issue with your Hackintosh build. I've modified your thread title to properly reflect the problems you've mentioned. 2 x possible causes to your screen problem: wrong configuration (you do not inject the correct settings for HD5500 and/or wrong SMBIOS) you need to inject your screen's EDID information (you can look this up on the Web: how to extract and how to inject in macOS through bootloader's property). It's very common to require this on HP laptops.

Hello and welcome.

Look at the usual place... https://github.com/OpenIntelWireless/itlwm

Generally speaking, generic/3rd party batteries tend to be utter crap and often seriously decline after only a few months. I guess you'll see soon enough. Not that many things you can do to optimise battery; you've already enabled low power mode but who knows if it's of any use on a Hack. Other possible actions to consider: reduce screen brightness adjust screen saver & sleep/hibernate settings revise CPU power settings (tuned CPUFriend kexts vs. native kernel CPU power management or vice versa) disable turbo boost on battery use SSD instead of mechanical HDD Battery settings may also differ according to SMBIOS/Mac model. That's about it...

@dadablaze No double/multiple posts on the forum please. See our published rules.

Nothing here for this laptop afaik. You'll have to make one up, starting with basic usual settings for a regular Kaby Lake/HD620 laptop, then adding whatever may be required for your hardware accessories (LAN, WLAN/Bluetooth, audio, SD card reader, etc.). Can't remember if Samsung PM961 SSD is supported, unlike its PM981/PM991 brothers which don't allow to install/run/boot macOS on them. SATA Express? Wow, can't be many machines fitted with that.

NB: This is a revival of the article I had initially published at InsanelyMac to answer recurring questions that had been raised in the Opencore thread that lives there. Posted October 2, 2021 The Dortania documentation refers to the DVMT pre-allocated memory or "stolen memory" when they mention "memory reserved for the iGPU". Years ago, @Firewolf described in details the relationship between stolen memory and DVMT pre-allocated memory on his blog: https://www.firewolf.science/2015/04/guide-intel-hd-graphics-5500-on-os-x-yosemite-10-10-3/ There's a more recent thread from him here: https://www.insanelymac.com/forum/topic/345377-surface-pro-patch-the-framebuffer-properly-to-get-rid-of-the-dvmt-assertion-patch/ It can be difficult to understand and differentiate DVMT pre-allocated memory, stolen memory, framebuffer memory, cursor memory, framebuffer size, cursor bytes, etc. And all of these have got nothing to do with VRAM of course... Some of us are familiar with the information provided by @Pike R Alpha many moons ago, the WhateverGreen User Manual or the Hackintool app though none of those clearly define what the various memory instances are. Several years ago, @Rehabman also attempted to explain this and his writings somehow collided with most people's comprehension of things. For instance, when @Pike, WhateverGreen or Hackintool refer to stolenmem and fbmem, @Rehabman spoke of framebuffer memory size and cursor bytes. In the case of the Haswell Azul framebuffer layouts, @Rehabman also spoke of the DVMT pre-alloc requirements when the others speak of stolenmem. Inevitably, this can lead to confusion... Definitions: See wikipedia and Google searches. VRAM = Video RAM. Common definition is that it stores the pixels and other graphics data rendered on a computer screen. DVMT = Dynamic Video Memory Technology. A technology used by Intel to dynamically allocate system memory to use as video memory to handle graphics. DVMT pre-allocated memory is the minimum amount, in multiples of 32MB, that will be allocated to the iGPU for handling graphics. By far and large, manufacturers set this to 32MB by default in BIOS (or certainly used to). Framebuffer = a memory buffer held in RAM and containing a bitmap of a video frame, i.e. all the data related to the pixels of an image to be displayed on screen (eg: colours, resolution, etc.). Stolen memory = basically, this is the same as the DVMT pre-allocated memory. As far as Apple's framebuffer drivers/kexts are concerned: framebuffer size (aka stolenmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout (it may change according to image characteristics), as defined in the driver/kext. cursor bytes (aka fbmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout's overlay used for handling mouse cursor (without modifying the framebuffer's data), as defined in the driver/kext. framebuffer VRAM (aka unifiedmem for WhateverGreen) = the max. amount, in bytes, of VRAM allocated by a framebuffer layout, as defined in the driver/kext (since Haswell and Yosemite, this usually is 1536MB). * As stated above, I believe that Whatevergreen only got it right for Haswell Azul framebuffer layouts with which stolenmem, fbmem and cursormem match their target. Thereafter, I'm of the opinion that WhateverGreen used incorrect names where stolenmem means the actual framebuffer size and fbmem means the actual cursor bytes (size), as stated by @Rehabman. Mac OS X/OS X/macOS graphics framebuffers: Let's start by looking at a few examples as illustrated in the WhateverGreen User Manual. 1) Haswell Azul mobile framebuffer 0x0a260006 (used for HD4200/HD4400/HD4600 iGPUs on laptops): ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 If we look inside the binary code of the Haswell Azul framebuffer kext, we'll find: 0600260A 01030303 00000002 00003001 00006000 00000060 D90A0000 D90A0000 00000000 00000000 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 which translates to: 0600260A -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00000002 -> 32MB stolen mem (framebuffer-stolenmem) // Rehabman's DVMT-prealloc requirement 00003001 -> 19MB FB mem (framebuffer-fbmem) // Rehabman's framebuffer size 00006000 -> 6MB Cursor mem (framebuffer-cursormem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) D90A0000 -> Backlight freq 2777MHz D90A0000 -> Max. backlight freq 2777MHz 00000000 00000000 00000800 02000000 30000000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000 01050900 00040000 87000000 -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP (framebuffer-con1-type), flags 87000000 02040900 00040000 87000000 -> port #3/FB@2: index 02, busid 04, pipe 0900, type 00040000=DP (framebuffer-con2-type), flags 87000000 FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 2) Broadwell BDW mobile framebuffer 0x1626006 (used for HD5300/HD5500/HD5600 iGPUs on laptops): ID: 16260006, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS [1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP [2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP 00000800 02000000 30020000 01050B00 00040000 07050000 02040B00 00040000 07050000 If we look inside the binary code of the Broadwell BDW framebuffer kext, we'll find: 06002616 01030303 00002002 00005001 00000060 D90A0000 D90A0000 00000000 00000000 00000000 00000800 02000000 30020000 01050B00 00040000 07050000 02040B00 00040000 07050000 FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 00000000 00000000 C8000000 which translates to: 06002616 -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00002002 -> 34MB stolen mem (framebuffer-stolenmem) // Rehabman's framebuffer size 00005001 -> 21MB FB mem (framebuffer-fbmem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) D90A0000 -> Backlight freq 2777MHz D90A0000 -> Max. backlight freq 2777MHz 00000000 00000000 00000000 00000800 02000000 30020000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000 01050B00 00040000 07050000 -> port #2/FB@1: index 01, busid 05, pipe 0B00, type 00040000=DP (framebuffer-con1-type), flags 07050000 02040B00 00040000 07050000 -> port #3/FB@2: index 02, busid 04, pipe 0B00, type 00040000=DP (framebuffer-con2-type), flags 07050000 FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 00000000 00000000 C8000000 3) Skylake SKL mobile framebuffer 0x19160000 (used for HD520/HD530/HD540 iGPU on laptops): ID: 19160000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000090F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL 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: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 We can't look at the binary code of the Skylake SKL framebuffer because Apple changed the way things are coded inside but it basically translates as follows: 00001619 -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00002002 -> 34MB stolen mem (framebuffer-stolenmem) // Rehabman's framebuffer size 00005001 -> 21MB FB mem (framebuffer-fbmem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) 6C050000 -> Backlight freq 1388MHz 6C050000 -> Max. backlight freq 1388MHz 00000800 02000000 98000000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 98000000 01050900 00040000 87010000 -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP (framebuffer-con1-type), flags 87010000 02040a00 00040000 87010000 -> port #3/FB@2: index 02, busid 04, pipe 0a00, type 00040000=DP (framebuffer-con2-type), flags 87010000 With the exception of the Haswell Azul framebuffer, we can see that Broadwell BDW and Skylake SKL framebuffers define framebuffer size (WEG's stolenmem) and cursor bytes (WEG's fbmem) characteristics and no DVMT pre-allocated memory (i.e. proper stolen memory). This extends to Kaby Lake KBL framebuffers and later. In my opinion, it's fair to say that @Rehabman's description and wording are the most appropriate/best ones when the WEG view of things got somehow misled by following through on the Haswell framebuffer decoding. To me, there was some mixup, leading to confusion and the said confusion has remained ever since... Confusion... why? Because of several things: 1) the observation that the Haswell Azul framebuffers used on Hacks (0x0D220003 for desktops and 0x0A260006 for laptops) defined: a DVMT pre-allocated memory (= Stolen memory) size of 32MB a framebuffer size of 19MB a cursor bytes of 0MB (desktops) and 6MB (laptops; required to be increased to 9MB to fix a minor graphics glitch on some systems) 2) the observation that the Broadwell BDW framebuffers used on Hacks (0x16220007 for desktops and 0x16160006 for laptops) defined: no DVMT pre-allocated memory requirement at all framebuffer sizes of 38MB and 34MB respectively cursor bytes of 38MB and 21MB respectively 3) the observation that the sum of framebuffer size + cursor bytes must be lower than the size of the DVMT pre-allocated memory, failing which a KP occurs at graphics initialisation during startup/boot. 4) In the case of the Haswell Azul framebuffers: DVMT pre-allocated memory requirement is set at 32MB framebuffer size + cursor bytes = 19+0 | 19+6 (or 19+9) = 19MB | 25MB (or 28MB) which is lower than DVMT pre-allocated memory 32MB -> All is Ok by default. 5) In the case of the Broadwell BDW framebuffers: framebuffer size + cursor bytes for desktops = 38+38 = 76MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most desktops, unless adjusted in BIOS framebuffer size + cursor bytes for laptops = 34+21 = 55MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most laptops, unless adjusted in BIOS -> Not Ok by default, Kernel Panic (KP) encountered. 6) And the story is the same with subsequent Skylake, Kaby Lake, etc. framebuffers. Solution: 2 x solutions were engineered to address the issue of KP at graphics initialisation. increase the DVMT pre-allocated memory set in BIOS. Could be complicated and tricky for PCs that do not offer this in BIOS Setup but made easy with Grub Shell if DVMT pre-allocated memory can be identified in BIOS. This method is usually required to gain 4K output. patch the Broadwell, Skylake, Kaby Lake, etc. framebuffer layouts to reduce framebuffer size and cursor bytes so that the sum of them totals less than the usual default DVMT pre-allocated memory of 32MB. This solution does not usually support 4K output. Although some people do opt for the 1st solution, most people just adopt the 2nd one. How were the framebuffer patches derived? If we look at the framebuffer patches that are commonly and generally used, we can observe that they set: WEG's framebuffer-stolenmem property , i.e. framebuffer size to 0x01300000 = 19MB (DATA type set to 00003001) WEG's framebuffer-fbmem property, i.e. cursor bytes to 0x00900000 = 9MB (DATA type set to 00009000) i.e. the values typically used on laptops with Haswell iGPUs, this simply because 19+9=28MB which is < 32MB. This is where it all appears to come from. Is this correct? By far and large, it is. But the need to apply such framebuffer patches depends entirely on the host PC's default DVMT pre-allocated memory. On desktop and laptop PCs where DVMT pre-allocated memory can be adjusted in BIOS setup, the patches are unnecessary as long as the DVMT value that is set exceeds the total of the framebuffer size + cursor bytes of the selected/target graphics framebuffer. Typically, a value of 64MB or 96MB takes care of things perfectly, including 4K. Of course, those PCs manufactured with default DVMT pre-allocated memory set to 64MB or more are unlikely to encounter any issue at all. The framebuffer patches are also unnecessary if the default DVMT pre-allocated memory is increased either though BIOS binmod (difficult and risky) or through Grub shell mod (easy and quickly reversible). This is well illustrated on @Firewolf's blog, linked above (there are other places too such as @Jake Lo's FAQ item here). To give an example, on some Dell laptops (eg. Broadwell Latitude E7x50 or Skylake Latitude E7x70), DVMT pre-allocated memory can be increased by booting a Grub shell and entering the following command: setup_var 0x432 0x3 This sets DVMT pre-allocated memory parameter located at offset 0x432 to 96MB (0x1 for 32MB, 0x2 for 64MB, 0x3 for 96MB, etc.), the default setting for the laptop in this example being 32MB. This setting will remain valid/in place until BIOS is reset to default settings. It's required to obtain 4K output out of DP/HDMI. Of course, different computers will have different locations/offsets for DVMT pre-allocated memory. What should I do then? As stated above, the framebuffer patches apply to most if not all cases. But not for 4K output. Those who feel adventurous or who are computing-literate may opt for the BIOS adjustment alternative. In all cases, the 1st thing to do is to look at the default framebuffer size and cursor bytes settings of the targeted graphics framebuffer, then decide if the sum of them both fits or not in 32MB or any other value set in BIOS for DVMT pre-allocated memory. Can I use different values? Absolutely! As long as the golden rule is respected: framebuffer size + cursor bytes < DVMT pre-alloc mem or, in WEG's conventions, stolenmem + fbmem < DVMT pre-alloc mem. To give a practical example, I experimented on my Skylake/HD520 Dell Latitude E7270 Hackintosh laptop: default DVMT pre-allocated memory value set in BIOS: 32MB target SKL framebuffer layout: 0x19160000 default framebuffer size: 34MB default cursor bytes: 21MB sum of framebuffer size + cursor bytes: 55MB (i.e. > 32MB) Booting with default DVMT pre-alloc mem + no framebuffer patches -> KP/freeze Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 12MB -> KP Booting with default DVMT pre-alloc mem + framebuffer size 19MB + cursor bytes 9MB -> Ok, full graphics acceleration, no 4K output Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 10MB -> Ok, full graphics acceleration, no 4K output Booting with DVMT pre-alloc mem set to 64MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output Booting with DVMT pre-alloc mem set to 96MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output

I get the impression you don't fully understand half of what you're doing/writing. 1) "BIOS patched to max 2048MB" ? Very much doubt you'd need to set DVMT to that much. I don't believe macOS framebuffers will make any use of that. 2) '#' character is used to comment something out in a bootloader's config and boolean values can be expressed as decimal NUMBER or 32bit hexadecimal DATA types (0 is 0 and 1 is 1, no matter the size of the data unit you opt for). You also need to understand that some of those injected properties are purely cosmetic (eg: labels, IO locations, slot names, etc.). 3) Your linked IOReg bears no relevance to the screenshots and OC EFI you posted (it shows Monterey kernel, MBP13,3 SMBIOS and SKL iGPU settings). To top it all, the Dortania display documentation you refer to is incorrect; most likely due to copy/paste errors. For instance, there's no such thing as device id 1b59006 for Intel HD 630 iGPU; trouble is that it is totally misleading and the Dortania folks are not (re)known for acknowledging and acting on requests for documentation adjustments. Looks like you're getting all confused (who wouldn't?). You need to do much further reading on the matter of properties injection and graphics settings. Or maybe it's time to give it a rest... I can suggest these links to begin with: https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units https://github.com/acidanthera/WhateverGreen https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards https://osxlatitude.com/forums/topic/17804-what-are-dvmt-stolenmem-fbmem-cursormem-why-do-we-patch-these-for-broadwell-and-later/ https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17587-how-to-spoof-hd520-to-hd620-in-monterey-in-preparation-for-ventura

Alternative links to https://xxxx can be macappstores://xxxx. Example for Ventura: macappstores://apps.apple.com/app/macos-ventura/id1638787999?mt=12

You need to understand that -no_compat_check boot arg applies to SMBIOS/Mac models dropped by the targeted macOS version. The parameter's sole purpose is to allow installing and/or booting a given macOS version on an officially unsupported platform; it's of no (direct) use for graphics acceleration. As such, it's entirely useless with SMBIOS MBP14,x, these Mac models remaining officially and fully supported under macOS Ventura. You would only use it with SMBIOS MBP13,x. Until now, unlike Haswell and Broadwell counterparts, Skylake systems have been able to obtain full graphics acceleration by using/faking KBL graphics with KBL SMBIOS and without any need for OCLP patching. Granted graphics acceleration has been difficult to obtain on HD 530 iGPU, not to say impossible on some platforms. You may consult the threads I had posted for Ventura beta (now in the Archive), my current E7270 guide or the initial Ventura beta thread at InsanelyMac. This being said, feel free to experiment with OCLP if you wish. The Precision 5510 EFI you've referred to clearly makes no use of stolenmem/fbmem patches/injections because DVMT already has the required value (64MB appears to be the default value according to your screenshot on p2). Do take good note that, if DVMT is set to 32MB, it is absolutely necessary to patch it for 4K output. Patching stolenmem and fbmem framebuffer properties won't do. That is clearly mentioned in Jake's FAQ on DVMT BIOS patching to which you had previously referred. In your case, you may experiment patching DVMT to higher values than 64MB. It also looks like you need to learn about the stolenmem/fbmem patches so you have some catching-up to do; it's been covered in all angles since 2015 when gurus such as Firewolf troubleshooted the issue of KP on Broadwell platforms due to DVMT vs. BDW framebuffer native settings. As for the RAM, it really is off-topic and unrelated to Hackintosh but it wouldn't be the 1st time Dell specs state something that's not entirely true on the matter (eg: good old Latitude D630/D830). How do you go about fitting 64GB of RAM? The answer is very likely to be so simple and obvious that it would leave you red-faced... Real question is whether you would need 64GB or not. But, again, off-topic, so let's close the subject.

SMBIOS for Hackintosh is basically a set of faked Mac computers hardware info (model, board id, serial number, etc, etc.) you inject to install and run OS X/macOS. There are various tools/apps to create/inject/update this if it's old/deprecated or if it needs to be changed to support a given macOS version (like after a new version drops older Mac models). OCC, CC, CLI tool (see Dortania documentation), etc. provide built-in SMBIOS generation facilities.

It probably will. Common sense dictates you experiment using a bootable USB key... As simple (and obvious) as that.

Experiment by yourself, you'll find out soon enough. The parameter usually applies to non-Metal GPUs and HD5500, albeit dropped in Ventura, is Metal compatible/capable though possibly not with Metal3.

You forgot the most important piece of information: details of your combo wifi/BT card.

We have a few guides for Sandy Bridge/HD3000 Dell Latitude models; look these up (eg: my Latitude E6220 guide). HD3000 graphics is last officially supported in macOS High Sierra. Thereafter, support can be provided with specific patches but limited to OpenGL mode only. HD3000 has no support for Metal and was already buggy on Hackintosh past OS X Yosemite 10.10 (over time: horizontal lines across the screen, pixelisation). Please note that this kind of platform is kinda obsolete for Hackintosh purposes given Apple's long abandonment for such 12yr old hardware. SSD can't be NVME since that the laptop is built on Intel QS67 chipset; so it can only be a good old SATA or mSATA model. Dell did not sold laptops with NVME-capable SSDs until Broadwell/Skylake generations.

As Jake said: leave SIP disabled (whether partially or fully), do not re-enable it (i.e. DO NOT set csr-active-config to 0). SMBIOS is irrelevant here, it's the OCLP patch for unsupported Haswell iGPU that requires SIP to be kept disabled.

Whilst these old Sandy Bridge E6x20 made great Hackintosh laptops in their days, they're unfortunately obsolete for recent versions of macOS given that Apple has long dropped support for HD3000 and nVidia Fermi graphics. Former was last officially supported in macOS High Sierra 10.13, latter in OS X El Capitan 10.11. Of course there are patches and various tools that'll bring back OpenGL-only support for HD3000 in Mojave and later but, since, Big Sur, such support is pretty poor and HD3000 was already buggy on Hackintosh laptops when it was still officially supported. You may refer to my old E6220 guide which goes up to Catalina (I subsequently sold the laptop). No such workarounds for the nVidia Fermi dGPU, it's a dead-end. If you insist on trying to run Monterey: make sure you install it without any config for HD3000, i.e. in VESA mode only. if you have a model with nVidia graphics, make sure you enable Optimus in BIOS (or laptop will only use nVidia dGPU) and disable the nVidia dGPU through a dedicated SSDT (available on the Net and Hackintosh forums through a Google search). Of course, Monterey will then run like crap due to lack of graphics acceleration. thereafter, install OCLP tool and apply only the graphics patches for HD3000. Make sure to install and boot Monterey with SMBIOS MacBookPro8,1 and the -no_compat_check boot arg. afaik, E6x20 laptops do not boot macOS USB installers when BIOS is set in UEFI mode, they only do so in Legacy mode. Once macOS is installed, you may change to UEFI mode and adjust your bootloader setup accordingly; it'll then work Ok. or you may simply opt to install say, High Sierra or Mojave, then upgrade to Monterey and apply the OCLP patch. That may be the easiest way to proceed. Good luck. Remember to post your E6520 specs in signature.