Fails to patch PECI_IsEarlySAMUInitEnabled: 0 in Monterey B4

[ghost]

Hi Osy, Thanks for all the great work you have done over the last 2 years to enable macOS to run on the Hades Canyon NUC. I have been trying to get graphics acceleration working in Monterey Beta 4 using my fork of Polaris22Fixup which can be found here:

https://github.com/dgsga/Polaris22Fixup

All I have done with the fork is to update the code to remove legacy OS support and use the new Lilu API's introduced in version 1.5.1. In Monterey the dyld cache is split into four parts, hence the need to update the repo.

• Added lilu_os_memmem and lilu_os_memchr APIs
• Added getSharedCachePath API to obtain current cache path
• Added LIKELY/UNLIKELY macros.

This fork works fine in BigSur 11.5.1 but in Monterey I get a glitch-free desktop but no graphics acceleration. All relevant kexts show as loaded. I have attached a full Lilu log showing the failure (highlighted in red) to patch PECI_IsEarlySAMUInitEnabled. Lilu_1.5.6_21.0.rtf.zip.

In the ioreg device tree: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG0@1/IOPP/GFX0@0/AMDRadeonX4000_AMDEllesmereGraphicsAccelerator is missing.

[MotorBottle]

May I ask where to download this moded kext please? Much appreciated!

[keatliang2005]

you can download the source and compile your own https://github.com/dgsga/Polaris22Fixup

you can refer to this thread how to compile from source https://github.com/OpenIntelWireless/itlwm/issues/158

[MotorBottle]

Thanks for help!

[goodbest]

Hello @dgsga , thanks for sharing your fork.

I've compiled your fork repo into kext (together with Lilu1.5.5 and WEG1.5.1). It's fully working under 11.5.1. But I got a black screen after lots of -v stuff under 12.0b4, and I can't even get a desktop without acceleration.

I see that you are using Lilu 1.5.6 and WEG 1.5.2 with your log. Do you use the amd device-id spoofing function that introduced in WEG 1.5.2 in your test? If so, I wonder that may interfere with the current HacMini's gpu spoofing method, which makes the issue more difficult to track.

Can you give your test result (and your compiled kext) with Lilu1.5.5 and WEG1.5.1?

[MotorBottle]

Hello @dgsga , thanks for sharing your fork.

I've compiled your fork repo into kext (together with Lilu1.5.5 and WEG1.5.1). It's fully working under 11.5.1. But I got a black screen after lots of -v stuff under 12.0b4, and I can't even get a desktop without acceleration.

I see that you are using Lilu 1.5.6 and WEG 1.5.2 with your log. Do you use the amd device-id spoofing function that introduced in WEG 1.5.2 in your test? If so, I wonder that may interfere with the current HacMini's gpu spoofing method, which makes the issue more difficult to track.

Can you give your test result (and your compiled kext) with Lilu1.5.5 and WEG1.5.1?

Did the same thing as you do, and the result was same as yours. Still no signal output after -v codes finished running. Lilu 155 and weg 151.

[keatliang2005]

Hello @dgsga , thanks for sharing your fork.

I've compiled your fork repo into kext (together with Lilu1.5.5 and WEG1.5.1). It's fully working under 11.5.1. But I got a black screen after lots of -v stuff under 12.0b4, and I can't even get a desktop without acceleration.

I see that you are using Lilu 1.5.6 and WEG 1.5.2 with your log. Do you use the amd device-id spoofing function that introduced in WEG 1.5.2 in your test? If so, I wonder that may interfere with the current HacMini's gpu spoofing method, which makes the issue more difficult to track.

Can you give your test result (and your compiled kext) with Lilu1.5.5 and WEG1.5.1?

I did manual update few week ago , WEG interfered some how, as far I know, the developer branch added additional property no device spoof

https://github.com/osy/HaC-Mini/issues/614

https://github.com/acidanthera/bugtracker/issues/1743

[goodbest]

And now let's talk about the PECI_IsEarlySAMUInitEnabled part. We should find a way to deal with it.

What to patch

In 11.5.1 and below, Apple provide the named symbol _PECI_IsEarlySAMUInitEnabled in /System/Library/Extensions/AMDRadeonX4000HWServices.kext/Contents/PlugIns/AMDRadeonX4000HWLibs.kext/Contents/MacOS/AMDRadeonX4000HWLibs. So it's easy to patch that function to always return 0 by KernelPatcher::RouteRequest and Functioncast in Lilu.

The bad news is, for 12.0b4, there's no named symbol for that function. Of course that function's code still remains the same in the kext for both 11.5.1 and 12.0b4.

You can see that the named symbol disappeared (up= 11.5.1, bottom=12.0b4)

What should be patched

In short, based on osy's explanation, we want to make that function always return 0. We may have to do binary patch if the simple Functioncast way is unavailable.(I'm not sure).

patch manner 1

static const uint8_t kPECI_IsEarlySAMUInitEnabledOriginal[] = {
    0xbe, 0x60, 0x01, 0x00, 0x00, 0xff, 0x90, 0xb8, 0x00, 0x00, 0x00, 0x31, 0xc9, 0x83, 0xf8, 0x01, 0x0f, 0x94, 0xc1, 0x89, 0xc8, 0x5d, 0xc3,
};
static const uint8_t kPECI_IsEarlySAMUInitEnabledPatched[] = {
    0xbe, 0x60, 0x01, 0x00, 0x00, 0xff, 0x90, 0xb8, 0x00, 0x00, 0x00, 0x31, 0xc9, 0x83, 0xf8, 0x00, 0x0f, 0x92, 0xc1, 0x89, 0xc8, 0x5d, 0xc3,
};

We can compare the effect of the patch (by decompiling the binary and translate into C. You can try Hopper to do that) As rax should never be less than 0, so 0 is returned. (up = origin, bottom=patched).

patch manner 2

static const uint8_t kPECI_IsEarlySAMUInitEnabledOriginal[] = {
    0xbe, 0x60, 0x01, 0x00, 0x00, 0xff, 0x90, 0xb8, 0x00, 0x00, 0x00, 0x31, 0xc9, 0x83, 0xf8, 0x01, 0x0f, 0x94, 0xc1, 0x89, 0xc8, 0x5d, 0xc3,
};
static const uint8_t kPECI_IsEarlySAMUInitEnabledPatched[] = {
    0xbe, 0x60, 0x01, 0x00, 0x00, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x31, 0xc9, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x89, 0xc8, 0x5d, 0xc3,
};

For manner 2, the effect is more straightforward.

patch manner 3 (to aggressive, not recommended)

We can also directly patch the bit CAIL_DDI_CAPS_POLARIS22_A0 from 1 to 0.

The original values are 05008000 FE110000 80000000 00100011 00020000 01000068 00004029 02400000 01018A62 1086A241 00000022 03000000 00000000 00000000 00000000 00000000 The patched value: 05008000 FE110000 80000000 00100011 00020000 01000068 00004029 02400000 01018A62 1086A241 00000022 02000000 00000000 00000000 00000000 00000000

[keatliang2005]

12.B5 (21A5304g) is released , i wondered the named symbol issue still exists ?

also i lookup in the method in Lilu (master) this particular method is interesting https://github.com/acidanthera/Lilu/blob/master/Lilu/Sources/kern_patcher.cpp

mach_vm_address_t KernelPatcher::solveSymbol(size_t id, const char *symbol)

[goodbest]

12.B5 (21A5304g) is released , i wondered the named symbol issue still exists ?

also i lookup in the method in Lilu (master) this particular method is interesting https://github.com/acidanthera/Lilu/blob/master/Lilu/Sources/kern_patcher.cpp

mach_vm_address_t KernelPatcher::solveSymbol(size_t id, const char *symbol)

Nope, b5 is as same as b4. This might be the standard in new official releases.

BTW, KernelPatcher::solveSymbol is not usable because we don't have symbols to solve.

[keatliang2005]

The symbol issue seems like the

keepsyms=1 boot arguments Or the kernel quirk DisableLinkeditJettison

I’m not sure is the feature is broken, or the graphics driver out right had the symbol removed

this issue very similar back in early bigsur day Where lilu need need keepsysms to work https://github.com/acidanthera/bugtracker/issues/1353

Maybe @osy or @vit9696 have some idea.

[vit9696]

Cannot you check where the virtual call points to? Perhaps the symbol for it exists. I guess the easiest way is to pass rdi (this) as zero, as it will access this inevitably, and then panic, showing the symbol we need in the backtrace if it exists.

[goodbest]

Cannot you check where the virtual call points to? Perhaps the symbol for it exists. I guess the easiest way is to pass rdi (this) as zero, as it will access this inevitably, and then panic, showing the symbol we need in the backtrace if it exists.

I'm afraid almost all symbols for this kext are gone in the 12.0b4/5. So the symbol backtrace is not handy. The one we care should be the last one in the following two pics. (up = 11.5.1, bottom=12.0b4/5)

Can someone help check the symbols, in case I'm doing something wrong?.

AMDRadeonX4000HWLibs_1151.zip

AMDRadeonX4000HWLibs_12b5.zip

[keatliang2005]

AMDRadeonX4000HWLibs_1151

Just for latest release of 1152 AMDRadeonX4000HWLibs_1152.zip

[vit9696]

You did not understand me. I do not mean the XREF, but rather the name of the symbol which address is calculated at 938e0 call instruction.

[goodbest]

@keatliang2005 @dgsga Can you test this one with 11.5 and 12.0b5. (with lilu 1.5.5 and weg 1.5.1)

Polaris22Fixup.kext.zip

[keatliang2005]

@keatliang2005 @dgsga Can you test this one with 11.5 and 12.0b5. (with lilu 1.5.5 and weg 1.5.1)

Polaris22Fixup.kext.zip

I had test the kext works under macOS 11.5.2, Lilu 1.5.5, WEG 1.5.1

as for 12.0B5 i don't have that installed maybe wait for @dgsga or @MotorBottle test it work or not they have access to beta release.

[MotorBottle]

Tested working on Monterey b4. how did you fix this? Animation and video acceleration both works, will try upgrading b5 later.

[keatliang2005]

Next we should figure out what happen with WEG 1.5.2 + cause it cause some issue, seems like device-id spoofing related

we can continue discussion, debug here https://github.com/osy/HaC-Mini/issues/614