Jump to content

Hervé

Administrators
  • Posts

    10077
  • Joined

  • Last visited

  • Days Won

    569

Hervé last won the day on October 29 2025

Hervé had the most liked content!

About Hervé

Recent Profile Visitors

115994 profile views

Hervé's Achievements

Brigadier General

Brigadier General (17/17)

1.2k

Reputation

29

Community Answers

  1. 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.
  2. As stated when 1st beta was released and confirmed when it was officially released, Sonoma dropped support for Broadcom cards that were supported up to Ventura. A solution based on OpenCore bootloader and the OCLP Patcher has been available since mid-summer 2023. Nothing new on the matter as I post this article in January 2024, except that, good news for Clover users (yes, we still exist!), the solution now works with Clover too and is no longer limited to OpenCore. The issue for Clover users was that there was no readily available solution to block vanilla IOSkywalkFamily kext from being loaded at startup, even when trying to do this through patching the Info.plist file of the kext in the Clover config. No matter what, as long as the vanilla kext loaded/was cached, injecting the replacing kext would result in immediate Kernel Panic. This was finally resolved in Clover r5157 which integrates a kext patch in the form of a flag that can be enabled in the Clover config: BlockSkywalk (NB: it does not work with version r5155 or r5156). With this patch enabled, the abandoned IO80211FamilyLegacy from previous macOS version can be loaded/injected and so can the older/replacement version of the IOSkywalkFamily kext that is required. This being put in place, the OCLP patcher can then be used to apply the wireless root patch (whether Modern wireless or Legacy wireless) to finalise the Sonoma wireless fix. Broadcom cards that we all previously used up to Ventura, whether DW1560 (BCM5352 chipset), DW1820A (BCM4350 chipset) or Apple's own BCM94360xxx (BCM4360 and related chipsets) can now be used in macOS Sonoma exactly as they could in Ventura and earlier macOS versions. See our dedicated thread on the matter for full details.
  3. Target macOS release: Tahoe 26.x This is a Clover-based installation using the well-known/well documented vanilla method detailed below: Working: full QE/CI with HD520 graphics (with KBL layout 0x59160000, KBL faked id 0x5916, MBP16,2 SMBIOS and Lilu kext v1.7.2 + Whatevergreen kext v1.7.0 or later) HDMI output OOB but built-in LCD goes off on 1st cable connection. With WEG boot arg igfxonln=1, LCD picture is recovered after closing then re-opening the LID and HDMI is on at 1st boot & after wake mDP output OOB touchscreen with USB HID fix (patch of IOHIDFamily to fake single-user mode) due to Apple dropping support for old USB hardware full audio, including jack microphone input and headset output (with AppleALC kext & layout-id 11 after OCLP-Plus patching) HDMI audio (with KBL con1 connector-type patch) built-in Gigabit Ethernet (with IntelMausiEthernet kext) full CPU power management, including Turbo boost to 3.4GHz (with PlugIn type settings) sleep: Ok through Apple menu->Sleep, lid closure, power button, Fn-Insert and energy savings settings with hibernation mode set to 0 (sleep to RAM) and /var/vm/sleepimage file deleted. wake: Ok through lid opening and power button wireless & bluetooth with any compatible card/USB dongle and necessary patching (after OCLP-Plus patching) battery management and monitoring (with ACPIBatteryManager kext) SD card reader (with 1Revenger1's RealtekCardReader kext) integrated webcam OOB keyboard backlight control OOB (for backlit models) audio volume control through Fn-F1/Fn-F2/Fn-F3 brightness control through Fn-F11/Fn-F12 touchpad basic features, incl. buttons (with Rehabman's modified VoodooPS2Controller kext; it has a Tahoe-specific VoodooInput Plugin) USB3.0 ports (with Hackintool's generated SSDT_USBX & SSDT_UIAC patched tables or USBPorts kext) Not Working: N/A Not tested: SmartCard reader 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: use of Kaby Lake framebuffer 0x59160000 (0x591B0000 may also be used but requires further graphics connectors patching) fake Kaby Lake HD620 iGPU id 0x5916 use Lilu v1.7.2 and Whatevergreen v1.7.0 minimum 1) 26.x USB installer creation Using a USB key of 16GB minimum, create a Tahoe USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Tahoe.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Tahoe 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 bootloader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI Drivers Recommended drivers FSInject SMCHelper Human Interface Devices (optional) Ps2MouseDxe UsbMouseDxe FileSystem Drivers ApfsDriverLoader Memory fix drivers OpenRuntime Additional Drivers (optional) NvmExpressDxe PartitionDxe Themes (optional) BootLoaderChooser (optional) CloverConfigPlistValidator (optional) Install Clover Preference Pane (optional) you may use Clover version r5167 as attached below (at time of writing, stick to this version max.) Clover_r5167.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer (attached version supports BlockSkywalk kext patch) Clover Configurator.zip add the (unzipped) HFSPlus driver attached below to the EFI/CLOVER/drivers/UEFI folder HFSPlus.efi.zip open this EFI partition and transfer/copy the files & folders from the Latitude E7270 Tahoe Clover pack below to the EFI/CLOVER folder Clover_Bootpack_E7270_Tahoe.zip download the latest OCLP-nightly or OCLP-Plus app from their respective repos and save the package at the root of the USB installer. It'll be required to recover audio and support for legacy Broadcom wifi. 2) 26.x installation boot the Tahoe USB installer at the Clover main menu, select the "Install macOS Tahoe" partition (but don't press [ENTER]) press [SPACE], select -v verbose option in the menu, then choose to boot with the selected options proceed with installation, creating & formatting the target Tahoe installation through Disk Utility as/if required on 1st reboot, boot off the USB installer and select the freshly created "macOS install from <target Tahoe partition>" repeat this until this partition is no longer offered and only the target Tahoe partition is left to boot Reboot the target Tahoe partition via your USB installer 3) Post-installation tuning once the target Tahoe partition has booted, complete the 1st boot configuration tuning once at the desktop, install Clover bootloader on the Tahoe partition/disk with the customised settings listed above once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the Tahoe partition/disk open this EFI partition and transfer the files & folders from the above Latitude E7270 Tahoe Clover pack to the EFI/Clover folder you may then reboot and verify that Tahoe boots off your disk through Clover at that stage, the E7270 will be running Tahoe without support for audio and legacy Broadcom wifi 4) Adding support for audio and legacy Broadcom wifi launch Clover Configurator app and mount the EFI partition of the Tahoe partition/disk add the kexts from the Legacy Broadcom Wifi pack below to the EFI/Clover/kexts/Other folder alongside the existing kexts Legacy_Broadcom_Support_Pack_Tahoe.zip open up the Clover config in Clover Configurator and check/enable the BlockSkywalk kernel & kext patch add -amfipassbeta boot arg add -revpatch=sbvmm boot arg (to obtain OTA updates) save the configuration you may download and install the latest KDK (Kernel Debug Kit) for your Tahoe version though OCLP-Plus should do it reboot then install the OCLP-nightly or OCLP-Plus app from the package previously downloaded and launch it proceed with root patching which should automatically detect that wireless networking and audio requires patching after another reboot, audio and wifi off the legacy Broadcom cards will be fully functional again if in doubt, check this thread for detailed guidance.
  4. 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.
  5. 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. Clover_r5167.pkg.zip
  6. 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: https://osxlatitude.com/articles/misc/support-for-broadcom-wireless-cards-in-sonoma-later-clover-and-opencore-r84/ https://osxlatitude.com/forums/topic/19730-wifi-in-sonomasequoiatahoe-patching-for-legacy-broadcom-wireless-cards/
  7. 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...
  8. 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).
  9. 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..
  10. 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...
  11. 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.
  12. 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 87010000 All 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.
  13. 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.
×
×
  • Create New...