WORLD FIRST: macOS Sequoia 15.7 bare-metal on AMD EPYC 7302P (Zen 2 Rome server CPU) with SMT 32 threads active — Geekbench 6 multi 8207

[lolo5023]

Hello AMD-OSX community,

After 40+ boot attempts and weeks of work, I finally got macOS Sequoia 15.7.7 booting bare-metal on an AMD EPYC server platform with SMT fully active. As far as I could find — after extensive searches across forums in EN/FR/DE/CN/RU/VN/KR/JP — no one had previously documented a successful bare-metal Sequoia boot on AMD EPYC. The only EPYC + macOS case out there is a Proxmox VM with PCIe passthrough, which doesn't count as bare metal.

Hardware:

• Supermicro H11SSL-i v2.0 (server board, IPMI/BMC ASPEED)
• AMD EPYC 7302P (Zen 2 Rome, 16C/32T)
• AMD RX 6800 16GB (RDNA 2)
• 64GB DDR4 ECC RDIMM SK Hynix
• Crucial P310 2TB NVMe
• macOS Sequoia 15.7.7 (build 24G720)

Results:

• 32 SMT threads detected by macOS (hw.ncpu=32, HTT flag active)
• Geekbench 6 Single: 1217 (+7.3% vs world average for this CPU)
• Geekbench 6 Multi: 8207 (+3.6% vs world average)
• GPU OpenCL RX 6800: 89761 (Mac Pro 2019 level)
• Native Ethernet, audio, USB, daily-driver stable

Public Geekbench result (verifiable):

https://browser.geekbench.com/v6/cpu/18196255

Full writeup with the technical story (failed attempts, dead ends, the 4 key blockers I had to solve, BIOS settings, credits):


Huge thanks to Micking (Michael Perche) who unblocked me on the T2/SMBIOS issue when I was about to quit, and to the Acidanthera + AMD_Vanilla maintainers without whom none of this is possible.

I'm not publishing my config.plist, EFI or kernel patches — this is purely a documentation post about the journey. macOS on non-Apple hardware violates Apple's EULA, this is a personal/educational experiment.

Happy to discuss the technical hurdles in the comments — especially if anyone here is wrestling with EPYC Rome/Milan platforms and high-MMIO debugging on macOS.

— Jeremy "PASEO" Choulant

 

[MickinG]

The Reality of the Facts: Anatomy of a False Narrative​

The narrative of a "solitary pioneer" who supposedly spent weeks researching, selecting, and assembling an unprecedented configuration specifically for a macOS milestone is a public relations fabrication. The hardware and software chronology, fully documented and archived, establishes a completely different reality based strictly on technical facts:

1. The Hardware Reality: A Two-Year-Old Legacy Server​

The claim that this hardware configuration was specifically researched and sourced for this project is false. The hardware stack—consisting of the Supermicro H11SSL-i v2.0 motherboard, the AMD EPYC 7302P processor, and ECC RAM—is an enterprise server infrastructure that I personally advised on and configured two years ago for the agency's original deployment under Proxmox VE (as verified by system monitoring logs from that period). This project did not stem from a recent components search; it is the recycling of a standard production server that I put on the hardware tracks on day one.

2. The Complete Failure of Automated Methods (AI & Prompts)​

The public narrative attempts to portray a fluid, solo progression. In reality, the exclusive reliance on generic templates and stacked AI prompts resulted in a complete impasse: over 40 failed boot attempts and systematic black screens. Automated tools were fundamentally incapable of diagnosing or resolving the primary blocker of the project: the physical memory collision at high-MMIO address 0xCFC000, which is natively reserved by the BMC ASPEED administration firmware of the server board.

3. The Documented Admission: "About to quit"​

On international technical forums, where marketing spin holds no weight, the individual explicitly admitted the truth in writing: he was "about to quit" prior to my engineering intervention. Claiming publicly on social media that my contribution was limited to "3 or 4 minor boot-args" directly contradicts his own written credits, where he acknowledges that I personally unblocked the system on the critical architectural node of the project (resolving the kernelmanagerd process panic linked to SMBIOS/T2 dependencies and stabilizing early XNU kernel initialization).

4. The Technical Signature​

System engineering does not lie. A custom OpenCore EFI capable of natively booting macOS Sequoia on a datacenter CPU utilizing only 6 base kexts and zero on-the-fly ACPI patches is not the product of an automated algorithm or trial-and-error. It is the definitive signature of a human, surgical diagnostic executed via low-level debugging.

The system files, before-and-after crash logs, the exact chronology of file modifications, and the complete history of remote access sessions to the machine are fully archived and secured. Commercial spin and social media posts cannot rewrite source code. The technical facts are documented, immutable, and unassailable.