Jump to content

Hervé

Administrators
  • Posts

    10047
  • Joined

  • Last visited

  • Days Won

    566

Posts posted by Hervé

  1. You post in the Latitude E5xxx Series; pease specify your laptop model. Haswell-based E5x40 I presume. Please post a zipped copy of your bootloader's config and, if possible, an IOReg extract + SysProfiler extract. Very little we can do without minium information and, in all likelihood, you have some incorrect settings.

    • Like 1
  2. 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.

  3. Re: sleep, follow the steps detailed in our FAQ topic on the matter. Basically cancel hibernation and revert to plain old sleep with deletion of the sleepimage file.

     

    I'm reviewing your setup and I can already see some stuff needing to be changed. For instance:

    1) you patch fbmem which is wrong; no need for such patch on Ivy Bridge HD4000 so make sure to remove that property:

    framebuffer-stolenmem        00000004        DATA

    2) never seen the need for SSDT-EC-USBX on an Ivy Bridge laptop; afaik, this is for Skylake and later platforms.

    3) not sure you need the SSDT-GPRW either.

    4) renaming device EC to ECDV normally suffices, I don't thing you need the SSDT-EC-LAPTOP table.

    5) don't think you need those PICI and TIMR ACPI patches that I see in your config; need to check the HPET and RTC ones as they look a little unusual to me for the platform.

  4. TX/RX rates depend entirely on antennas and physical environments, not the OS. Your screenshots clearly show that both systems hook on your wireless network with identical specs: channel 40 (5GHz, 80MHz). Whilst you may not obtain 100% identical results between the 2 computers, you should nevertheless expect to obtain very similar results if both machines are sitting at roughly the same place. Afterwards, it depends on the antenna's characteristics and quality.

     

    5GHz wireless networks are heavily sensitive to distance and signal reduction due to walls and other environmental elements. Hence why you should only compare TX/RX rates if computers stand at the same physical place. One other thing to note -as observed and detailed here- is that using AirportBrcmFixup can affect TX/RX rates. Make sure you use identical configurations on your 2 computers when you make your comparisons.

  5. IOReg is unlikely to be of any use for that shutdown problem; a zipped copy of the bootloader's EFI you're using would be much more useful...

     

    As far as running Ventura on those unsupported platforms is concerned, you should:

    1. re-use what you had under Big Sur/Monterey (assuming everything worked Ok under macOS 11/12, including shutdown)
    2. update all your add-on kexts to latest versions (especially Lilu & PlugIns)
    3. use the SMBIOS of a MBP model supported under Ventura (eg: MBP14,1) for initial installation (and OTA updates)
    4. revert to Haswell SMBIOS and boot with -no_compat_check boot arg post-install
    5. apply OCLP root patching (use OCLP v0.6.1 minimum) after booting with Haswell settings for the 1st time

    and that's it. Has worked perfectly for my Ivy Bridge E6230, so it should too on your Haswell E5440. I'd say your shutdown issues are related to some patched ACPI tables or ACPI patches you use.

  6. Probably far too many inappropriate kexts present. I'd start with a basic set and remove all of the following kexts, adding stuff gradually as/if required:

    • CPUFriend + CPUFriendDataProvider (did you actually tune these for your specific CPU/SMBIOS model? If you didn't, there not suitable)
    • FakePCIID_XXXX (can't seen why you'd need such deprecated kexts on a Whiskey Lake laptop)
    • USBInjectAll (clashes with USBPorts assuming latter is the result of an adequate USB port mapping on the computer)
    • HibernationFixup
    • RTCMemoryFixup
    • IOElectrify (if you need to tune TB ports, I'd do it once everything else works perfectly Ok)
    • Thunderbolt3Unblocker (same, keep that to post-install if it's at all required)
    • UVC2FaceTimeHD (can't see why you'd need that but, here too, keep that for post-install if it's at all required)
    • Airportitlwm (keep that to post-install and make sure to follow the specific guidance posted for Monterey at the ITLWM site)

     

    For the other kexts you keep, make sure to update them to latest version, especially Lilu & associated PlugIns because you're running on older versions right now...

     

    As for the ACPI patched tables, I can only recommend you follow the guidance posted at Dortania, that's quite an extensive set of SSDT tables you got there.

     

    Finally, you only posted CPU+iGPU and SSD specs; I'd strongly recommend you identify the rest of your hardware in order to asses what you need (LAN, Wifi, Bluetooth, audio codec, card reader, etc., etc.).

  7. -> Thread moved to relevant hardware support section; this is not a thread about hardware information. Please make every effort to post in the appropriate forum sections and to use punctuation, not just post in a single extended sequence of words! This is totally unreadable and such posts/threads be deleted without prior notice in the event of re-occurence.

     

    Assuming you've followed all the necessary recommendations posted at ITLWM, you can always try and re-apply the Windows driver for the card in the hope that it'll reload the firmware onto the card if that's what's gone sideways.

     

    But you may have to consider that the card is either suffering from a bad connection (try and clean the cards connector and the slot) or simply got defective (it happens). Check if the Bluetooth module is seen or not in SysInfo->Hardware->USB. If it's not, as per in Windows, you have a hardware-related issue. it's probably not the case but do check that Bluetooth did not get somehow disabled in BIOS settings.

  8. No such thing as a Latitude "E7480", there are only Latitude 7x80. Renaming thread and adjusting contents + moving thread to the Latitude 7000 Series section.

     

    Grab the PS2/I2C kexts from EFI folders posted in existing Latitude 7280/7480 threads and adjust your bootloader's config accordingly.

  9. You should delete the sleepimage file in /var/vm -it often leads to trouble at wake- and ensure Power Management settings point to null device for the hibernate file. Basically, I suggest you follow the recommendations posted in our FAQ topic.

     

    MBP7,1 should be the ideal target SMBIOS site you have a Penny C2D platform but if you feel your laptop works better with a different one, then use whatever suits you.

     

    Re: USB ports, sounds like you need to do or redo the mappings when you switch SMBIOS. Also remember that:

    • OHCI = USB1.x
    • UHCI = USB1.x
    • EHCI = USB2.0
    • XHCI = USB3.x

    With Big Sur, Apple started to drop some older USB technologies so Big Sur and later versions require what is called the USB HID fix to circumvent the USB-related issue. This is mostly applicable to older systems like C2D/C2Q platforms but I found it also applicable to more recent platforms like, say, Skylake when fitted with hardware accessories based on  older USB technology (eg: touchscreens).

     

    You've made no mention of it but I can only assume you use the OCLP app to patch your unsupported platform; latest versions are supposed to somehow address the USB1.1 issues but I've not read about it yet so I don't know how applicable this may be for your old laptop.

  10. Thanks for posting the specs; a very old laptop indeed. You should be using SMBIOS of MacBookPro7,1 rather than MBP6,2 which was a 1st gen Arrandale platform.

    Also note that OpenCore does not properly care for CPU power management of pre-SandyBridge systems. As such you may want to consider switching to Clover (r5150 or later for instance).

     

    Re: wake issue, did you disable hibernation? It's enabled by default and certainly needed to be disabled on most platforms in the past and still today. You may lookup our dedicated thread on the matter in our FAQ section.

    Re: DSDT, don't hesitate to list the various patches you applied/implemented; this is not something we'll be able to guess.

     

    One final comment about your OC config and the graphics properties you inject, I'm not sure you got that right. The IO location you specified looks erroneous to me; but it sure does not prevent you to gain graphics acceleration according to your IOReg. For your info, your nVidia dGPU is PCI0.PVGA.GFX0 so the correct device location is "PciRoot (0x0)/Pci(0x1, 0x0)/Pci(0x0,0x0)".

    HP_DV7_GFX0_IOReg.jpg

     

    You should therefore adjust your config to remove what I believe to be a typo of some sort in your config:

    nVidia_dGPU_location.jpg

  11. According to kronokernel, patch for BCM43224 still works in Monterey (or, at least, it did in the summer of 2021 and Monterey beta days):

    https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/post-30034783

    https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/post-30038647

     

    I've not looked at what the OCLP solution does in that respect but, assuming it breaks the seal and somehow copies the necessary kext in /L/E or /S/L/E for caching, then the on-the-fly patch (in the bootloader's config file) would work. You'd have to target MacBookAir5,2 or MacBook7,1 for OCLP to install the necessary kext and patch macOS accordingly.

  12. It was mentioned on p1 but macOS OTA updates require that your booted system complies with a set of pre-requisites:

    1. SMBIOS of a fully supported Mac model (unsupported models will not attract updates)
    2. no -no_compat_check boot arg
    3. no Apple_Internal SIP flag enabled (5th bit of csr_active_config parameter). See our SIP-related FAQ topic for details

    These apply to systems using Clover. For systems using OpenCore, I vaguely remember that there's another pre-requisite around SecureBootModel or something of that essence; you'll have to look that up.

     

    You may therefore need to have 2 x configs at hand to be able to obtain and install Ventura updates on your unsupported platform: your current config and a specific "supported model" config (eg: MBP14,1 SMBIOS, no -no_compat_check, SIP=0xFEF) that you'll use exclusively for updates.

     

    Given that you're running Ventura on a Haswell Latitude E5440 with HD4400 graphics, you used OCLP patching to apply root patching and gain graphics acceleration. Make sure the option you selected/unselected in the tool do not prevent OTA updates. Check out the tool's documentation. On a real Mac, default parameter for the targeted system do support OTA updates, but that's real Mac...

×
×
  • Create New...