Jump to content

Driftwood

Members
 View Profile  See their activity

  • Posts

    466

  • Joined

  • Last visited

  • Days Won

    5

 Content Type 

Posts posted by Driftwood

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted · Edited by Driftwood

    SOLVED: Asrock TRX40 Radeon with 6950XT GPU + CorpNewt's bridge masking + fake bridge injection ssdt

    This is not normally a straightforward spoof for TRX40 users wanting to attach a Radeon 6950XT card to their Mackintosh system. However, legendary SSDTTime creator (amongst other apps), CorpNewt over from Discord AMDOSX server together with the main man here @fabiosun managed to get the board working with it. The fix? A special SSSDT-Bridge involving a zero'ing the D0A7 board and rewriting it, masking out injecting a new bridge that the DeviceProperties (kindly provided by fabiosun) can attach to. And it works beautifully with full Metal operation and acceleration 🙂 Its spoofed to the 6800XT but obviously will run faster as to the faster chipset.

    So here is the config.plist and SSDT -bridge he provided for all our TRX40  + 6950XT users still out there - there's life in the 3970x Threadripper yet! . Give it a go and let me know / or let fabiosun know how you get on 🙂
    The config works with Sonoma latest AND sequoia latest together with the latest version of OC.

    CorpNewt's explanation:
    image.thumb.png.f5c315e533f962d07ab84d31a292479b.pngimage.thumb.png.81c0f1f3b8001af2ad89127a6c88b8a2.png
    image.png.25f6081b070b69d55106a8752882bb63.pngimage.thumb.png.41e48cd8e5689f1a846e2a2d4c60b87e.png

    Files:

     

    SSDT_FOR RADEON 6950XT_ANDCONFIG_SETTINGSBRIDGE.zip

    • Like 1
    • Thanks 1

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted · Edited by Driftwood

    Here’s a table showing recommended Secure Boot model + SIP (csr-active-config) combos for TRX40 AMD on Sonoma, Sequoia, and Tahoe — along with why each combo works best for stability and patch compatibility.

    See Excel  xls Table attached.

      Recommended Secure Boot model SIP.jpg

     

    Why not full SIP disable?

    • Setting csr-active-config to FF0F0000 (full SIP off) will allow anything, but:

      • Breaks some macOS security preference panes.

      • Can trigger security audits in some DRM apps.

      • Not needed for standard AMD kernel patches.

    Why not keep Secure Boot enabled in Tahoe?

    • Tahoe’s new boot policy re-verifies some kernel signatures even after OpenCore patch injection.

    • With SecureBootModel set to a real Mac, these checks can fail mid-boot on AMD and cause kernel panics or “Unable to verify kernel” messages.

    • Disabling it bypasses that policy, making installs/upgrades smoother on TRX40.


     

    SecureBoot_TRX40_Sonoma_Sequoia_Tahoe.xlsx.zip

     

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted · Edited by Driftwood

    Boot Sequoia (Darwin 24) and Tahoe (Darwin 25) without changing EFICombo TRX40 Patch set - Sequoia (Darwin 24) and Tahoe (Darwin 25) Patches to paste into your config.plist.zip

    Tahoe TRX40 INSTALL - Pitfalls Checklist

    1. Kernel & ACPI Compatibility

    • Patches must be Darwin 25–aware — Sequoia-only EFI won’t boot without extending MaxKernel to 25.99.99.

    • Watch for ACPI quirks:

      • Some TRX40 boards drop _CRS IRQ routing differently in newer macOS; keep SSDT-EC-USBX and SSDT-PLUG up-to-date.

      • Ensure SSDT-CPUR or SSDT-CPUR-ZEN matches your CPU topology (especially if you edited _SB.PR00).

    • Keep Kernel → Quirks → ProvideCurrentCpuInfo enabled — Tahoe’s CPUID checks are slightly stricter.

    2. PCI & IOPCIFamily Changes

    • Tahoe has a rewritten PCI enumeration path:

      • The Disable 10-bit tags patch is still needed.

      • Don’t enable IOPCIIsHotplugPort AM5 patch — TRX40 doesn’t like it.

    • If devices vanish after boot (especially NVMe on chipset lanes), double-check:

      • Above4GDecoding enabled in BIOS.

      • Resize BAR disabled.

    3. GPU Drivers

    • AMD Navi / RDNA2 GPUs:

      • Works if already working in Sequoia.

      • Check that agdpmod=pikera boot-arg is still set if you’re bypassing board-ID checks.

    • RDNA3 (RX 7xxx):

      • Still experimental; some kext names changed in Tahoe — might require spoofing Device ID.

    4. Audio (RME / PCIe Cards)

    • If Fireface works in Sequoia, it should work in Tahoe — but:

      • Gatekeeper reset in upgrade will block unsigned RME extensions until re-authorized.

      • After install, run: 

        Terminal bash
        sudo spctl --master-disable
        sudo kextcache -i /

      • Then re-plug your device.

    5. Networking

    • Intel i210/i225 NICs:

      • Update IntelMausi or LucyRTL8125Ethernet to the latest before upgrade.

    • If using Aquantia AQC107:

      • The Apple driver (AppleEthernetAquantiaAqtion) in Tahoe is fussier about PCI config space; may require device property injection.

    6. Sleep / Wake

    • Tahoe tightens non-monotonic time checks again.

      • Both Visual time patches must extend to Darwin 25 or you’ll kernel panic on wake.

    • Disable Power Nap in System Settings; TRX40 firmware doesn’t play nice with it.

    7. Security Changes

    • amfi_get_out_of_my_way=1 is even more necessary for unsigned kexts in Tahoe.

    • Some OC users needed csr-active-config set to 03080000 for post-install patches to load without SIP interference.

    8. Installer Quirks

    • When installing from USB:

      • Use Kernel → Quirks → DisableIoMapper = YES for first boot stage (workaround for TRX40 IOMMU mapping issue).

      • Re-enable after install if you need VT-d for virtual machines.

    • Avoid hot-plugging USB during install — Tahoe is fussier about re-enumeration.

    If you get stuck in the second boot stage (Apple logo ~50% then reboot), it’s almost always:

    1. Missing or mis-ranged CPUID patch for Darwin 25.

    2. PAT patch not applied for 15+ kernel.

    3. GenuineIntel bypass missing.

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted · Edited by Driftwood

    TRX40 - Installing Sequoia Watchouts:
     

    1. Boot Hangs or Kernel Panics Before Installer

    • Cause: Missing or mis-scoped new leaf 7 allowance patch for Darwin 24.x.

    • Without it, _cpuid_set_generic_info blocks CPUID leaf 7 and early kernel init fails.

    • Fix: Ensure the MinKernel=24.0.0 leaf 7 patch is present and enabled (we did this in your Sequoia/Tahoe array).

    2. PAT (Page Attribute Table) Changes

    • Cause: Apple tweaked PAT handling in Sequoia → breaks older Ventura/Sonoma PAT patches.

    • Symptom: Black screen after the Apple logo, or login window never appears.

    • Fix: Use only the Algrey/Zormeister 15+ PAT variant. The Shaneee version can still work but tends to cause subtle GPU framebuffer quirks on TRX40.

    3. Non-Monotonic Time Panics

    • Cause: The scheduler trips over AMD’s TSC drift.

    • Symptom: Panic messages mentioning non-monotonic or Quantum::invoke.

    • Fix: Keep both “Visual” time patches covering 24.0.0–24.99.99. Without them, uptime-related panics are common after sleep or heavy load.

    4. PCI Enumeration Oddities

    • Cause: Newer IOPCIFamily builds in Sequoia can misread certain Threadripper bridges.

    • Symptom: NVMe or certain USB controllers missing, or devices showing in System Profiler but not functioning.

    • Fix: Keep “Disable 10-bit tags” patch active; avoid AM5-specific PCI patches, which can hang TRX40 entirely.

    5. Aquantia 10GbE Driver Allocations

    • Cause: Slight API change in AppleEthernetAquantiaAqtion in 24.x.

    • Symptom: Network interface exists but won’t get DHCP / stalls under load.

    • Fix: The alloc_dma_buffer and withOptions patches still work — keep them extended to 24.x.

    6. Core Count Hardcoding

    • Cause: Darwin 24+ scheduler changes can misdetect AMD core counts above 16 without patches.

    • Symptom: System boots but shows wrong core/thread count; performance tanks.

    • Fix: Use the 13.3+ cpuid_cores_per_package patch with 0x20 for 3970X.

    7. Quirks and Kext Expectations

    • Lilu & WhateverGreen need to be latest — older ones break in Sequoia with certain AMD GPUs.

    • ProvideCurrentCpuInfo must be enabled or CPU info patching won’t apply.

    • DisableIoMapper is still needed if VT-d is off in BIOS — but if you enable IOMMU + AMD patches, some TRX40 boards crash at boot.


     

    Sequoia Survival Checklist tailored for TRX40 + Threadripper on AMD Hackintosh, so you can pre-flight your EFI before booting Darwin 24.x.

    EFI / OpenCore Settings

    1. OpenCore Version

      • Use latest release or debug build (as of now, OC 1.0.3+ recommended for Sequoia).

      • Older OC builds don’t handle Sequoia’s new kext linking behavior.

    2. NVRAM Reset

      • Always Reset NVRAM after changing patches, kexts, or upgrading macOS.

      • Prevents stale CPU data or boot-arg conflicts.

    3. Kernel → Quirks

      • ProvideCurrentCpuInfo = true

      • DisableIoMapper = true (unless you’ve verified working IOMMU on TRX40)

      • CustomSMBIOSGuid = true

      • PanicNoKextDump = true

      • AppleCpuPmCfgLock = true (avoid CPU power mgmt panic on some BIOS)

      • AppleXcpmExtraMsrs = true

      • CustomCPUID = only if running extra vendor masking (most don’t need)

    4. Boot Args

      • Always keep:

        keepsyms=1 debug=0x100 alcid=1

        Add npci=0x2000 only if PCI enumeration hangs — remove if boot OK.

    Kext Requirements

    1. Always Latest:

      • Lilu

      • VirtualSMC

      • WhateverGreen

      • AppleALC

      • NVMeFix

      • SMCAMDProcessor (latest build for Sequoia, not older Ventura/Sonoma one)

    2. Networking

      • Aquantia: latest AquantiaAqtion.kext with Sequoia support.

      • Intel: latest IntelMausi.

    3. USB Mapping

      • Must be done with custom SSDT or USBMap.kext — Sequoia breaks some XHCI defaults.

    Kernel Patches

    1. CPUID Core Count (13.3+)

      • MinKernel=22.4.0 MaxKernel=25.99.99 → 0x20 for 3970X.

    2. Leaf 7 Allowance (Sequoia)

      • MinKernel=24.0.0 MaxKernel=25.99.99

    3. PAT Fix (15+)

      • Use Algrey/Zormeister 15+ only.

      • Shaneee 15+ is optional but not recommended for TRX40.

    4. Non-Monotonic Time Fixes (Visual)

      • Two standard patches for Darwin 21–25.

    5. PCI Fix

      • Disable 10-bit tags patch.

      • Do not enable AM5 PCI hotplug fix.

    6. GenuineIntel Bypass

      • Goldfish64/algrey patch MinKernel=21.0.0–25.99.99.

    BIOS Settings (TRX40)

    1. Disable:

      • CSM

      • Secure Boot

      • Serial Port

      • Above 4G decoding (enable only if needed for GPUs with >4GB VRAM and your EFI supports it)

    2. Enable:

      • XMP / DOCP for RAM

      • SVM (if running virtual machines)

      • HPET (High Precision Event Timer)

    Before Booting Sequoia

    • Test EFI first on Sonoma (Darwin 23) to confirm baseline stability.

    • Update all kexts to the latest release from July 2025 or newer.

    • Keep USB keyboard connected — wireless HID devices can fail during installer prelinkedkernel load.

    [Guide]VirtualBox on Sonoma and AMD Hackintosh

    in Guide

    Posted · Edited by Driftwood

    @tomnic As I'm currently using Sonoma 14.2 (23C64) apparently there was a cursor / pointing device bug with this version of the OS from what I was reading somewhere and I think its not been helping the vbox guests with sluggish 'forgetful' performance. Whats the latest version of Sonoma (14.4.1) been like with pointer control in VBox guests?

    [Guide]VirtualBox on Sonoma and AMD Hackintosh

    in Guide

    Posted

    3 hours ago, tomnic said:

     

    Thanks for your appreciation on my guide, probably resetting the nvram parameters recreates the kext blacklist, I'm on 6.1.48 right now and I'll try with 6.1.50.

    Yes the new AMFIPass doesn't require the specific bootflag, I'll update the guide.

    @tomnic Ive updated the above to see if you spot any additions I need!

    [Guide]VirtualBox on Sonoma and AMD Hackintosh

    in Guide

    Posted · Edited by Driftwood
    forgot a few points

    On 11/13/2023 at 11:06 AM, tomnic said:

    But how can we get Virtualbox running on recent macOS? The prerequisite is to disable SIP and use the AMFIpass.kext with the bootflag -amfipassbeta in order to allow VirtualBox kexts to be loaded once installed, nothing more. In fact, once rebooted and allowed the kexts to run in Security section you can even disable the loading of AMFIpass.kext and remove the related bootflag, by now the kexts have bypassed the blacklist, forever!
     
    After that you can also install Windows 11 as a VM, direct without any issue, and the performance is also great if you don't overdo the number of cores (my maximum is 2 then it starts to slow down)!!!

    Hi Tomnic,

    Nice guide.

     

    Ive tried this with 6.1.50 and everything working installing Win 10 guest into the Box Host on Sonoma(in the process installing Win 32bit apps I needed  etc...)  but on reboot and resetting NVRAM SIP to 0000000 & removing the AMFIPass kext in config.plist its back to the kernel error cant load. Any info on this?

    BTW I used AMFIPass v1.40 and didn't require the bootflag -amfipassbeta

     

    amfipasskextandnvramconfigplistsettings.thumb.jpg.7ecfedc63cceb0f723583fe2d5b25be1.jpg

     

    METHODOLOGY

     

    1. In config.plist (see image) inside your boot EFI, Add the numbers csr-active-config = 03080000 (see image)  into the NVRAM section of config.plist (to workaround security & Privacy Oracle Box kext sign problems with this partial SIP disable).

    2.  Add AMFIPass.kext details (see image) into kernel section of config.plist.  Save config.plist back to the EFI /OC folder.

    3. Download version 1.40 of AMFIPass.kext and copy it over onto your EFI drive's Kext folder.

    4. Ensure you can reset NVRAM in Opencore when rebooting

    5. Reboot, and hit space, number to reset your NVRAM.
    6. Now it should boot with your SIP disabled and use AMFIpass to allow the box kernel thru.

    7. Download & install Vbox v.6.1.48 or 6.1.50

    8. During the installation process it should ask you to sign / allow the Oracle Virtual Box / ALLOW it inside your 'System Settings' Security & privacy section.

    9. After install and the kernel of box has been signed it will ask to reboot. Go ahead and reboot.
    10. After reboot, locate and download/install Oracle_VM_VirtualBox_Extension_Pack-6.1.50.vbox-extpack (if using ver 6.1.50)

    11. Now grab a ISO from Microsoft and install your guest OS - in my case it was Windows 10 32 bit iso

    12. Go thru the motions of installing the guest OS like you normally would.

    13. Locate and download VBoxGuestAdditions_6.1.50.iso or VBoxGuestAdditions_6.1.48.iso and install them from a guest ISO storage drive.This will provide a number of addition hardware features and functionality.

    14. Finally, fine tune your guest OS for display USB pointing devices etc...

    15. If you get problems running virtual box - quit Vbox completely (stop any guest VMs running first if you can) and then rerun it by running it from within Applications folder and not as an alias as sometimes aliases get corrupted or lose sight of the software.

    16 I tried then resetting SIP to Enabled and disabling AMFIPass kext inside config plist Kernel section, reboot, resetting NVRAM and booting up to Sonoma but the Kernel errors reappeared and I found they were no longer 'Allowed' by the OS. Subsequently, virtual box guest VM's failed to start. 😞

    17. So went back to partially Disabling SIP (csr-active-config = 03080000) but didn't require AMFIPass to ON now that Ive installed vBox.

     

    More on this soon...

     

    useful links:

    Virtual Box Old Builds: https://www.virtualbox.org/wiki/Download_Old_Builds_6_1

    and https://download.virtualbox.org/virtualbox/6.1.50/ to find the Guest Additions etc...

    AMFIPass kext: https://community.macmeup.com/index.php?/files/category/3-kexts/. or payloads/Kexts/Acidanthera/AMFIPass-v1.4.0-RELEASE.zip

     

    Win10inSonoma.thumb.jpg.ec06d57dea81c3c7fd96f2112c7f092c.jpg

    • Like 1
    • Thanks 1

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted

    On 10/14/2023 at 1:20 PM, fabiosun said:

    I think so

    but I think price will be monster

    and I would like to have a platform with the change to upgrade also the cpu without changing the motherboard

    trx40 missed that part 

    we will see

    the future seems more interesting than recent past🥹

    And you're not tempted by the Intel Core i9-14900K? 😉

     

    [Discussion] - TRX40 Bare Metal - Vanilla Patches

    in General

    Posted · Edited by Driftwood

    10 hours ago, Jaidy said:

    Was this problem ever solved? I just populated all of the m.2 ports on my machine, and occasionally it won’t boot, or boot to black screen, or restart midway. Though once it gets to desktop, things are solid. 
     

    also I added a second GPU (7900XTX)..

    You should check resources - PCIE which ones are directly connected to CPU and which are to chipset. All devices inc USB devices are taking up resources. DO a count and subtract from the total available for your motherboard. Maybe take out a device - a drive, a GPU etc... (experiment) until you see a happy compromise.

    For example, The ASROCK TRX40 Creator features 88 PCIE lanes, 72 of which are useable to the end user. The Threadripper AMD CPUs utilise 56/64 PCIe 4.0 lanes.

     

    Chipset vs. processor allocated PCIe lanes

    The PCIe lanes on a motherboard originate either from the processor itself or the motherboard chipset.

    Generally, the processor lanes are reserved exclusively for the graphics card x16 slots and M.2 slots for high-speed SSDs, as they require to move data without being bottlenecked by the chipset.

    On the other hand, chipset lanes connect to onboard USB, other M.2 and PCIe slots, and SATA. The chipset itself transfers data to the processor via a dedicated 4-lane PCIe bus.

    So, all devices connected via PCIe lanes to the chipset will have a cap on their maximum bandwidth leading to bottlenecks


    Don't forget to run MMIO Opencore checks as u go.

     

     

    • Thanks 1
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.