Hervé
-
Posts
10077 -
Joined
-
Last visited
-
Days Won
569
Content Type
Profiles
Articles, News and Tips
Forums
Posts posted by Hervé
-
-
Tools such as OCLP-nightly v3.0.0, OCLP-Plus version v3.1.x/v3.2.x or OCLP-Mod v3.1.x now provide patches that bring back support for legacy Wireless services (and AppleHDA) in Tahoe 26.x.
Such patching requires that the KDK (Kernel Debug Kit) for the target Tahoe version is installed. The tools do take care of this but it can be installed separately of course.
At time of writing, it is also necessary to boot with boot arg -amfipassbeta to avoid KP and reset/reboot.
Lots of details, known issues and troubleshooting tips are available in this InsanelyMac thread.
-
I've noticed that Clover versions past r5167 available through Clover Configurator app or through HackyCloverColor's Github repo no longer include the BlockSkywalk binary patch. As such, avoid them if you want to retain Broadcom wireless services in Sonoma and beyond. It's probably just a mistake and I've contacted the Dev on the matter.
For the moment, do not update Clover beyond r5167 which is the latest version to retain that patch.
-
It's pretty straightforward:
- update Clover to r5157 minimum; you may go up to r5167 but not beyond as I've noticed that r5169 to r5172 (obtained through Clover Configurator or CloverHackyColor Github repo) no longer include the BlockSkywalk patch anymore
- update your bootpack to the version I posted for Sonoma
- install Sonoma, either through Software update or through the AppStore (i.e. OTA update)
Bear in mind that Sonoma dropped all legacy Broadcom wireless cards so, if you have one of those, you'll have to use OCLP to bring back support. If this is the case, install latest OCLP before you upgrade to Sonoma so that it's readily available afterwards. See here for details:
-
My mistake, OC does indeed support CPUPM for Sandy and Ivy Bridge platforms of course (post above corrected to that effect). However, OC does not provide P States and C States generation and, as such, cannot properly support CPU power management for C2D and 1st gen. CORE platforms, only for LFM and HFM speeds. It's Ventura that dropped CPU PM for older CPUs up to Ivy Bridge by removing AICPUPM kexts.
I think you're looking at this a wee bit wrongly; you want to use "modern" kexts and OpenCore on an ancient platform and with an ancient OS X version; it's contradictory and makes little sense to me. And no, absolutely not, Clover is not "just an OC fork". It's better suited to older platform such as yours. It's still subject to development and I still use its latest versions on my E7270 with Sequoia and Tahoe with everything working perfectly...
-
Try and use kexts from the era of El Capitan; you may refer to guides/threads posted for similar C2D models.
As stated in a previous E6400 thread, OpenCore should be avoided on C2D systems because it does not support power management for old Intel CPUs up to 1st gen CORE models. I would recommend you stick to Clover which does; Clover is perfectly fine and best suited to this type of ancient Penryn laptops. You should also use the FakeSMC kext I had tuned for improved CPU power management and GPU throttling.
https://osxlatitude.com/forums/topic/2673-performance-tuning-with-fakesmc
https://osxlatitude.com/forums/topic/7807-nvidia-gpu-performance-tuning-with-agpm
I was able to get my old D630 nVidia up to Catalina (see my old D630 guide) so no reason why your E6400 could not do the same. Big Sur and beyond will be challenging especially as Apple dropped AICPUPM from macOS Ventura though it can be injected (see my E6230 old guide) and you'll need OCLP patcher, of course, to obtain support for Tesla graphics (last natively supported in High Sierra).
-
-
Hi, it's all a little long in the tooth after so many years now but the Latitude D630 and D830 with nVidia dGPU were very close cousins of these Inspiron 1520 laptops. You may want to compare the DSDT/ACPI tables of both models with those of your Inspiron 1520 on the basis that there were no shutdown/reboot issues on the D630/D830 under Mac OS X/OS X/macOS..
-
Updated following the release of macOS Tahoe.
-
Moved to the support section.
Again, this thread is not a guide, please post in the relevant section!
Yes, you need to update your usual add-on kexts: Lilu & PlugIns, RestrictEvents, AMFIPass, etc. See this thread about early findings with 1st Beta version and/or this one. If you need more, you know the drill...
-
Actually, 00009000 is 9MB and 00003001 is 19MB.
As I mentioned before, 4K usually requires a minimum of 64MB of pre-allocated DVMT so that the selected framebuffer can be run natively without patching. This is a value set in BIOS so, given yours is set to 32MB, you must find a way to patch BIOS. No way around this as far as I know.
-
Another thing you could experiment with is switching to KBL framebuffer 0x59160000:
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 87010000All you'd require would then be to:
1) patch stolenmem to, say, 30MB (=0x01E00000, which you specify as 00 00 E0 01). Other value to try is 26MB (00 00 A0 01)
2) patch con1 from 01050900 00040000 87010000 to 0204A000 00080000 87010000 (using framebuffer-con1-alldata patch))
3) patch con2 from 0204A000 00080000 87010000 to 03060A00 00040000 87010000 (using framebuffer-con2-alldata patch)
This is derived from here: https://www.insanelymac.com/forum/topic/345377-surface-pro-patch-the-framebuffer-properly-to-get-rid-of-the-dvmt-assertion-patch/
I don't know if that will bring support for 4K output (probably not) but it's worth a shot.
-
Any advanced settings in your BIOS setup?
If there are no specific settings for DVMT in your laptop's BIOS, you'll have to scrounge the Net for valid information I'm afraid. But I'm pretty sure it is 32MB by default, especially if you look at the Clover config posted in the repo you mentioned in your opening post:
One thing you can do, though, is experiment with fbmem and stolenmem values in the manner I described in my article linked above. As long as the sum of them remains lower than DVMT pre-allocated value, you'll be Ok. So you could try to boot with fbmem+stolenmem set to, say, 30MB, then boot with fbmem+stolenmem set to, say, 34MB. If you boot Ok with 30MB but not with 34MB, you'll know that DVMT is set to 32MB.
You use KBL FB 0x591B0000 which is defined as follows:
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- fbmem is set to 21MB
- stolenmem is set to 38MB
You therefore need DVMT to be set to at least 64MB to support the native framebuffer without patching. There is no way around this.
Afaik, you'll only be able to set DVMT to 64MB by patching your BIOS and, from what I've read on the Net, it looks like you'd need some EPROM programming equipment...
If nothing seems readily available, you could always post a BIOS mod request in the Hackintosh section of the bios-mods.com forum.
NB: your Lenovo X1 Carbon is a laptop so I would have expected the built-in screen to be attached to the usual connector con0, not con1 as you stated earlier.
-
You're highly unlikely to obtain 4K out of macOS with your current framebuffer patches:
Indeed, these apply the usual video memory patches (fbmem 9MB, stolenmem 19MB)) required when Intel DVMT is limited to 32MB. If, as I understood, you've set DVMT to 256MB in BIOS, then you can get rid of your fbmem + stolenmem patches. These are not compatible with 4K operation which usually requires DVMT to be set at a minimum of 64MB.
I therefore recommend you remove/comment out your fbmem and stolenmem patches. In the same respect, you're highly unlikely to require to set VRAM, i.e. unifiedmem, to 2GB.
-
Released September 15th, 2025.
Build 24G222.
Bug fixes and security update. Safe to install on our Hackintosh platforms.
Also released at the same time:
- macOS Sonoma Security Update 14.8 (Build 23J21)
-
Released Sep. 15th, 2025.
Version 26.0, build 25A354.
Tahoe is the last version for Intel platforms and marks the end of the long road for Hackintosh computers as we've known it since 2006.
It drops official support for all 8th gen. platforms + 9th gen. 2019 Coffee Lake MacBook Pro15,x and, somehow surprisingly, for 2020 Ice Lake-based MacBook Air9,1. This leaves final support for only a handful of 9th gen. and 10th gen. platforms.
This being said, support for Kaby Lake graphics survives, all KBL kexts remaining present, so good news to all owners of Skylake laptops who will all be able to run Tahoe with full acceleration through the SKL graphics patch that's been available since Ventura. For other older iGPUs, patches should hopefully remain available through OCLP tool (once updated and released) to regain graphics acceleration.
Officially supported Intel platforms are now limited to :
-
2020 iMac20,x (10th gen. Comet Lake)
-
2019/2020 MacBookPro16,x (9th gen. Coffee Lake and 10th gen. Ice Lake)
-
2019 MacPro7,1 (Cascade Lake)
NB: macOS Ventura is now unsupported.
-
1
-
-
Just you... A call to Apple support will probably sort it out.
-
Not a guide -> moved to the support section.
Local zipped copy of the OC EFI added without the Resources folder and all the Intel stuff for the AX210 wireless card.
-
Released September 2nd, 2025.
Build 25A5351b.
Available via OTA update:
All Ok.
Same Clover bootpack as for beta 1 to beta 8.
-
Released August 25th, 2025.
Build 25A5349a.
Available through OTA updates.
Same Clover bootpack as for beta 1 to beta 7.
-
Released August 18th, 2025.
Build 25A5346a.
Available through OTA updates.
Same Clover bootpack as for beta 1 to beta 6.
-
1
-
-
Released August 11th, 2025.
Build 25A5338b.
Available through OTA updates.
Same Clover bootpack as for beta 1 to beta 5.
-
Released August 5th, 2025.
Build 25A5327h.
Available through OTA updates.
New icon for disks/volumes.
Same Clover bootpack as for beta 1 to beta 4.
-
Please stick to macOS/Hackintosh related matters/topics...
-
Re: UEFI, I did find out that it would not/coud not boot a USB installer with BIOS in UEFI mode but it certainly could boot macOS once installed. See the instructions for Mojave/Catalina of my E6220 guide for reference. In the end I could boot my E6220 in UEFI mode and without patched DSDT, just a very small set of patched SSDTs, 2 of them being to bring support for the screen brightness Fn keys (otherwise IMEI, PM and PNLF sufficed!). In the same respect, not may kexts were required (and forget about lspci one which was optional and only necessary for the lspci tool).
There is no need to patch the kernel with Sandy bridge or Ivy bridge platforms like there was for Haswell and later platforms. All that is needed with regards to CFG lock is the AICPUPM patch. If you want to binary patch the kext yourself, do look at the specific thread that was posted on the matter many years ago. Of course, you need to generate the CPU PM SSDT that suits your own specific CPU model and, to that effect, you have to use the old ssdtPRGen script/tool that Pike R Alpha provided all those years ago.
All I ever dropped in terms of SSDTswere the expected CpuPM + Cpu0Ist; 'never had to drop MCFG or whatever else...
All in all, your writing style remains difficult to understand/decode and I think you're kind of all over the place so I suggest that, if you want further assistance, you post:
1) the hardware details of your E6520 (HD3000 only model or nVidia model?)
2) a zipped copy of your Clover/OpenCore EFI folder(s) (just include the config file, the ACPI folder and the kexts folder)
You'll find details of the recommended BIOS settings for E6x20 laptops at the top of this very E6xxx forum section. I strongly recommend that you consult existing E6x20 installation guides. I went up to Catalina on my E6220 before I sold it off and it ran in UEFI mode. I explained how in the High Sierra instructions of my guide. You could also find my E6230 guide interesting for more recent versions of macOS (Big Sur and later).
You want Monterey, ok (it's the last version to natively support Sandy bridge CPU PM) but why not stick with Clover if it works?
Dell Latitude E7270 with i7-6600U, HD520 and 1920x1080 Touchscreen - High Sierra/Mojave/Catalina/Big Sur/Monterey/Ventura/Sonoma/Sequoia/Tahoe
in Dell
Posted
Target macOS release:
This is a Clover-based installation using the well-known/well documented vanilla method detailed below:
Working:
Not Working:
Not tested:
With regards to Skylake/HD 520 graphics, same principles apply as for macOS Sonoma and Sequoia but make sure to update Lilu & PlugIns to latest versions:
1) 26.x USB installer creation
where:
The process will take several minutes. Once completed:
2) 26.x installation
3) Post-installation tuning
4) Adding support for audio and legacy Broadcom wifi