Jump to content

Hervé

Administrators
  • Posts

    9900
  • Joined

  • Last visited

  • Days Won

    547

Community Answers

  1. Hervé's post in [Solved] E6530: dGPU is disabled in Windows after reboot from MacOS was marked as the answer   
    Ok, so dGPU remains disabled on warm reboots from macOS into Windows. There are only a few ways to address this:
    you opt for the boor arg option rather than the patched ACPI code. you call on your EGPU ACPI code on macOS shutdown to re-enable the dGPU; that should be handled by an event that you need to identify. Maybe one of those EV methods. you power off your laptop when you want to boot Windows.
  2. Hervé's post in [Solved] Latitude 5401: Reboot loop after second installation stage on Sonoma was marked as the answer   
    What version of Sonoma?
    What version of OpenCore?
    Try and set SecureBoot to disabled rather than default. I understand that's required for Sonoma 14.4.
  3. Hervé's post in [Solved] Dell Precision 7530: HDMI Port issue was marked as the answer   
    That would be perfectly normal since CFL framebuffer layout 0x3E9B0007 is for desktop computers and offer 3 x DP connectors but no LVDS connector for laptops:
    ID: 3E9B0007, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00801302 TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel UHD Graphics 630 Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 01050900 00040000 C7030000 02040A00 00040000 C7030000 03060800 00040000 C7030000 You would need to patch connector con0 to laptop's settings to hope for your built-in screen to work. For instance to this:
    00000800 02000000 98000000 as per CFL framebuffer layout 0x3EA50009 as I illustrated above.
     
    Setting the framebuffer layout to mobile may help too.
  4. Hervé's post in Latitude 7480: Grey screen on USB key boot was marked as the answer   
    You do reset NVRAM from the OC Picker after each config change, right?
  5. Hervé's post in [Solved] D630 (GMA X3100): Blinking white line when attempting to install Snow Leopard was marked as the answer   
    That's where you get it wrong. To apply the bootpack, you have to run myHack and load/apply it with myHack, it's one of the option in the pop-down menu (called "Install Extra" from memory). Copying/pasting it to the USB key won't do.
     
    Please note that T7250 is a little Merom CPU running at 2.0GHz and fitted with only 2MB L2 cache. Performance won't be great, even more so if you run off a mechanical HDD, whether 5400rpm or, preferably, 7200rpm.
  6. Hervé's post in [Solved] E6430: Locking up when waking from sleep was marked as the answer   
    You run with the config you used to install Big Sur on this unsupported platform which is using MBP11,1 SMBIOS. Whilst this allows you to keep Big Sur updated, my experience is that it prevents proper CPU power management. You should therefore make a backup of this config (for future use to update Big Sur) and revert SMBIOS to MBP9,2 or MBP10,2 and add boot flag -no_compat_check of course. Also make sure you've disabled hibernation as per the dedicated thread in our FAQ section.
     
    You may also have opted for something incorrect when you applied the OCLP patch. But only you can tell us what you did in that respect...
     
    NB: There is no limitation to 4 lines for your signature; you must be confusing OSXLatitude with InsanelyMac...
  7. Hervé's post in [Solved] Lenovo Thinkpad L570: Ventura installed but not everything works was marked as the answer   
    Audio should work with the exact same settings you previously had for Monterey. There should be no issue at all on that matter. Same applies to brightness control.
     
    For Wifi and Bluetooth, you need to consult the information available on the ITLWM site. Development for Ventura remained at early alpha stage until very recently (I've not checked status for several weeks) so make sure to check the latest information published by the devs.
  8. Hervé's post in [Solved] E7470: Monterey to Ventura was marked as the answer   
    Means you need to fake Kaby Lake (KBL) graphics since Skylake (SKL) graphics are no longer supported, Apple having dropped support for all pre-Kaby Lake MacBook platforms (+ others) in Ventura.
    Also look at the WhateverGreen User Manual and our GPU support thread.
  9. Hervé's post in [Solved] Dell E5440: no HDMI audio was marked as the answer   
    Your posted IOReg shows:
    external display on con2 (FB @2), not con1 (FB @1) con1 patched to HDMI type (as per your OC config) -> [...]con1-alldata 01051200 00080000 ... con2 patched to DP type (as per your OC config) -> [...]con2-alldata 02041200 00040000 ... If your external display on con2 is indeed HDMI, you need to patch its type accordingly, i.e. not to DP (0x0400) but HDMI (0x0800).
     
    NB: No need to patch fbmem or stolenmem for Azul frame buffers (i.e. Haswell iGPU HD4200/HD4400/HD4600/etc.). You can remove those from your config and only retain the cursormem patch if you found it necessary (in case of cursor graphics corruption).
  10. Hervé's post in [Solved] CCC: Ventura cloned drive won't start was marked as the answer   
    Don't hesitate to scrounge the Net before asking on forums...
     
    CCC probably best avoided with Ventura; there are lots of unresolved known issues.
    https://bombich.com/kb/ccc6/macos-ventura-known-issues
    https://bombich.com/kb/ccc6/cloning-macos-system-volumes-apple-software-restore
    https://www.reddit.com/r/MacOSBeta/comments/xah1pm/carbon_copy_cloner_mac_os_ventura/
     
    My understanding is that you will not succeed trying to boot a cloned OCLP-patched Ventura installation; at best -if that works at all !- you would need to either:
    1) clone your basic, i.e. unpatched, Ventura installation prior to OCLP patching; you may then patch your cloned disc.
    or
    2) unpatch your Ventura build, clone it, then repatch; and, of course, patch your cloned disc afterwards. 
     
    Do consider that, since Big Sur -even more so with Ventura-, CCC (and other apps such as SuperDuper) are no longer reliable for macOS disc cloning, especially on Hackintosh running patched installations for unsupported hardware. Issues are related to (sealed and encrypted) snapshots. Many people have written about this if you care to search the Net.
     
    Also consider alternative bootable disc cloning solutions for macOS Ventura (if such things do exist and they may not be free):
    https://www.doyourdata.com/disk-copy/best-disk-clone-software-for-macos-ventura.html
    https://www.doyourdata.com/disk-copy/make-bootable-backup-clone-for-mac.html
    https://www.donemax.com/mac-disk-clone/clone-macos-ventura-to-external-hard-drive.html
  11. Hervé's post in Latitude 7480: Unable to obtain 4K resolution on external monitor through TB->DP port was marked as the answer   
    Did you check the default DVMT settings of your 7480? Under macOS, DVMT must usually be set to 64MB or 96MB to obtain 4K output; afaik, you won't get it if DVMT is set to 32MB even if you patch the DVMT settings (fbmem + stolenmem) through properties injection.
     
    With DVMT set to 64MB or 96MB (BIOS mod through Grubshell, see our FAQ topic on the matter or my E7270 guide), I can get 4K @24-30Hz out of HDMI and 4K@60Hz out of mDP on my Skylake/HD520 E7270 laptop. Can't see why it'd be different on your 7480, unless it's the TB port that's causing the issue under macOS of course.
     
    Don't hesitate to post a zipped copy of your bootloader's EFI folder so that we can check your settings.
     
    Do post your system's specs in signature since they're are 6th gen and 7th gen 7480...
  12. Hervé's post in 7490: issues with sleep, power-off and wifi in Big Sur and Monterey was marked as the answer   
    I don't think it'd have any influence on Sleep/Wake but it certainly could on a boot time perspective but Samsung 970 Evo Plus was not natively supported unless firmware was updated; can't say which version but it'd be worth checking whether you run on the latest version or not:
    https://semiconductor.samsung.com/consumer-storage/support/tools/
  13. Hervé's post in [Solved] E5470: OC config check was marked as the answer   
    Is there any particular reason why, as suggested by PM, you won't uncomment the properties injection for the DW1820A? Without this injection, you're highly likely to encounter system reset or plain freeze at startup.

  14. Hervé's post in Dell XPS 7390: High CPU usage/horrible battery life was marked as the answer   
    I looked at the patch you took inspiration from and can only make the following comments:
    it's something dating back to 2016 it's something that applied to an Asrock Skylake desktop motherboard I'm not entirely convinced that the patch that consists of simply removing the entire method _L6F is fully applicable to your Dell Comet Lake laptop but Ok if you've established your high CPU utilisation derived from the same problem of having kernel_task process running at 100% CPU load of course. Did you see a similar ACPI _L6F related error message in your boot log? I really must ask what makes you so sure about your statement  re: bugged UEFI firmware...
     
    Anyway, as a simpler alternative to DSDT patching, I would suggest that, in you Bootloader config, you simply rename method _L6F to XL6F (or _L6X) through the following ACPI patch/renaming:
    Find (Hex): 5F4C364600 Replace (Hex): 584C364600 (or 5F4C365800) because _Lxx methods are for interrupts xx (in hex).
     
    The only way you could remove method _L6F from ACPI through an SSDT would be to replace the entire _GPE scope that contained the method by a new one that would not contain it. It's feasible of course but really complicated (several instances of Scope (_GPE) in your DSDT, need to rename all methods and/or variables the scopes contain, etc.) when you may simply isolate/void method _L6F through the above renaming. Of course, you could also consider renaming _L6F to, say, XXXX to be more radical:
    Find (Hex): 5F4C364600 Replace (Hex): 5858585800  
    Failing that, just use a patched DSDT where method _L6F has been removed.
  15. Hervé's post in Dell E7280: 99% working! was marked as the answer   
    I'm not certain you need to change pipe value or inject flags for your iGPU connectors. Injecting/faking the iGPU's own device id is, of course, of no use. I also believe injecting enable-hdmi20 to be inapplicable on platforms that only support HDMI 1.4...

     
    All I do on my Skylake i7-6600U/HD520 E7270 is inject HDMI type (00080000) to con1 and use boot arg igfxonln=1. I have adjusted DVMT pre-allocated memory through Grub shell-based BIOS data mod. Try that and see if these settings makes a difference. I detailed my observed behaviour with HDMI in my E7270 guides.
     
    I believe all you need to inject is:
    AAPL,ig-platform-id 00001619 DATA AAPL,slot-name Built-in STRING framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA -> not needed if you change DVMT pre-alloc mem to 96MB through Grubshell framebuffer-stolenmem 00003001 DATA -> not needed if you change DVMT pre-alloc mem to 96MB through Grubshell framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA  
  16. Hervé's post in Latitude E7440: graphics problem after OC update was marked as the answer   
    Of course, you need to adjust your config; that's the little pleasures every month with every new OC version.
    https://www.insanelymac.com/forum/topic/349151-how-to-opencore-073-074-differences/
    https://www.insanelymac.com/forum/topic/349485-how-to-opencore-074-075-differences/
  17. Hervé's post in Latitude E7440: graphics problem after OC update was marked as the answer   
    Of course, you need to adjust your config; that's the little pleasures every month with every new OC version.
    https://www.insanelymac.com/forum/topic/349151-how-to-opencore-073-074-differences/
    https://www.insanelymac.com/forum/topic/349485-how-to-opencore-074-075-differences/
  18. Hervé's post in [Solved] Optiplex 3050 Sound issue was marked as the answer   
    Your IOReg shows next to nothing under device HDEF so, indeed you have no audio enabled. Assuming there's nothing in BIOS to block this, you should consider implementing the HPET IRQ patch. That should fix your audio issues.
    https://dortania.github.io/Getting-Started-With-ACPI/ssdt-methods/ssdt-easy.html#so-what-can-t-ssdttime-do
     
    Did you fix your config conflicts regarding codec layout id? Because the config you posted in port #1 showed:
    codec layout 11 being injected in Device Properties codec layout 3 being injected through NVRAM boot arg
     
    You need to decide on one method or the other, not both and opt for the correct layout of course!
  19. Hervé's post in [Solved] E5470: USB3.0 ports was marked as the answer   
    I'm pretty confident your issue derives from using that single unified SSDT which I believe to be incomplete. I would advise you gradually get rid of this SSDT and return to a more standard set of patched SSDTs. You'll then avoid such issues as that you currently encounter.
     
    When it comes to USB ports power settings, your single SSDT contains the following code and nothing else:
            Device (USBX)         {  [...] Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method             {                 [...] Return (Package (0x08)                 {                     "kUSBSleepPowerSupply",                      0x13EC,                      "kUSBSleepPortCurrentLimit",                      0x0834,                      "kUSBWakePowerSupply",                      0x13EC,                      "kUSBWakePortCurrentLimit",                      0x0834                 })             }  
    E5470 is Skylake, right? On my Skylake E7270, I also inject the attached standard XHC/USB3.0 patched SSDT which defines the following power settings:
                    "AAPL,current-available",                  0x0834,                                          "AAPL,current-extra",                  0x0898,                                          "AAPL,current-extra-in-sleep",                  0x0640,                                          "AAPL,max-port-current-in-sleep",                  0x0834                         
    Try and add that XHC patched SSDT to your setup.
    SSDT_XHC.aml.zip
  20. Hervé's post in [Solved] HP 430 G3: no HDMI audio was marked as the answer   
    All off-topic posts deleted. Guys, I remind that this topic is about HDMI audio...
     
    Looking at the zipped EFI provided above, I can se that the OC config lacks the required, yet well-known, properties injection for HDMI audio: that of the HDMI connector type for the relevant iGPU connector/port (usually con1).
    framebuffer-con1-enable       1        NUMBER framebuffer-con1-type         00080000 DATA If audio is working from the onset, the above will enable HDMI audio. Of course, the exact connector used by HDMI output needs to be verified and adjusted as required (con2, con3).
     
    See the Whatevergreen user manual for details.
  21. Hervé's post in [Solved] E7270: OCS: No schema errors & OC: No vault provided error was marked as the answer   
    Nope, what you get/see is perfectly normal. Mainstream multi-core CPUs have always been reported as single CPUs with n cores, something that totally reflects the hardware. Here's my own i7-based E7270 SysInfo:

     
    In no way does "dual-core/4 threads CPU" mean 2 x processors and 4 cores; you misunderstood things.
  22. Hervé's post in [Solved] E6220: Brightness toggle via Fn keys (UP & DOWN) was marked as the answer   
    Look up my recent Mojave and Catalina updates in my E6220 guide. They offer an installation free of patched DSDT, in UEFI mode and the posted pack contains all the SSDT tables + ACPI renamings in the Clover config to cater for brightness keys. You'll find the necessary code for Fn-UP/Fn-DOWN operation in the SSDT-Q66 table.
  23. Hervé's post in Unable to Update mac os big sur on Dell Latitude E6530 was marked as the answer   
    Updates are not offered when running macOS with the -no_compat_check boot arg. There are 2 x pre-requisites for obtaining Big Sur update offers:
    the SMBIOS of a Mac model compatible/supported by Big Sur (MBP11,x minimum). a SIP value that does not enable Apple Internal; it's disabled by default and must be kept disabled (bit #5 of SIP value, see here for details).
  24. Hervé's post in [Solved] Help with HD 4000 on Big Sur was marked as the answer   
    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
  25. Hervé's post in [Solved] Latitude 7400: no success with OpenCore was marked as the answer   
    You appear to have a Micron 2200s SSD in that Latitude 7400. Those are known to be troublesome with macOS and you should consider replacing it.
    https://dortania.github.io/Anti-Hackintosh-Buyers-Guide/Storage.html
×
×
  • Create New...