Hervé

It's indeed a D620 with nVidia graphics. Can't remember if the D620 10.6.8 packs will work with 10.6(.0) but, from memory, it should. We have copies of myHack v3.1.2 and v3.3.1 here and they're fully kosher so no need to get those off Web archives. Make sure you use a retail version of SL 10.6(.0) as only the retail copies have the full installation files that are required. Retail copies existed for 10.6(.0), 10.6.3 and 10.6.8. The other versions exist as recovery sets only and are no good for fresh installations. As you wrote yourself, CoreDuo means SL only, not Lion. Ideally, you may want to consider replacing your current CPU by a high-end FSB667 Merom Core2Duo T7x00 (T7200, T7400 or T7600). It's old stuff but these cost pennies today on the 2nd hand market and would allow you run run Lion (or MLPF'ed ML if you were game). Make sure you've configured your BIOS as per the recommended settings posted in the dedicated thread in this very section. MBR patch is only of any use if you try or want to install SL on a disk with MBR partition scheme. If SL is the only OS you intend to run, just reformat it from your USB installer as GPT/HFS+ (Mac OS Extended) using Disk Utility once you reach the main installer screen. I'm no longer 100% on this (it's old stuff and too many years have passed) but it may well be that the DW1397 or DW1395 (BCM4312 wireless card) in that D620 are causing trouble so you may want to try and disable Wireless in BIOS until you've actually installed SL. Good luck! NB: lspci -nn is more useful command than lspci -vv.

It's the fbmem patch that prevents the graphics glitches and defects as explained in our HD4000 patching guide; so make sure you implement it. You do not modify/patch memory count, pipe count, port count or stolenmem with LoRes/4-port layout 0x01660003, only with HiRes/1-port layout 0x01660004. Therefore, your framebuffer patch for iGPU@2 should set the following parameters to the following values: ig-platform-id -> 03006601 // LoRes/4-port Capri mobile layout framebuffer-patch-enable -> 1 // enables framebuffer patching framebuffer-fbmem -> 00008000 // reduces framebuffer memory from default 16MB to 8MB framebuffer-conX-enable -> 1 // enables conX patching, where X is your identified connector for HDMI output port framebuffer-conX-type -> 00080000 // sets conX to HDMI type, where X is your identified connector for HDMI output port hda-gfx -> onboard-1 // for HDMI-audio and nothing else. Target connector will most probably be con1. In the future, please post system's specs (add those in signature!) and copy of your bootloader config so that it can be properly read with the relevant tools, rather then leave people use Base64 to Hex/Text converter to decode your patches... Here, we assessed it was a Clover config but also specify this sort of things. For a complete and detailed set of information on framebuffer patching, I invite you to consult the Whatevergreen user manual: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md

Not that it'll help you much but I prefer to advise you that, afaik, no Hackintosh laptop ever got its Wifi LED to lit when running OS X/macOS. It's something that appears universally unsupported.

You have to properly create your Big Sur installer with the usual createinstallmedia command. Process is explained on Apple's web site and in most of our published guides so look it up. OC will then offer you the option to boot this Big Sur installer. You can't just copy the macOS installation package on the USB key, that will do absolutely nothing.

Did you verify your cable was Ok? LAN card set to auto-neg or some fixed 10/100/1000Mbps settings? MAC address of your card sure is listed in IOReg. Or maybe version 2.3.0 of the kext is inadequate for Big Sur. Try version v2.4.0 posted by Mieze on her Github repo and at InsanelyMac. Also check the latest info posted on the dedicated RTL8111 thread at IM. That's where Mieze discusses her development work on the driver and where people report on their experiments. If v2.3.0 or v2.4.0 do not work, try the previous versions; I've seen people reporting issues such as yours with version 2.3.0/2.4.0. You'd also read this in the comments left for this driver posted in the Download->kexts->LAN & Wireless section at IM.

Realtek RTL8111 driver is clearly loaded and Ethernet card appears functional. What's not working of course is the Qualcomm Atheros QCA6174 WLAN card; that's unsupported under OS X/macOS and will need to be replaced.

For screen brightness, add the SSDT-PNLF.aml table; it's missing. Please note that you should: not use 2 x SSDT EC tables, only one to keep things clean and avoid confusion. in the same respect, review the ACPI renaming patches you've configured in your OC config file; for instance, I see at least 3 x patches for EC device and I guess only one applies. Same goes for USB or audio devices. Of course, those that do not apply make no harm but it's a little messy.

Big Sur is not known to run slower than its predecessor so I'd say that you've either lost CPU SpeedStep/power management (and laptop runs at LFM) or you've lost graphics acceleration. You should be able to verify CPU operational status through apps such as HWMonitor (if you've installed FakeSMC's PlugIns or VirtualSMC PlugIns) or Intel's Power Gadget tools and graphics acceleration through the normal checkups (About this Mac, LaunchPad, Finder's bar & Dock translucency, etc.). Ideally, post your debug files or at least IOReg extract and zipped EFI folder (Clover or OpenCore).

[Recovered backup of old article from 5th May, 2013] So, you got Mac OS X running on your favourite PC and you want to optimise performance? A bit of fine-tuning might be possible with FakeSMC kext and SMBIOS plist. Your Hackintosh needs to be running on native CPU power management of course (with P & C States set in Chameleon boot plist), not under null management. Our R&D top man Mario (aka. Bronxteck) recently played around on the matter. Moving away from our EDP-provided FakeSMC, he used one of the latest FakeSMC versions and started editing it according to Apple’s latest SMC list. Having noted some CPU + graphics performance issues under Mountain Lion on his D630 nVidia (Intel T9300 2.5GHz FSB800 CPU, nVidia Quadro NVS 135M GPU), Mario was initially looking at pushing up the GPU clocking to fix video juttering and getting SpeedStep to run better. I joined him in the testing phase and we were able to obtain native SpeedStep operation + improved GPU clocking (and therefore improved graphics/video performance) on our respective D630 nVidia (ML 10.8.3) which, by chance, run on the same Penryn T9300 CPU. Our tests were only conducted under ML, i.e. in 64bit mode. By default, EDP uses FakeSMC v4.0 and MB3,1/MBP3,1 SMBIOS for the D630 laptops. Mario and I had already changed SMBIOS from MBP3,1 to MBP4,1 using Chameleon Wizard, but after thorough testing, video/graphics performance was found not to be 100% optimal and some juttering could be observed when watching video or switching rapidly between desktop screens through key-strokes such as Ctrl-UP, Ctrl-DOWN or Ctrl-LEFT. Looking at Apple’s latest support page for EFI and SMC Firmware updates for Intel-based Macs that provides version details, Mario installed FakeSMC v5.1.59 and edited the kext plist to try different SMC versions. In addition, Mario was not entirely satisfied with EDP’s emulated SpeedStep facility (VoodooPState kext + PStateMenu app) which was required to obtain CPU throttling: without it, the T9300 CPU would only run at its lowest multiplier/frequency (x3 / 600MHz!) and with it, he found frequency changes a bit lagging. After some trials, we found that editing FakeSMC plist to use SMC versions of MBP5,1 and loading MBP5,1 SMBIOS plist gave us excellent graphics/video performance with nVidia GPU core/memory clocking efficiently between 275/300 and 400/594MHz during video playouts, thereby rendering an extremely smooth video and leading to an excellent quality of experience. As an added bonus, we also found that SpeedStep was now natively operating and that CPU stepping appeared much more rapid than with emulated SpeedStep. Mario also reckons the battery lasts a little longer. Naturally, emulated SpeedStep has to be removed in order to verify native SpeedStep operation, so if you have emulated SpeedStep installed, remove VoodooPState.kext from /Extra/Extensions (remember this will require a subsequent myFix (full) to rebuild kext cache) and remove PStateMenu.plist from /Library/LaunchAgents. The same applies to IntelCPUMonitor kext which goes with older FakeSMC version (v4.0 for instance) and now has to be removed. Note that systems based on Intel 945GM/PM chipset must keep VoodooTSCSync kext, whilst other systems can get rid of it. All in all, this has made for a substantial performance optimisation of our D630 nVidia Hackintoshes and something really worthy of a trial on other systems. Here are details of things to do: 1/ make a precautionary backup of your existing FakeSMC kext (found at usual location in /E/E folder) 2/ download a copy of FakeSMC kext v5.1.59 (64bit only) to your desktop 3/ download a copy of Plist Editor Pro 4/ lookup for the Apple Mac model that best matches your own Hackintosh at EveryMac.com (you may also look at the various profiles available in the Chameleon Wizard SMBIOS tab) 5/ in Apple’s EFI and SMC list, identify the SMC version most likely to match your system specifications and take good note of it. This is the information required to be used subsequently. 6/ open up the FakeSMC kext package and, using Plist Editor Pro, open up the Contents/info.plist file 7/ in the upper part of the editor, open down IOKitPersonalities->SMC Device Emulator->Configuration->Keys 8/ At the bottom of the Keys list, open down REV, RVBF and RVUF. By default, FakeSMC is using SMC version 1.30f3 which is displayed in Data field as 01300F00 0003. 9/ in order to modify FakeSMC to a different SMC version, all of these 3 keys have to be modified. This is done by double clicking on the 6bytes value and replacing it by the targeted SMC value. 10/ Once this is done, close Plist Editor Pro, move or copy the modified FakeSMC kext to /E/E, run myFix (full) to repair permissions and rebuild cache. Then, with Chameleon Wizard, change your SMBIOS plist to the new targeted version. 11/ download HWMonitor tool v2.3.7 and run it (close and remove any other or previous version you might have been using). This particular version supports the enhanced features of the newer FakeSMC kext such as GPU/memory frequencies, thereby providing improved monitoring capabilities. Click on the associated menu bar icon and configure it to display your desired items (eg: CPU T°, GPU T°, GPU/mem frequency) and to run automatically. 12/ Your Hackintosh can now be rebooted. BIOS IDA settings may be re-enabled, depending on CPU model. In the case of our D630 laptops with T9300 CPU and nVidia Quadro NVS 135M, Mario and I tried the SMC version listed for the 15″ MacBookPro5,1 -> 1.33f8 (SMC 1.2). This translated to 6bytes Data 01330F00 0008. On reboot, video play out was extremely smooth (even whilst doing desktop screens swaps) and GPU core/memory frequencies could be seen switching between 275/300 and 400/594MHz. The frequencies showed idling at 168/100MHz. These basically matched the expected/documented specifications of the nVidia Quadro NVS 135M whereas, when using the MPB4,1 profile, the GPU frequencies did not seem to go beyond 275/300MHz. On removing emulated SpeedStep (by removing VoodooPState kext from /E/E and PStateMenu plist from /L/LaunchAgents), HWMonitor also allowed us to see that SpeedStep was natively running as CPU clock stepping could clearly be observed. We even noticed that IDA could be re-enabled in the BIOS without impacting the FSB. Perfect! The only little bug I noticed with HWMonitor 2.3.7 is that reported GPU/memory frequencies tend to get stuck at highest values after a while. However, the reported GPU T° tends to indicate that it is not the case… Using same MBP5,1 settings, similar results were observed on D830 nVidia 135M with T7250/T7500 CPUs under ML 10.8.3. Compared to the D630, the differences were lower GPU memory frequencies (whilst GPU core clockings were identical) and no IDA support with that CPU family (re-enabling IDA caused FSB to drop from 200 to 182MHz, thereby lowering all CPU clockings by approximately 10%). So, to your keyboards lads and good tuning! And, once again, thank you Mario for the research work. NB: most of this derives from Prasys’ own work. EDIT: Kozlek has updated these FakeSMC kexts & plugins since this article was 1st published. One major change for us is the ability to compile the code in 32bit mode and apply this tuning to our Hackintoshes that run 32bit kernel only: I’m now getting native SpeedStep on a D630 Intel X3100 with a 2.2GHz T7500 under Lion 10.7.5 (no IDA support). EDIT #2: Aug 2013 New tests were conducted with Kozlek’s FakeSMC v5.2.678 in 32/64bit mode. All Ok on numerous systems that we’ve tested. Don’t hesitate to use and try by yourself. More recent versions of HWMonitor also provide more information, so I’d recommend to use HWMonitor 5.2.678 too. Tests were also done with 5.2.755, but not all systems seemed to support that version. View full article

You're gonna need to be a little more forthcoming with info if you expect assistance. Please post: system's specs zipped OC EFI folder debug info such as a zipped copy of an IOReg extract

There is no such pack posted here afaik but feel free to start on the matter. You could start by looking into the existing stuff posted in this very section for the Inspiron 5559.

Jake Lo gave you a link that leads to what's pretty much a step-by-step guide and a very recent one too; all you have to do is follow it. You'll gain experience with OC by experimenting and it is really not that hard to grasp. As a beginner, I found it easier to understand OpenCore than Clover.

Very old and totally obsolete stuff nowadays but you can make your USB installer with myHack tool/app (available on this forum) and the relevant D620 bootpack (also available on the forum in this very section). myHack Requires an existing Mac, Hack or VM running SL 10.6, L 10.7, ML 10.8 or Mav 10.9. It's not supported on pre-SL and post-Mavericks versions. Make your USB installer and then install Mac OS X by following the on-screen guidance. The bootpack consists of the full Extra folder that you will need to point to and install when prompted so by myHack. If you're not prompted for the bootpack (Extra folder), use the dedicated menu option of myHack to install it. This applies to the USB installer and the actual Mac OS X installation. Please note that you won't be able to do much with old Mac OS X versions such as SL and Lion (anything older than Yosemite in fact) and old Web browsers available for SL and/or Lion are no longer compatible with most Web sites. But SL flew on these D620 with decent specs (say [email protected] CPU, 4GB RAM and a 7200rpm HDD). Same applies to Mountain Lion if you went ahead with the old MLPF hack that allows to run a bastardised DP1 version of ML on these old officially unsupported systems.

Well, obviously, it could not have been done properly, so you need to revisit the steps you followed. You must have missed something along the way, maybe the boot file.

You need a lot more than that to update OpenCore. You need to download the whole package and replace the various drivers you use, modify or suppress bootstrap, update resources, etc. Please refer to the OpenCore documentation on the matter. The packs posted here usually only contain the specifics for the target model, not the entire OpenCore arrangements.

Bluetooth is USB-based and so should work once you sort out your USB ports problems.

Try and cache CodecCommander kext from /L/E. I'm not sure it'll inject successfully from OC kexts folder, but you can always try.

@kcmok Please note that hexadecimal values specified as DATA in properties injection must be entered in reverse byte order. So, if you want/need to inject graphics framebuffer layout 0x59160000, you must enter value 00001659. It is read byte by byte, from right to left: 59-16-00-00.

Check your drivers settings; you appear to call on AudioDxe.efi which is reporting missing. So either you add it to your driver folder or you remove its reference from your OC config. OpenCore has zero tolerance for that sort of things and its the same for kexts and their order (re: PlugIns). One thing wrong and your boot fails.

Well, I think it's pretty much a closed matter: systematic black screen if you only run on the nVidia dGPU (Optimus disabled). All those tests are useless if they can only be completed with Optimus enabled, i.e. when you run on the HD4600 iGPU. So, as far as I'm concerned, you'll have to accept that you need to run with the HD4600 iGPU knowing that the nVidia dGPU can clearly be used for external screens (at least HDMI). There's probably a good chance you would not get any HDMI output if you disabled the dGPU through ACPI patching. But do that if you're never gonna use an external screen and you want to save battery life when you run macOS.

Obviously, the value shown in IOReg is the one in use... So you may try and experiment with the tool mentioned at Dortania. No guarantee that any of this will bring life to the built-in LCD with nVidia graphics-only of course. One other thing to try is boot your Big Sur (or any other macOS version) USB installer and, once (or if) your reach the installation screen on the built-in LCD, open up Terminal to check the NVCAP value in IOReg with the following command: ioreg -l | grep NVCAP It may show a different value that what you previously had. That's how I got VGA output to work on the GT730 fitted to my old C2D desktop: initially, I had no VGA output -only DVI-D and HDMI- and NVCAP was showing a given default value once system was booted up. One day, after my partition got corrupted, I rebooted the USB installer with dual DVI + VGA screens connected and, to my surprise, the VGA screen was active and displaying video once I reached the macOS installation screen. On checking the NVCAP value in IOReg, it showed a different value than the one I had before. Once I injected that value in my bootloader config file, I've had all outputs fully working ever since, including VGA.

Oh that's right, I had also mentioned NVCAP but not provided a specific value, just listed the one shown in your IOReg (which is gone now). Basically, with Intel iGPUs, video outputs are handled through connectors and connector types (LVDS/eDP, DVI, DP, HDMI) whereas, with nVidia graphics, it's the NVCAP value that defines the video outputs. It's somehow detailed in the Dortania documentation at following URL but, with a Google search, you would also find old threads on the Net in other Hackintosh forums about it: https://dortania.github.io/OpenCore-Post-Install/gpu-patching/nvidia-patching/

Looks like our server took a hit this today and all posts/threads made since Sunday afternoon or Monday are gone. Rest assured there was no Moderator's/Admin's actions to deleted posts/threads. Sorry but I can't remember all that I had posted but I believe I had stated that your posted IOReg showed built-in LCD attached to HD4600 iGPU and an external monitor attached to the nVidia dGPU (I think it was HDMI). I had re-affirmed my belief that the built-in LCD is probably wired to/controlled by the iGPU but, having looked at your OC config, you could try the following boot-args adjustments with Optimus disabled in BIOS (i.e. only nVidia dGPU active): given that you are using MBP11,5 SMBIOS, i.e. a fully supported platform in Big Sur, you could remove the -no_compat_check boot arg of your OC config since it's unnecessary and will prevent Big Sur updates from being offered to you. change your csr-active-config value from 0x7FF to something where the 2nd nibble does not set bit 5 to 1 which enables Apple Internal. When that SIP flag is enabled, Big Sur updates are not offered. As such, you may change your value to 0x7EF. I recommend you consult our dedicated thread on disabling SIP that's available in our FAQ section. add boot arg agdpmod=pikera or agdpmod=vit9696 in case Apple Graphics Device Policy is somehow responsible for black built-in screen. With such boot arg, AGDP will be disabled/bypassed.

You have an eDP display type. Connector type is the same in OS X/macOS at least for Intel iGPU. Please note that things are very different with nVidia dGPUs with which output port types are controlled by NVCAP (and the registered connector type does not really matter). As I said, none of this really matters if the built-in LCD is wired to/controlled by the Intel iGPU...On the other hand, you may find that external output such as HDMI are controlled by the dGPU. You'd have to check that out in IOReg having opted for iGPU as main graphics card with Optimus enabled in BIOS and the dGPU not disabled.