CPU wrapping (SSDT-CPU-WRAP, SSDT-CPUR, "ACPI0007")

[etorix]

The problem
OS X expects processors to be declared in ACPI through Processor() objects, in accordance with versions 1.0 (December 1996) and 2.0 (July 2000) of the ACPI specification. Version 3.0 (September 2004) of the ACPI specification introduced (and obviously favoured) declaring processors as generic ACPI Device() with a specific hardware ID (_HID="ACPI0007"). From version 6.0 onwards (April 2015), the old Processor() object is officially deprecated. The current specification is version 6.4.

Fortunately for our hacks, most motherboard manufacturers still use the deprecated style in their declarations. But when they change to current standards, OS X simply cannot find any processor to run on and boot stalls at an early stage.

 

The solution
Define old-style Processor() objects in a SSDT, wrapping the processor devices.

Attached are three SSDTs for Xeon-based systems.
SSDT-CPU-WRAP.aml is suitable for uni-socket C621 systems and known to be working on Gigabyte C621-SU8 and Asus PRO WS C621-64L SAGE/10G.
SSDT-CPU-WRAP2.aml is known to work with Supermicro X11SPA-F (C422); it should be suitable for C621 systems with a PBaseAdress of 0x1810 (this appears to be the case for dual-socket Gigabyte C621-WD12… but adding the second socket if left as an exercise for the reader).
SSDT-CPU-WRAP3.aml was written for Supermicro X12SPA-TF (C621A, 3rd generation Xeon Scalable). (As of this writing, the board has not yet successfully booted OS X, but is getting ever closer.)
AMD users on B550 or A520 can use Acidanthera's SSDT-CPUR.aml.

Who needs such a SSDT?
The typical symptom is OS X verbose boot stalling just after loading the ACPI tables ("oops, there's no processor!"). The diagnostic is confirmed by dropping ACPI tables (OpenCore: use DEBUG version with Misc>Debug>SysReport:True; Clover: F4), decompiling DSDT.aml with MaciASL (or SSDT*.aml for AMD-based systems, which may not define CPUs in the DSDT) and looking for "Processor".
If you see something like

Processor (CP00, 0x00, 0x00000510, 0x06)

you're fine. If you see something like

Device (CP00)
{
    Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID

CPU wrapping is needed.

The issue first affected C621 systems for Xeon Scalable or Xeon W-3200 CPUs, possibly through a BIOS update switching from the old style to the new style. Recently, the issue arose on a C422 system for Xeon W-2000 through a BIOS update. C621A systems for 3rd generation Xeon Scalable or Xeon W-3300 are affected from the beginning.
On the consumer side, AMD B550 and A520 are affected (Acidanthera SSDT-CPUR), but curiously not X570 and earlier. Z690 for Alder Lake CPUs appears to be affected from the beginning; Intel has likely taken the opportunity of this major architectural style to update its reference ACPI code.
Z590 and earlier are fine so far, and may remain so if manufacturers do not bother rewriting their ACPI tables for "old" boards. But there's a risk that the issue could propagate through BIOS updates. HEDT systems on X299 are possibly most at risk for this, seeing what happened on C422.
Virtualisation with HyperV is also affected (Acidanthera SSDT-HV-CPU).

 

How to adapt?
The base code unit is:

Processor (PR00, 0x00, 0x00000510, 0x06)
{
    Return (\_SB.SCK0.CP00)
}

corresponding to ACPI declaration

 Processor (ProcessorName, ProcessorID, PBlockAddress, PBlockLength)

ACPI path to the CPU is to be adapted; consumer platforms would not have multiple sockets in the way (_SB.CP## rather than _SB.SCK#.CP##).

Fake Processor() objects cannot have the same ProcessorName as the CPU Device(). SSDT-CPU-WRAP and WRAP2 wrap CP00 to PR00; SSDT-CPU-WRAP3 wraps C000 to CP00. Renames are needed if your motherboard defines CPUs with names other than CP##—double renames if the CPUs are named PR## ('#' being any decimal or hexadecimal digit). The names are arbitrary, and the "numbers" in there are not a real counter, but it helps writing ("Find & Replace" is your friend) and checking the SSDT, if the real and fake CPUs have the same "number" and this also matches ProcessorID.
ProcessorID must be unique to each processor.
Per the specification, PBlockLength only has two valid values: 0 or 6. For us, it will always be 6.
Typical values for PBlockAddress would be 0x510, 0x1810, 0x810 (AMD) or 0x410 (old Intel). If the right value for the board is not known from a previous DSDT, it can be computed from the FACP.aml ACPI table: Add 0x10 to the hexadecimal value at offet 0x98 of FACP.aml.

Spoiler

This indicates that the processor base address register is 0x1810 (0x1800 at offset 0x98, plus 0x10):

The ACPI compiler will not yet you forget to also adapt all the External() references.

 

What else?
When using a CPU wrapping SSDT, any further SSDT which refers to the CPU—typically SSDT-PLUG for power management on Intel platforms—should: 1) load after SSDT-CPU-WRAP; and 2) target the fake Processor() objects in SSDT-CPU-WRAP and not to to the real CPU Device() in the DSDT (so _SB.SCK0.PR00 with SSDT-CPU-WRAP(2) as provided, and not _SB.SCK0.CP00).
 

Thanks to @metacollin for identifying the issue and writing the first wrapping SSDT, to @yapan4 and @obus for their enduring support while I was hacking my C621 system, to @yapan4 and @Balamut for additional testing, to the zero-post user who tipped me on simplifying wrapping through a private message, to @Pike R. Alpha for ssdtPRGen.sh and computing PBaseAddress, and to the Acidanthera team for their ACPI guides which greatly helped me grasp how to write SSDTs. (I've not yet adopted the ACPI specification as bedtime reading, but I've got a little closer…)

 

 

SSDT-CPU-WRAP.zip

 

 

Z690 and Alder Lake

Use the attached SSDT-CPUR-Z690.aml. It has been successfully tested on Gigabyte Z690 Gaming X DDR4, and allowed to boot and install Big Sur.

SSDT-CPUR-Z690.aml

 

As this is an early result, please check for your system, using the above guide to adapt, and report if adaptation was indeed necessary.

SSDT-CPUR-Z690.dsl

 

Edited November 9, 2021 by etorix
Alder Lake update

[miliuco]

Excellent work!!! Useful for times to come.

[etorix]

Acidanthera has come up with an alternative SSDT for Alder Lake which combines processor declarations and power management. That's quite elegant, as it avoids some user confusion that "SSDT-PLUG does not target processors as found in the DSDT" and, most remarkably, SSDT-PLUG-ALT does not even reference the actual processor devices.

 

Dear @vit9696, if you happen to pass by, would you care to explain how SSDT-PLUG-ALT works? As it stand, this SSDT seems to create processors out of thin air. How can calls to the standard methods of actual processors (_PDC, _OSC, _PPC, _PCT, _PPS, etc.) achieve anything if there is no connection between _SB.CP00 in SSDT-PLUG-ALT and the actual _SB.PR00?

 

Incidentally, the comments of SSDT-PLUG-ALT indicate that OS X makes no use of PBaseAddress, and that setting this value is purely cosmetic. This means that my SSDT-CPU-WRAP and SSDT-CPU-WRAP2 are functionally identical., and that adaptation is only required for the the processor names.

[miliuco]

@etorix

Thanks for the info. I've seen the new Acidanthera's SSDT for Alder Lake. Are you etorix also in the other forum? The expert guy in Alder Lake right now? 🙂

[Aluveitie]

On 11/6/2021 at 4:15 PM, etorix said:

On the consumer side, AMD B550 and A520 are affected (Acidanthera SSDT-CPUR), but curiously not X570 and earlier.

 

To give some context: AMD usually doesn’t create its own chipsets. Recently it let ASMedia do it, though they failed to be ready in time for Zen 2. AMD had to pull X570 out on its own (it is basically a Zen 2 IO chiplet repurposed as southbridge). Since that was produce by GF 14nm, it required better/active cooling.

 

B550/A520 were finally released by ASMedia over a year after Zen2/X570. And this is the reason they are very different in some aspects.

 

Edited November 16, 2021 by Aluveitie

[etorix]

Yes, I'm not imaginative with aliases. But I'm no expert on Alder Lake! I'm just a hackintosher who suffered for some months on a Xeon Scalable build, found about @metacollin's work on CPU wrapping along the way, took that along and kept the flame forward. The original post above is a brain dump on what I learned along the way, not long after connecting the final dots (namely, where and how to extract PBaseAddress for perfectly standard-compliant declarations).

 

It turns out that this knowledge was helpful to kickstart Alder Lake, which is great, and I follow the thread with interest. But CaseySJ and Elias64Fr have far greater mastery of ACPI than I do, and there's no doubt who's quickly turning into the Alder Lake expert. I do not even have an Alder Lake system, and do not intend to—well, if it does work good, maybe I'll give Sapphire Rapids a try…

[miliuco]

21 minutes ago, etorix said:

... But CaseySJ and Elias64Fr have far greater mastery of ACPI than I do, and there's no doubt who's quickly turning into the Alder Lake expert. I do not even have an Alder Lake system, and do not intend to...

Yes, I forgot CaseSJ and others, I was thinking in the EFI for Alder Lake you posted there, and if you even have such a system... 👏

[etorix]

5 hours ago, Aluveitie said:

To give some context: AMD usually doesn’t create its own chipsets. Recently it let ASMedia do it, though they failed to be ready in time for Zen 2. AMD had to pull X570 out on its own (it is basically a Zen 2 IO chiplet repurposed as southbridge). Since that was produce by GF 14nm, it required better/active cooling.

 

B550/A520 were finally released by ASMedia over a year after Zen2/X570. And this is the reason they are very different in some aspects.

Thanks! This explains why X570, and also TRX40 for Threadripper (another repurposed I/O die), are not affected. There can even be a reasonable hope that ACPI for these chipsets will not be updated to v.6.x.

[Guest 5T33Z0]

I have a question about the workflow when adding the SSDT-WRAP tables:

• So for Xeon, I basically would have to check in the DSDT if ACPI0007 exists
• If so, I check which naming scheme for the CPU is used.
• Select the corresponding SSDT for that name scheme
• adjust the number of DeviceObj in accordance to the number of CPU cores. save it and then add the SSDT#

Is this correct?

[etorix]

@5T33Z0 Correct: Check in DSDT if this is needed at all (ACPI0007 devices), adjust path/names and number of Processor() as needed. Plus a SSDT-PLUG for power management which points to the first "fake" Processor() in the wrapping SSDT rather than to the DSDT device.

It's not specific to Xeons, since the latest 12th generation Core (Alder Lake) need that as well.

[Guest 5T33Z0]

Thanks for the explanation. So SSDT-Wrap and SSDT-PLUG are required. But Westmere-EP and everything before 4th gen use the legacy plugin. So then you would use the SSDT-PM that ssddtPRGen generates instead of SSDT-Plug or just set the Value for the plugin to ZERO instead of ONE?

 

[etorix]

It's not for all Xeons either! Only those motherboards whose ACPI tables have been upgraded to a recent version of the specification. So far, affected Intel platforms are C621 (depending on firmware version), C621A (probably all), C422 (one known Supermicro motherboard, depending on firmware version) and Z690 (all).

Westmere and other old Xeons certainly do not need it, otherwise many more people would have noticed the issue much earlier.

 

Theoretically, all that is needed to adapt a previous SSDT-PM is to change the ACPI name of the processor (no change to the content). If one were to run ssdtPRGen on a platform with CPU wrapping, I suppose it would pick the "right" processor, that is the fake one in SSDT-CPU-WRAP, since this is the one used by macOS.

[etorix]

Adding a version for dual socket 3rd generation Xeon Scalable:

SSDT-CPU-WRAP3-2S.zip

[anerik70]

Hi, I have this

 

Do I need the fix?

[etorix]

Theory says you have "Processor" devices, so no SSDT needed. (That's in the first post.)

 

If the ACPI code is from the X79 system in your signature, which is already running Big Sur, practice concurs you didn't need a SSDT to get there.

[anerik70]

On 6/7/2022 at 8:42 AM, etorix said:

Theory says you have "Processor" devices, so no SSDT needed. (That's in the first post.)

 

If the ACPI code is from the X79 system in your signature, which is already running Big Sur, practice concurs you didn't need a SSDT to get there.

Thanks for answer

[hardcorehenry]

I made another variation of SSDT-PLUG-ALT, some might consider as cosmetics, but I don’t like the idea of having CP00, CP01,… and RP00, RP01,… “both” present in ioreg, so I maintained original scopes and used different method to rename Device to Processor. Could someone take a look and see if it’s proper approach.

Spoiler

 

SSDT-PLUG-ALT.aml

Edited November 5 by hardcorehenry

[etorix]

Have you tested it?

Each PR## processor should have its own _UID, not always 'One'.

If it works, which may well be the case for macOS, this should actually create _SB.PR00.PR00 and so forth. I don't think you can "retype" a DeviceObj to Processor. Do not load this SSDT with another OS as both the parent and the fake child would be active.

[hardcorehenry]

I tested it only in macOS tried on Linux (live USB) only if it boots. Noticed, that neither _UID and _HID, "ACPI0007" show in ioreg, that’s why asking for second opinion, besides didn’t experienced any issues. Now, after reading your comment, not so sure. Anyway, switched back to original SSDT-PLUG-ALT for now…

[hardcorehenry]

On 11/16/2021 at 2:28 PM, etorix said:

As it stand, this SSDT seems to create processors out of thin air. How can calls to the standard methods of actual processors (_PDC, _OSC, _PPC, _PCT, _PPS, etc.) achieve anything if there is no connection between _SB.CP00 in SSDT-PLUG-ALT and the actual _SB.PR00?

Couldn’t get rid of this thought, and although Acidanthera’s SSDT-PLUG-ALT works without issues I started testing your Alder variant, added _STA Method, plugin-type and cf-frequency-data, so far so good.

 

SSDT-PLUG-ALT.aml

Edited November 16 by hardcorehenry

[etorix]

Reportedly, macOS only need Processor() stubs, and does not use any of the attached ACPI code.

Plugin-type is not even required if you're using a recent version of macOS, as this as been deprecated.

[hardcorehenry]

Without plugin-type I can’t attach cf-frequency-data with custom FrequencyVectors, without which performance is not acceptable for me.

Edited November 16 by hardcorehenry