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?