iGPU

For those who might be interested in creating patches (or at least, making a relatively simple one like for the Aquantia port), I made a post on another thread on this forum on my attempts at learning the basics of patch making.

A Reverse-Reverse-Engineering Patch Tutorial

For those who already know what I'm posting here and consider this simplistic: sorry. I'm presenting this information for those, who like myself, may be unaware of how patches are created. Virtually every time I've read about a new patch, the patch is presented only by itself or only with the smallest of hints as to how it was created.

Recently, I've spent hours trying to get the SmallTree I211 kext to work under Monterey. I've not yet succeeded, but the attempt led me to think a patch might be necessary. SInce I didn't know how to make a patch, I thought a good way to learn might be to "reverse engineer" an existing patch.

That thought led me to study patches for the Aquantia ethernet port. There is a long thread over at InsanelyMac (here) where Aquantia patches are discussed for various macOS releases. These patches seemed to have become necessary with the release of Catalina and Big Sur (Mieze and Shikumo seem to have done most of the work). Recently, a new patch for Aquantia was found to be necessary for Monterey; it was discussed in this post by Mieze (from whom I've gleaned the most about kext patches). This means there are several examples to test-out the reverse engineering process. (BTW, what's described below was also tried out on the Big Sur Aquantia patch and this process works with that patch too.)

1. Initial Attempt - OTOOL/HEX FIEND

My first attempts to reverse engineer the Aquantia patch began by using the tools discussed in the first post on this thread (from Piker Alpha, using otool (part of macOS): extracting the contents of the Aquantia kext file into a text file), along with using Hex Fiend (a download). The Aquantia kext file is located inside the IONetworkingFamily kext as a plugin (you have to dig a bit to find it!): IONetworkingFamily/Contents/Plugins/AppleEthernetAquantiaAqtion/Contents/MacOS/AppleEthernetAquantiaAqtion.

[Note that all editing and work below was carried out on a copy of the kext file that was transferred from "S/L/E/IONetworkingFamily" to the desktop, so nothing destructive was done to the original file.]

The text file can be created with otool with the following command (drag and drop your file  location in place of the  "/~/~/" section):

otool -tV /~/~/AppleEthernetAquantiaAqtion > ~/Documents/Aquantia.txt

And this same AppleEthernetAquantiaAqtion file can be examined with Hex Fiend. The combination of otool's resulting text file (upper left) and Hex Fiend (upper right) are shown below, where they're also compared with the link from Mieze (bottom left):

Unfortunately, I couldn't figure out how to derive the patch from this data.

2. Successful Attempt - IDA64

It wasn't until I did some searching and came across a tool from the Belgium company, Hex-Rays. They offer a free download (here) of the IDA64 macOS app to try out and that is what I'll present next. The idea behind using this app is to de-compile the kext file. But what I'm actually trying to do is "reverse engineer" Mieze's "reverse  engineering" of the de-compiled kext file. If successful, then we can learn how to better make patches.

We can start this process from some knowledge shared on that thread: we know the area in the kext to examine ("checkConfigSupport", shown in above image) and the given Find string ("41 C7 45 00 00 00 00 00 E9"). Between these two items, we can zero-in on the area that needs to be patched.

The first step is in opening the file (again, the nested AppleEthernetAquantiaAqtion file contained within IONetworkingFamily from the latest Monterey ß3) with the IDA64 app. When opening, the default settings in IDA64 are best (shown in Spoiler below).

Once opened, the initial screen can have the windows rearranged (initial view shown in Spoiler below).

I prefer the Function View be expanded on the left as shown below (also shown is the search window which is accessed from the menu bar). This particular search item was chosen based on discussions in the InsanelyMac thread, where Mieze describes (in Spoiler):

When this search is completed, and the Function View item on the left double-clicked, the following can be seen in the right pane. But the result is not obvious as the presentation is a bit complicated: the right pane must be scrolled (shown as separate images in the Spoiler below).

After scrolling the right pane, we can begin the process. On the left pane, note that the Aquantia item is "107" which references the AQC107 port name. Next, even after scrolling, there are  many windows in the right hand pane. Since we're reverse engineering, we already know that we're looking for something that should say "__ZN30AppleEthernetAquantiaAqtion10718checkConfigSupportERiS0".

This is highlighted below on the right. As pointed out in the InsanelyMac thread, we need to change the value of "0" to "1", but first we need to find the corresponding hex code. We  do this by clicking on the "mov" command (highlighted below right). Once the "mov" command is selected, the corresponding hex code will also be selected for us, but to see this, we need to change views.
 

To see the hex code, change views by clicking on Hex View near to the top of the window. The new view switches the right pane from the IDA View above to the Hew View below. Again, since we clicked on the "mov" command in the above step, the correct hex code for this command is already highlighed in dark green.

We then look for the Find string which is "41 C7 45 00 00 00 00 00 E9", but notice that the "mov" command did not contain the "E9". The next byte seems to be chosen when patching to help ensure only one site is patched. The replacement will simply over write this byte with the same value.

But to change the "0" to "1", we need know which byte to change. This can easily be tested in real time by editing the hex code as shown below: right-click on the byte to change.

The cursor will be in the middle of the byte to change the right least significant value as shown next. To make this change 'stick',  we need to apply it. This is done by again right-clicking.

This change can be verified by switching from the Hex View to the IDA View. If incorrect, switch back to the Hex View, re-edit as needed and re-apply and return to the IDA View once more to verify if now correct. If the correct byte was changed, you'll see the following:

At this point, we can see that the Find value of "41 C7 45 00 00 00 00 00 E9" and the replacement value of "41 C7 45 00 01 00 00 00 E9" now all make sense and this seems to be how this patch was derived.

If anyone has any comments or corrections to the above let me know and I'll edit this post.

[BTW, I compared the Monterey ß3 Aquantia file to that of Monterey ß1, using Hex Fiend: there is no difference. However, this is quite a difference in this same file between Monterey and the latest release of Big Sur.]

ADDENDUM - Future Approaches

3 minutes ago, fabiosun said:

I did in this way (sip disabled)

otherwise I have this:

 

Yes, I did that, but the key is that I did not disable SIP. (I must go to work, so later I try.)

Thanks!

43 minutes ago, fabiosun said:

Ciao Carlo

above 4g

i can use also off on 4g

try by now 🙂

 

I agree that Monterey is running smoothly with the best sleep/wake cycle that I've yet seen on the TRX40. 😃

What I want to ask you is how you get CB15 to run.

I've only gotten errors on Big Sur and Monterey. I've tried all sorts of permission approvals and I only see a series of these (spoiler) for each dylib element.

1 hour ago, Arrakis said:

here is my config.plist under your Opencore 0.7.2 version

Arrakisconfig.plistzip.zip 6.34 kB · 2 downloads

A few comments regarding your config file. But first, are you trying to boot into BS or new Monterey; if latter, then do a fresh install (as I mentioned in a recent post above).

When systems behave strangely, remove un-necessary items. In your case, remove the TB AIC (and note Spoiler below) and any USB devices if possible.

Kext adjustment (also, if not necessary, since you had so many problems with I225, maybe disable those kexts and unplug your ethernet cables until system booting reliably):

I'd use change these Kernel/Quirks (Boot/Quirks look ok):

And you might try a MmioWhitelist variation:

Your Patches look ok, but the following are not needed for BS onwards and could be removed:

Finally, the UEFI section: a few changes to try:

Just now, jsl2000 said:

Thanks.

So even RestrictEvents.kext can be disabled  ?

Read this summary along with fabiosun's post preceding that post to understand what is going on with the new Quirk and patches.

RestrictEvents has nothing to do with booting; it's more cosmetic. (You might also read this link too to get an idea of the EFI structure.)

The basic factors affecting booting are:

1. Booter/MmioWhitelist
2. Booter/Quirks
3. Kernel/kexts (mostly Lilu and VirtualSMC)
4. Kernel/Patches
5. Kernel/Quirks

fabiosun in his uploaded OCv072-Shanee EFI has it all laid out. Change very little or you will make things difficult for yourself. Don't be creative at this stage. You only need to adjust your mobo MmioWhitelist as most everything else will work for all of our TRX40 mobos. For some reason, many people keep changing the Quirks around and this is a guaranteed way of getting a boot failure. fabiosun and I have kept the Quirks the same for several days now.

***

To avoid trouble when experimenting with your EFI, I would suggest doing the following.

To keep testing simple, my BIOS is set to boot from a known, working EFI (call it #1). I have the same, working EFI on another drive (call it #2 that I do not change; this is my backup EFI) that I can access by pressing F11 during boot (may be a different key for your mobo). EFI #2 is my backup guaranteeing that I can gain access to my computer (yes, I also have external USB EFI serving as even more backups).

At this stage, what ever EFI works (boots) is okay; don't worry about minimal patch lists, etc.  EFI #1 will then become my experimental EFI that I change.

In addition to different EFIs, one of these two drives contains a known working macOS (such as Big Sur). The other drive contains the new, to-be-tested macOS (such as Monterey). During the automatic boot, EFI #1 is selected and once the OC menu appears, I then select which OS to enter.

Again, I test on the EFI #1, making any changes only to it (not EFI #2). If I break it, such as by using a bad patch, and it won't boot, I re-start computer, hold down the F11 key, select EFI #2. Once booted through EFI #2, I can then make changes on EFI #1 and test it again, repeating this cycle as desired.

If you only use one internal EFI and drive, your backup EFI could be an external USB. I tend to use internal drives and their EFIs for testing, since USB drives are slower to boot and prolong the test cycles.

SOLVED

When weird things happen, double check the drive and macOS. The drive I used was updated from Big Sur to Monterey ß3. Things must have been corrupted. So I erased the drive and did a fresh install of Monterey ß3.

Now, the Aquantia port works just fine on ß3 with usual patch (and the ß1 Aquantia port worked, because is was a fresh install).

I'm leaving the problem below as a reminder: do a fresh install, especially with a new macOS if your system is behaving strangely.

*******

OK, new problem... which only pertains to those of us with internal Aquantia ports. (Well, maybe only pertains to me, unless I read of others having this problem.)

BTW, the SmallTree kext for the I211 is an entirely different problem and does not work in Monterey (and I've found not solution to date), but won't discuss here.

A bit of history: the internal Aquantia port worked natively in Mojave, but began requiring a patch starting with Catalina. This same patch worked with Big Sur. However, Monterey ß1 seemed to require a new patch (not quite true; shown below in Spoiler). The new Aquantia patch which works in Mß1, does not work with Mß3. [Aside: I have an external USB-NVMe with Mß1 and an internal NVMe with Mß3 to trouble-shoot and compare.]

I've compared the IONetworkingFamily/Contents/Plugins/AppleEthernetAquantiaAqtion kext file from M-ß1 and M-ß3 in the Hex Fiend app and the files are identical. Since there were no changes, it seems rather strange to me that the same patch doesn't work.

1 hour ago, fabiosun said:

I have installed from an USB installer to do a "clean" test

With MacPro7.1 ,no WEG, only -v as bootarg a SSDT for GPU pM and other few stuff

I have a pciex card for my 960 pro nvme and also Aquantia card as pciex card...
two NVME on M2 slots and a bunch of mechanical disks and bd writer..

tb not inserted from a bit of time..so I can't say

 

@iGPUif you have installed beta 3 and if you have time to test try to change MaxKernel of algrey - _cpuid_set_info - GenuineIntel to AuthenticAMD - 10.13/10.14/10.15/11.0/12.0 to 20.99.99

It seems not mandatory for Monterey

I have also said @Shaneeeto verify it in his testing steps..

we verified it also on lower platform as x570 or x370 so it should be fine for all platform

 

I've installed Mß3. I can confirm that with the new Shaneee EFI that "algrey - _cpuid_set_info - GenuineIntel to AuthenticAMD" is not needed for Monterey ß1 or ß3 (I've skipped ß2 and keep a USB drive with ß1, which I'll discuss below). This patch, even with new PF EFI, is still required for the latest 11.5 Big Sur.

***

A comment, unrelated to the above patch. I've randomly observed a refusal of Mß3 to respond to either the "Restart..." or "Shutdown..." menu commands, forcing me to power cycle the computer. I did not see this with Mß1. 

For WiFi/BT in Big Sur and Monterey, look at following image. Note: this is only for Fenzi-type AIC or swapped internal cards, not the stock, internal AX200. WIth a mac-compatible card, these kexts will allow AirDrop to work. See this post of details. To use the kexts shown below, you also must inactivate the internal AX200. I have discussed this many times (see here and here). If you do not inactivate the internal AX200, your BT will not properly work.

On the other hand, if you use the stock AX200, entirely different kexts are required (which I won't discuss here), and in that situation, you must not use any of the kexts in the below image. I refer to the special AX200 kexts in the above first referenced post, providing a link to their source. Furthermore, understand that if you use the internal AX200, while you'll have WiFi and BT with those other kext files, AirDrop will not work: trade-offs.

7 hours ago, fabiosun said:

Hello everybody
in the attachment I add another variable for you that could cause more confusion .. (ehehehe joking)

But in the spirit of always sharing everything that is possible to share ... 🙂 :P

attached the EFI of opencore that can be obtained by filling in the Shanee Pull Request posted in this thread:

OpenCore-0.7.2-DEBUG-Shanee.zip 4.18 MB · 1 download

attached also patches I use with this EFI 🙂

remember now a quirk includes a lot of patches.

Patches for PR EFI.plist.zip 1.88 kB · 2 downloads

latest to patches are for Aquantia ethernet card I use)

Patches are for BigSur and latest Monterey Beta (1-2-3)

Disclaimer:

this PR EFI is not yet approved by Opencore Devs team and it is not included in official release or beta from them

If I understand what you've presented (and after studying Shaneee's pull request), and to help clarify for others, is the following true?

With this custom commit, when ProvideCurrentCpuInfo is enabled, behind the scenes, OC automatically calculates patch 0 since it 'knows' the current CPU core count and the macOS version and thereby determines the proper mask and replacements. In other words, there is no new Quirk, or any other data to enable, except for ProvideCurrentCpuInfo, which is now more powerful. Aside from patch 0, all other patches remain the same.

3 minutes ago, Ploddles said:

 

Thank you.

I forget if your board has an Aquantia port. If not, you can delete or disable the last 2 patches which are for Aquantia.

46 minutes ago, Ploddles said:

 

Please find attached my full config. I am using the official 0.7.1 release version.

 

 

config.plist.zip 6.31 kB · 0 downloads

I've changed your patches (commenting out your old ones), and re-adjusted all of your Quirks.

Try this one as is (except obviously for PlatformInfo/Generic stuff).

The first 3 patches are the new algrey ones written out for the 3970X with one each for Monterey, Catalina-BS, and the third for HS-Mojave.

config-ploddles-2.plist.zip

3 hours ago, fabiosun said:

no @iGPUit is a 960 pro 1Tb MVME

Mounted on a pciex card as you can see in this bad picture :

I doubt it's a Samsung benefit, but probably related to pciEx card connection. The obvious way to test, is to exchange the Samsung with one of the Sabrent NVMe.

But I wouldn't bother: too much work. I'd just use kext for the internal NVMe drives.

1 hour ago, fabiosun said:

thank you @iGPU

it works also in M-ß3 😉

 

with kext:

 

without kext:

 

 

Nvme in this pictures is on a pciEx card and it is seen by default as Apple SSD Controller

Or Samsung 960 pro is more compatible with apple?

IDK

I think your Samsung is an SSD drive, the others are NVMe. This kext is only needed for NVMe drives.

On a different topic (for those of us still stuck with M-ß1 and old patches...), here is a way to adjust the labelling of the NVMeExpress setting in SystemInfo using a kext file (and then no injection is needed within DeviceProperties).

This kext file was created by apfelnico who posted it here (after his original post here). I've taken liberty in renaming the file (to better describe its function) and adding another section for TRX40 inside the file. You will have to change the settings for your drives; the uploaded file is for my drives and yours are probably different.

[But truly it is not dependent on the mobo, but rather simply on which NVMe drives are in your system as shown below. This means that the "X299" section can be deleted and also means that the "TRX40" section title I made, can be renamed to something else like "NVMeDrives". In fact, this is exactly what I did in the update to the uploaded file: the image of the Info.plist section that says "TRX40" now is "NVMeDrives".]

Basically, this kext injects your NVMe drive data so that Apple recognizes it as being an Apple SSD Controller rather than a Generic Controller. This is probably mostly cosmetic, but under the hood, who knows if Apple doesn't treat the controller differently?

Before using the kext (note "Generic SSD Controller" in spoiler):

After using the kext, now "Generic" is changed to "Apple SSD Controller":

How to use NVMeControllerFix

1) To adjust, open the kext and edit the Info.plist file (see Spoiler below):

2) After following steps in above Spoiler, you'll want to edit the IOPCIPrimaryMatch section with data collected using HackCheck.

Specifically, using the pop-up shown in the leftmost red box, rotate among your NVMe drives, copying the Device-id and Vendor-id to the IOPCIPrimaryMatch section inside of the Info.plist file. The data is entered as "0x[Device-id][Vendor-id]" (eg, 0x50181987 in the example) with spaces between each NVMe drive in your system.

HackCheck:                                                                                                                                             Info.plist:

3) Save the Info.plist file and add this kext file to your Config/Kernel/Add section.

NVMeControllerFix.kext.zip

5 hours ago, fabiosun said:

Clover Patches useful to boot with Big Sur 11.4,11.5 beta 5, 12.x (x=1 and 2) 🙂

 

 

Opencore Patches useful to boot with Big Sur 11.4,11.5 beta 5, 12.x (x=1 and 2)

 

list of patches I use in above pictures:

 

new_Algrey Force cpuid_cores_per_package (unreleased in latest form tested today, you can use patch available for now)

algrey _cpuid_set_info (unreleased)

Goldfish64 - Bypass GenuineIntel check panic - 12.0

algrey - _commpage_populate - Remove rdmsr - 10.13/10.14/10.15/11.0/12.0

algrey - _cpuid_set_cache_info - Set cpuid to 0x8000001D instead 4 - 10.13/10.14/10.15/11.0/12.0

algrey - _cpuid_set_generic_info - Remove wrmsr - 10.13/10.14/10.15/11.0/12.0

algrey - _cpuid_set_generic_info - Set flag=1 - 10.13/10.14/10.15/11.0/12.0

algrey - Remove Penryn check to execute default case - 10.13/10.15/11.0/12.0

algrey - Get DID and VID from MSR - 10.13/10.14/10.15/11.0/12.0

algrey - _cpuid_set_info - GenuineIntel to AuthenticAMD - 10.13/10.14/10.15/11.0/12.0

algrey - _i386_init - Remove rdmsr (x3) - 10.13/10.14/10.15/11.0/12.0

XLNC - Remove version check and panic - 10.15/11.0/12.0

 

this patches:

 

algrey - Remove Penryn check to execute default case - 10.13/10.15/11.0/12.0

algrey - Get DID and VID from MSR - 10.13/10.14/10.15/11.0/12.0

 

they are not useful if you use a bootloader with ProvideCurrentCpuInfo quirk capability.

 

Today I have helped algrey to test his Force cpuid_cores_per_package with also older system like 10.13.6.

It is working quite well!

So maybe, in few time , patches will be updated

 

Personally, my goal was reached by now!

always thank to @algrey for his time and skill! 🙂

 

I was planning on not writing anything more about patches, but with Ploddles having problems and your repeating a patch list that I think none of us can presently boot with, I felt compelled to write. While I can speak only for myself, and possibly Ploddles, those of us not having access to "algrey _cpuid_set_info (unreleased)" cannot boot into Big Sur or Monterey ß1 with your patch list unless the following are also added:

A. Big Sur

1. algrey - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN - 10.13, 10.14, 10.15, 11-11.3
2. DhinakG - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN - 11.3b1 (11.4-12)

B. Monterey ß1 (plus A2 above)

1. Goldfish64 - Bypass GenuineIntel check panic - 12
2. XLNC - jmp to calculations and set cpuid_cores_per_package - 12
3. XLNC - cores and threads calculations #1 - 12
4. XLNC - cores and threads calculations #2 - 12

Perhaps the unreleased patch you reference can replace these extra patches, but presently without this unavailable patch, I cannot boot without the above two sets added to the other patches you've listed (whether or not Above 4G is enabled).

Since there is currently so many patch changes and associated confusion, I've removed all of my recent posts about patches (they're now blank, since I could not delete them). Those posts are pointless with the constant changes and secrecy, and will only serve to further misdirect current or future readers.

1 hour ago, Ploddles said:

 

I get this (BS and Monterey) without the revcpu or revcpuname entries as per your spoiler, so I am assuming it must be reading it from the BIOS.

 

 

Are  you using the RestrictEvents kext?

And what value are you using for PlatformInfo/Generic/ProcessorType?

3 hours ago, Ploddles said:

Anyone tested the new patches with Big Sur 11.5 Beta 5?

 

Not that I am expecting any changes now in the latest beta released today so they should be fine. This will probably be the last update, bar any further security updates, to Big Sur before we move on to Monterey.

This update went fine with new patches (using the minimal ones I uploaded last night).

RestrictEvents injects the Processor info shown below in the "About This Mac" window (with code in Spoiler).

18 hours ago, fabiosun said:

Attached patches for 11.4,11.5b4 and 12 b1

One patch is needed to install and boot Monterey Beta 2 and for now it is not public.

 

thanks to Algrey for  patch 0 which allows to bypass many of previous and mandatory patches

 

 

patch 0 that algrey posted on Insanely Mac is made for my processor in this example

it is very easy to recreate it for other types of cpu:

 

PatchProvideCurrentCpuInfo set cpuid_cores_per_package

f:4489EAC1 EA1A

r:BA1F0000 0090

PAY ATTENTION

Value 1F means 31, 3970 x has 32 cores so as stated by @algrey on IM

32 -1=31=1F

IE for a 8 cores  CPU :

8-1=7=07

for 3950x or 5950x 16:

16-1=15=0F

and so on

 

Patch # 1 will be released when the editors of the patches will decide to make it public!

 

Thanks again @algrey for his usual availability and skill

in this plist latest two are for Aquantia Ethernet

 

 

PAtches.plist.zip 1.68 kB · 6 downloads

@fabiosun

We need to see how this formula will hold up for those using a 3990 CPU which has more cores than macOS software supports. It might not have a searchable result (64-1 --> 3F). This patch might have a limitation on CPUs with too many cores.

Use: 

f:4489EAC1 EA1A

r:BA3F0000 0090

and see what error code is created even if it does not boot.

1 hour ago, Ploddles said:

I have updated to OC 0.7.1 and added new patches for Monterey. I seem to need a few more patches than the rest of you to be able to install and boot Monterey, but I still need to try a few more combinations of the patches to minimise the extra ones I am using. I will post my EFI once I have narrowed it down a bit.

 

Nice to see that the Threadripper Processor is still being automatically identified in System Info, but Bluetooth isn't working as yet.

 

 

I have WiFi/BT AIC working, including Airdrop (as I described here) in Monterey ß1.

See the Kernel/Add section in the EFI I uploaded for what needs to be on/off and for which macOS. If you are using an AIC for BT, you must inactivate the internal AX200 or you will have a conflict (I've commented on this several times in the past few posts; follow the links).

However, if you're using the internal AX200, a different scheme is needed and Airdrop is not presently supported.

13 hours ago, fabiosun said:

added in OP Opencore 071 EFI for my rig (for 11.4.x and 11.5.x) I am using by now Clover 5137 to boot in Monterey B1

It uses @iGPUreduced set of Kernel patches and some quirk adjustment for it (RebuildAppleMemoryMap and others)

I've downloaded and can boot without problem into Big Sur. 

I did change MmioWhitelist and PlatformInfo/Generic for my mobo. All other settings are the same. I later added SmallTree to get my I211 port active.

Only problem is that AMD-SMC kext won't work, so I cannot yet monitor temps.   Kext is loading as shown when running "Kextstat | grep -v com.apple" in Terminal. I'll work on shortly.

I copied AMDRyzenCPUPowerManagement.kext from one of my backups into the kext folder, over-writing the one in your folder and now it works. Strange.

***

BTW, I'm also using HackCheck. It's really nice software. Hats off to gengik84!

***

Another finding is that I have no Airdrop with your EFI (no complaints, just describing for others ); this is because there are no Broadcom kexts nor DevProp injections which help on my setup. Also, there is no SSDT to remove XHC/HS05 USB power from the Internal AX200 which then leads to interference with the Broadcom AIC.

Once I rebooted with a custom SSDT (7-SSDT-TRX40-USB-Rename-NoIntelBT.aml), provided in the previously posted EFI, Airdrop is working. This can be verified by using HackCheck: on the USB tab, you can see how there is no HS05 (part of the renamed, thru the SSDT, XHC device) because it was simply not declared in the SSDT. Easy.

In the same EFI posted above, there is also an alternative SSDT (8-SSDT-TRX40-USB-Rename-WithIntelBT) that does declare HS05 for those wanting to use the internal AX200. (Note that your mobo might require that the USB devices be changed a bit; if an IORE is posted, I can help adjust for you.)

Temporary attachment EFI v070 for testing by fabiosun (of no interest to anyone else). 

59 minutes ago, fabiosun said:

A spike of 63 degrees when system is doing nothing for me it is no good

the sense of the test I was asking is to see if also for other users with that Efi is possible to have a temperatures reduction as I see of 10 degrees and more.

then we can also  discute about mat or what it is correct for an Apple system with an unsupported thread ripper Cpu
 

Small spike seems of no concern to me. I do not have AIC water cooler for CPU, so maybe worse transients in my case.

But even when I tested on other Intel systems in past with AIC water coolers, temps were always jumping up and down based on what's happening. I'm not convinced of overall accuracy and steady states of these values. I take them as relative values looking for significant over-heating problems, mainly during the initial build or for build changes. Aside from that I don't use or run the kexts (more overhead, no?).

In BIOS, I have fans set to kick up based on temps. So if the fans are quiet, I know the temps are not bad and I get on with using the computer. If the fans were to stay at full throttle, then temps are elevated and I'd need to investigate. (I've never had this happen to date.) Fans average out the small blips in the temp readings. I do not hear fan surges, accompanying those spikes I posted earlier.

Attached to this post is an EFI that seems to boot into Big Sur and Monterey ß1 on the TRX40 without too much difficulty, using the minimal patch list from recent post. Comments are made on most problematic sections of OC in several Spoilers below. This is the Debug version of OC v071 (be2d9fe) from 5 July.

By "too much difficulty", I mean that occasionally, the AMD-SMC kext prevents a boot. As I've mentioned, unless absolutely necessary, I keep it disabled. The developer has not specifically written it for the TRX40 platform, nor updated it recently.

1. ACPI (Internal HS05 power for USB/BT; also see Update at bottom)

2. Booter - DevProperties Sections

3. Kernel

4. MIsc and NVRAM

5. PlatformInfo

6. Validation a config plist file:

*****

UPDATE (22 July 2021):

This is an expansion on how to cancel the internal AX200 WiFi/BT module discussed above in the ACPI section. For more discussion on the WiFi/BT issue and AirDrop, see this post (p 93).

After removing HS05, while the internal AX200 has its BT disabled (after removing its USB power), the WiFi portion at BYS4 is still active (although somewhat broken) as shown below:

To completely remove the device, another SSDT is required, 9-SSDT-TRX40-OFF-AX200.aml (the code is shown in Spoiler below and the file added as another attachment).

DefinitionBlock ("", "SSDT", 1, "APPLE ", "NoWLAN", 0x00001000)
{
    External (_SB_.S0D2.D2A0.BYUP.BYD4, DeviceObj)
    External (_SB_.S0D2.D2A0.BYUP.BYD4.BYS4, DeviceObj)

    Scope (_SB.S0D2.D2A0.BYUP.BYD4.BYS4)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If (!Arg2)
            {
                Return (Buffer (One)
                {
                     0x03                                             // .
                })
            }

            Return (Package (0x06)
            {
                "class-code", 
                Buffer (0x04)
                {
                     0xFF, 0xFF, 0xFF, 0xFF                           // ....
                }, 

                "vendor-id", 
                Buffer (0x04)
                {
                     0xFF, 0xFF, 0x00, 0x00                           // ....
                }, 

                "device-id", 
                Buffer (0x04)
                {
                     0xFF, 0xFF, 0x00, 0x00                           // ....
                }
            })
        }
    }
}

After rebooting with this SSDT enabled, the following is seen. Now there is no device at BYS4 and the power is removed at HS05.

Note that this discussion is based on the internal AX200 being located at BYS4. Check IORE to see if your device is at a different location. If it is, you'll need to accordingly modify the SSDT files.

EFI.zip

9-SSDT-TRX40-OFF-AX200.aml.zip

On 7/4/2021 at 10:42 AM, fabiosun said:

@iGPUEFI you have downloade is only till Big Sur beta 4 so you have to leave "my" patches and try with your BS 11.5 beta 4

.

I think temperatures are too elevate and for now I do not know why

I can use your EFi without touching nothing

obviously I miss a couple of MMIO if I do in that way but system starts and works..

For now I can't have a system as I like if I include new Monterey b1 patches...

if you use your patches in my 070 EFi couldn't work because you disable two patches as we said and you discovered  yesterday and without them I need of RebuilAppleMemoryMap quirk ..to see if your system boots you should only change your MMIO and maybe something with WEG I do not use as kext and either as bootlargs..but it is only a my curiosity to see also for you some degrees less happen

 

to summarise with a 13 patches combination my system needs RebuilAppleMemoryMap that usually I do not use)

if you put your complete set of patches in my 070 EFi you have to enable that quirk..and to gain some degrees also DisableIOMapper..

but my goal is always to reduce stuff 🙂

 

I'm not understanding why not using RebuilAppleMemoryMap is reducing anything; it just seems like we use one Quirk or another.

The OC docs discuss MAT:

In the error log created when booting OC Debug, search for "MAT" and you'll find that MAT = 1, meaning our mobos support MAT:

Therefore, it would seem that Booter/Quirks, based on MAT, can be set as:

*******

UPDATE:

With multiple, very slow boots into Monterey ß1, I remembered on InsanelyMac some users on the Intel side commenting that turning on 'auto login' reduces boot time. It does. (This is most likely just early beta hiccups.)

Enable it by going into Users & Groups as shown below:

21 minutes ago, fabiosun said:

@iGPUi have 10 ° in all 3 system I can boot, my results in temperature are similar to yours

With previous EFI posted in this thread  I have had 10° less

I am investigating this  (not happy for this I mean)

 

I didn't do an accurate testing (sorry) because I am trying to have patches working also for Clover Bootloader and a X570 system 

confirmed your update about AMD PowerGadget

 

to explain better this assertion 🙂

I usually do not use RebuildAppleMemoryMap quirk

and without two patches I have a pretty instant reboot

Bios and hardware settings are not involved in my opinion

 

@fabiosun

I just finished test booting your EFI v070 from 1st post on this thread. I only substituted my patches (your have 15; mine 18) and my mono-specific MmioWhitelist; otherwise all is from your EFI folder (no updated kexts, etc). When I did this, I could not boot into either Big Sur or Monterey.

I think this is due to other settings within OC and has nothing to do with v070 vs v071. My OC settings also include various ACPI and DevProp injections, which, while I understand many here don't like them, I think they help the functionality of Hackintoshes.

I'll work on a sampled EFI and attach to this post in a few minutes...