Solved SATA drives not detected on macOS Tahoe (AMD B550 chipset + ASMedia) | worked fine on Sequoia with same EFI

[rxtsel]

Edit: Now work for me. I use this resource for re configuring my efi:

GitHub - lzhoang2801/OpCore-Simplify: A tool designed to simplify the creation of OpenCore EFI

A tool designed to simplify the creation of OpenCore EFI - lzhoang2801/OpCore-Simplify

github.com

(Disclosure: I used Claude to help investigate this and draft this post — English isn't my first language and the AI helped with the technical write-up. One claim in an earlier draft was already flagged as wrong and corrected below; please call out anything else that looks off.)

​

Hardware​

• Motherboard: MSI PRO B550-VC
• CPU: AMD Ryzen 7 5800X
• GPU: AMD Radeon RX 6600 (Navi 23)
• Storage: 2x ADATA SU650 2.5" SATA SSD
• OpenCore: 1.0.7
• SMBIOS: MacPro7,1

Problem​

Two SATA controllers on this board:

• PCI 1022:43EB — AMD B550 chipset SATA controller (motherboard SATA1-6)
• PCI 1B21:0612 — ASMedia ASM1061/1062 controller (motherboard SATA7-8)

Neither is detected by macOS Tahoe (currently on 26.5.2). Disk Utility / diskutil list show nothing SATA — only the USB installer. This is a regression: the exact same EFI (OpenCore 1.0.7, same kexts, no changes) boots macOS Sequoia fine and detects both SATA SSDs without any special kext. The problem only appears when booting the Tahoe installer.

What we ruled out (with evidence, not just "tried it")​

1. AMDSata.kext (aka SATA-unsupported.kext, also re-hosted as AlfCraft07/AMDSata)
IOClass = AppleIntelPchSeriesAHCI, IONameMatch includes pci1022,43eb. Loaded this alone (no other SATA kext) — no drives appeared, and on one earlier boot attempt it correlated with a hard hang after AppleAHCI::start in verbose (no panic, no log — see below). Correction from an earlier draft: I incorrectly claimed this IOClass was removed since Big Sur — I was told that's wrong, so scratch that explanation (didn't re-verify myself, taking the correction at face value). Point 3 below is a cleaner test anyway since it doesn't depend on this class at all.

2. CtlnaAHCIPort.kext (both HeaDragon's original and Dortania's hosted copy in OpenCore-Install-Guide/extra-files/)
Downloaded and disassembled the actual binary's IOKitPersonalities. It contains only Intel PCH device IDs (pci8086,... — 10 personalities, all Intel 5-Series through 200-Series). Zero AMD (1022) or ASMedia (1b21) entries. This kext is commonly recommended across guides as "the Big Sur+ fix for third-party SATA" but it is Intel-only and cannot help AMD/ASMedia hardware at all.
3. Ryzen-CtlnaAHCIPort.kext (a fork of HeaDragon's CtlnaAHCIPort, got it from a Discord server, not sure of original source)
This one's actually well-built: same compiled CtlnaIntelPchSeriesAHCI binary as HeaDragon's original (156976 bytes, identical SourceVersion), with an added AMDRyzenSATA personality carrying IONameMatch: ['pci1022,7901', 'pci1022,43eb'] pointed at that real, compiled class. This is not a dead/codeless injector — correct PCI ID, real driver code. Tested alone: same result as everything else — no disks in Disk Utility, no hang, no dmesg output. This is the strongest evidence so far that this isn't a "wrong kext" problem.

4. BIOS SATA Hot Plug
Per-port Hot Plug was disabled for SATA1-6 (chipset). Enabled it — no change. SATA7-8 (ASMedia) doesn't expose a Hot Plug toggle in BIOS at all.

5. ACPI-level fixes

• Built an SSDT to disable (_STA=0) the AMD chipset SATA ACPI device (\_SB.PCI0.GPP1.PT01) to isolate/avoid a kernel hang we hit earlier when the SATA controller was touched (see below) — confirmed via acpidump/iasl decompile that this is the correct ACPI path for 02:00.1.
• Built an SSDT-Bridge.aml (via CorpNewt's SSDTTime) to declare the missing leaf PCI device for the ASMedia controller (\_SB.PCI0.GPP1.PT02.PT26, target path PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x2)/Pci(0x6,0x0)/Pci(0x0,0x0)).
• Neither changed the outcome for detection, though the SSDT hiding the AMD controller did stop an earlier kernel hang (see below).

Diagnostic evidence collected​

With AppleDebug/ApplePanic enabled and a DEBUG build of OpenCore:

• Before hiding the AMD chipset SATA controller via ACPI: boot would hang hard after AppleAHCI::start appears in verbose (no panic ever written to disk — genuine hang, not a crash. Confirmed no panic log ever generated across 5+ attempts).
• Blocking com.apple.driver.AppleAHCIPort entirely (Kernel -> Block) let the installer reach the GUI — confirming the AMD chipset controller was the source of the hang.
• After that, in the installer's Terminal:

  kextstat | grep -i ahci
  84  1  ...  com.apple.iokit.IOAHCIFamily
  85  0  ...  com.apple.driver.AppleAHCIPort

AppleAHCIPort loaded but 0 active clients — it never attached to either SATA controller (AMD chipset or ASMedia). dmesg | grep -iE "ahci|sata" returns nothing at all — not even a failed-match log line.

Question for the community​

Has anyone gotten SATA (not NVMe) drives working under Tahoe on an AMD B550/X570 FCH controller or an ASMedia SATA controller?

Given that a real, correctly-matched, compiled AHCI kext (Ryzen-CtlnaAHCIPort.kext, point 3 above) still ends up with 0 clients and zero dmesg output, I'm now wondering if this is less about which kext/IOClass and more about something Tahoe-wide blocking third-party AHCI/storage kexts from actually attaching (even when loaded and matched). Has anyone run into new kext-loading/entitlement restrictions in Tahoe specific to storage drivers? Happy to share the full EFI, logs, or test anything — and please do keep correcting anything else that looks off, I'd rather get called out than waste people's time chasing a bad lead.

 

[Edhawk]

How did using OpCore-Simplify fix your SATA issue?

Which patch, kext, SSDT or DeviceProperties were added to your OC setup to enable the AMD SATA controller?

 

[GameX]

I had the same problem. For about 2 weeks lol, and I was getting mad (trying to see if I could succeed on my own, for the last time, on Tahoe haha)

• Motherboard: MSI B550 Tomhawk
• CPU: AMD Ryzen 9 3950X
• GPU: AMD Radeon RX 5700 XT
• Storage: Samsung 860 EVO
• OpenCore: 1.0.8
• SMBIOS: MacPro7,1

I never knew how OP fixed it, tried OpCoreSimplify, which wouldn't boot (I have never used it in the past, I always did manually).

With the own EFI, the system would boot in the Tahoe installer, from the only USB 3.0 port that worked (JUST USB 3.0 in the motherboard was working, no USB 2.0, no front). I got "Still waiting for root device // Prohibited", but I still reached the installer everytime. No idea why. The installer never detected any SATA drive (I don't own NVME), despite trying AMDSata.kext, CtlnaAHCIPort.kext, the correct board ID (was already included in the Kext, did BIOS update...).

I also installed Tahoe on a mechanical HDD connected to USB 3.0 docking station,through a monitor USB (LOL). SLOW, but it actually installed. Naturally, no SATA, nor Ethernet, don't ask, they both worked under Sequoia.

Nothing worked until I mapped the USB port PROPERLY with USBMap from Sequoia. I believe I did it a few years back under Sequoia but it was under Windows with USBToolbox. And was it STILL done correctly for Sequoia, I don't know, so I did it from scratch with USBMap.

So yes, idk but the solution for me was simply USB mapping, which solved SATA AND Ethernet. Otherwise, I kept having the error "AHCIRoot Assert failed: implementedPorts !=0x..... Then I put the HDD at SATA instead of USB which booted instantly (of course). I'll clone to SSD.

Edhawk, what sorcery is this? (just curious anyway - how does USB mapping have anything to do with SATA and Ethernet? And why was the USB still booting DESPITE the "Still waiting for root device" ?

Cheers

 

[etorix]

Tahoe uses a different format of USB map than the previous versions, so yours was in need of an update.
No idea why USB mapping would affect SATA…

 

[GameX]

Correct, but I was mistaken too, I was using the OpCoreSimplify generated EFI this whole time !! (minus the USBMap. Without USBMap, no "still waiting for root device" but simply stuck)
...which is unsatisfying as I didnt do it exactly myself LOL (but still works heh?)
Given a little more time, I will try and find out. If I use this USBMap on my personal own EFI try and find the cause of this.

I will share my findings and final EFI hoping to come up with an answer.

 

[GameX]

This is not much to go on, but I wanted to follow-up with the answer.... the solution appears to be in Kernel Patches (I compared OpCoreSimplify and the generic Config.plist I made, with trial & error). Adding USBMap alone is not enough.

AMDRyzenCPUPowerManagement.kext
AppleALC.kext (not working ATM)
AppleMCEReporterDisabler.kext
Lilu.kext
LucyRTL8125Ethernet.kext
RealtekRTL8111.kext
RestrictEvents.kext
SMCAMDProcessor.kext
SMCRadeonSensors.kext
USBMap.kext
VirtualSMC.kext

USBMap and the Kernel Patches in this config.plist alone were necessary for SATA on B550 Tomahawk. But it seems, that my DATA drive SATA Port 2 is inconsistently showing up (on MY plist, not the OpCoreSimplify generated one, which works). One of the Kernel Patch allow SATA to works. I believe.

AMFIPass.kext (and the Bootarg!)
and CtlnaAHCIPort.kext (also cause the BD+DVD drive to not show up) generated by OpCoreSimplify do not appear to be necessary on B550 Tomahawk for the SATA drives to be found. Removing them had no ill effect.

Every works besides audio for now...

 

[Edhawk]

For audio to work in Tahoe you need to add AppleHDA.kext to the OS. Apple removed this audio kext from Tahoe, because none of the supported Apple Systems need this kext for audio. It is only required for Coffee Lake and older systems. Without this kext being added to the system AppleALC.kext has nothing to match against, so it doesn't work.

There are a number of fixes for this available on the Web. Some are specifically Intel based (RP-CORE), a few work with both Intel and AMD systems (MyKextsInstaller app).

GitHub - Mirone/MyKextInstaller: MyKextInstaller is a lightweight macOS utility designed to simplify the installation of kernel extensions (kexts).

MyKextInstaller is a lightweight macOS utility designed to simplify the installation of kernel extensions (kexts). - Mirone/MyKextInstaller

github.com

You usually have to install a matched version of the Kernel Debug Kit (KDK) as pairs with the version of Tahoe you are using, 26.6.1 being the latest release. Just check the OS build version before you download and install the KDK.

Releases · dortania/KdkSupportPkg

Kernel Debug Kit Mirror for macOS Ventura and newer - dortania/KdkSupportPkg

github.com

When AppleHDA.kext is installed the Realtek Audio should work the same as it did in Sonoma or Sequoia, i.e. using AppleALC.kext and the same layout-ID as was previously used.