iGPU

1 hour ago, valmeida said:

@fabiosun@igpu

I have had succes installing Monteray . I pin pointed the issue was my Samsung Odyssey G9 49 inch monitor. I have tried a couple of different options with my config .plist one with Whatevergreen turn on and one with just 6900ssdt turned on. When I boot with with motor connect with WEG it reboots with SSDT I get a black screen. If I boot without the monitor plugged in it boots fine with either WEG or SSDT. I can then plug it in and it seat it and starts to work. I have noticed that with Big Sur and ssdt it have no issues with WEG sometimes It down not recognize one of my monitors. Also I have no ethernet ports with Monterey. I have attached both config list .  

Archive.zip 12.94 kB · 4 downloads

I looked at your mobo specs. You have one I211 port. We've discussed this at length on this thread: it does not work on Monterey. So for the time being: ignore this port. However, your other port is an Aquantia and should work. I already gave you the patches for both Big Sur and Monterey. Please re-read what we've previously written for using Aquantia: the patches are different for Big Sur and Monterey and were recently posted on this thread.

4 hours ago, Jaidy said:

Is there someone who’ve experimented hackintoshing on a TR pro platform? Or know of any?

I'm unaware of any Pro Hackintoshes. Here is a good overview of the feature set between Threadripper, Threadripper Pro and EPYC.

The price point for the Pro 3975X is not too much more than the 3970X most of us are using, at $2790 (there is a typo in the 32-Core table where they say the 3970X costs $3990; the MSRP is $1999). However, the price point for the Pro 3995WX over the 3990X is significantly more: $5490 vs $3990.

This price difference doesn't reflect the need for a new mobo since the socket is different for the new Pro models (so there's no swapping of the CPUs for a quick test). And then there's the ECC memory (in the referenced review, read the Comments section, users have found that the number of used DIMM slots affect performance and explain why).

In terms of performance, both use Zen 2 and little advantage was found except in memory performance. My guess is that except for the 3995WX (which uses 4 chiplets), the other Pro versions will have little improvement over our current CPUs in a Hackintosh. The next generation of Threadripper using Zen 3 will probably be a different story; they're supposedly due to arrive later this year.

3 hours ago, fabiosun said:

@Arrakisin that thread they talk about BigSur

And they say it works in it only put that kext and declaring it in your Kext config plist section (Kernel/add)

and to do an example..this below:

 

<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>BundlePath</key>
				<string>AMDRyzenCPUPowerManagement.kext</string>
				<key>Comment</key>
				<string>AMD Power Gadget</string>
				<key>Enabled</key>
				<true/>
				<key>ExecutablePath</key>
				<string>Contents/MacOS/AMDRyzenCPUPowerManagement</string>
				<key>MaxKernel</key>
				<string></string>
				<key>MinKernel</key>
				<string></string>
				<key>PlistPath</key>
				<string>Contents/Info.plist</string>
			</dict>

 

is equal to:

 

so for you, and overall in Monterey it is not useful because is the same method you used in Big Sur (and if I understand well now in MR is not working)

 

PS I use another kext but logic is the same

 

 

@valmeidaI think  is an "user" error 🙂

But I have no more ideas to try by now

 

My reading of the above referenced thread is the same as fabiosun's understanding: they were not patching the kext from OC, but instead are 'patching' (editing) the info.plist and then injecting this kext (info.plist) from OC.

There is something different about how Monterey, compared to all previous macOS releases, handles ethernet ports. Once this difference is sorted out, I'm sure all again be functional.

(BTW, editing this kext to add 0x15398086 did not work for the I211 port...)

5 hours ago, valmeida said:

I now able to boot  Big Sur  from IGPU EFI he sent me last nite by enabling   ssdt-EC and 3-SSDT-6900xt.aml. I will try to boot Monteray and will let you know . 

EFI.zip 6.27 MB · 6 downloads

The SSDT-6900XT is only useful if not using WEG. For months, I have used BS and now Monterey using only WEG and no SSDT file (for RX580, Vega56, Radeon VII and now 6900XT). Such SSDT files are not necessary for a boot if using WEG.

And even if not using WEG, while the SSDT is helpful in re-naming the GPU devices as seen in IORE, the computer will still boot without it. I done this many time on both Intel and AMD platforms.

If one wants to inject certain properties (like control the fan and GPU speed), these can be injected via an SSDT or injected by using DevProp section. The SSDT method is best, especially if one also wants to re-name devices.

Portion of SSDT code to rename GPU devices. That is, how it's done: bridge after DODF becomes EGP0 and next bridge becomes GFX0:

Result after above SSDT re-name as seen in IORE:

Result after re-name by WEG. The first bridge is not re-named, but this is only cosmetic and seems to have no impact on GPU functionality.

(Note: for those paying attention, this IORE taken from a different mobo than the above example, so the D0BF device is here D0C1, which would mean that the SSDT shown above would not work for this mobo unless changed, and it is for a different GPU and that portion should be changed as well.)

2 hours ago, Ploddles said:

@fabiosun What does the 3-SSDT-6900xt.aml do for us? I've seen it mentioned a few times but haven't seen any explanation as to what it does. Thanks.

 

It simply injects data for GPU and re-names devices. It is only useful if not using WEG.

If using WEG, it is un-necessary, which is why I disabled it for @valmeida

2 hours ago, valmeida said:

I really do and appreciate all your help and support. 

I did have a back up  the config I was  just trying out different things . I will  follow your istratuctions  based on the EFI you sent me  I can not boot with Big Sur or Monterey I this is  the error I get.  I ran IOREG from terminal and saved it and is attached. 

Terminal Saved Output.zip 9.5 kB · 1 download

Terminal?

No, IORE:

Maybe you have a corrupted BIOS. I would re-flash latest version and then go over settings with fabiosun.

But before flashing the BIOS, try re-setting NVRAM from the OC boot menu (press space bar when menu is up and scroll to left). You have your menu set for 10 sec (I don't use timed log in; but I left your settings), so you need to press a key before it auto boots after 10 sec.

(With all respect to fabiosun, I don't think a lack of an SSDT-EC file is the cause of boot failure. In fact, a re-naming of an EC device can lead to system instability.)

3 hours ago, valmeida said:

 I  looked at IGPU threads and recommendations and still can not boot  Ito Monteray. I can boot into Big Sur fine and everything is working. Have attached my current EFI and IORE Any help would be greatly appreciated . 

IORegistryExplorer.app.zip 226.14 kB · 1 download EFI.zip 15.3 MB · 2 downloads

Carefully read what I write. I'm usually concise and reasonably accurate. There are 2 sections I cannot check: MmioWhitelist and your ethernet kext. If ethernet is working then the kext is probably fine. If you can boot into Big Sur, the MmioWhiltelist is probably fine too.

*****

First off, the IORE you uploaded is an app, not your IORE file. Run IORE and do a "save as" and upload that file.

Second, you extensively changed the config.plist file I spent more than an hour fixing last time. I again spent over an hour today re-re-fixing your config file.

Do NOT change anything in this config file until fabiosun or I have gotten feedback from you. If you continue to fiddle with the config file (with apparently no understanding), you waste all of our time. For example, you'd completely replaced the Kernel/Patch section, so I had to carefully re-check each entry as the order was different and I had no idea what you'd done.

I've re-done the SSDT section and supplied new files. Nothing there, as is, will prevent booting. Do not change it. We can refine later (with WEG active, no GPU SSDT is required).

I've also removed your fancy log-in icons. It is back to basics. Leave this stuff alone while we are trouble shooting. After everything is booting properly, you're on your own with icons and change to your heart's content. But not before.

Some of the problems:

After fixing most of problems, I ran the ocvalidate and still had 40 errors that you'd introduced:

And the tool section was not what I uploaded to you (this section alone gave 40 errors). Don't change this section; you'll never use it.

The most unbelievable change you'd made was in the DevProp section as partially shown in Spoiler below (my monitor is not large enough to show it all in one shot). I'm surprised anything booted. It's now done to 1 (one).

EFI-valmeida-2.zip

2 hours ago, valmeida said:

I was able to boot with Big Sure but no Ethernet from the 1 gig or 10 gig Aquatina . I also tried Monterey was able to install it but I get a black screen  one it finishes booting up.

I copied my Mmiowhite list

I did not know you had Aquantia (I checked and you did not have them in the config file you uploaded, so I left out). You need to add the following to Patches:

<dict>
				<key>Arch</key>
				<string>Any</string>
				<key>Base</key>
				<string>__ZN27AppleEthernetAquantiaAqtion5startEP9IOService</string>
				<key>Comment</key>
				<string>Aquantia Big Sur</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				D4TAAgAA
				</data>
				<key>Identifier</key>
				<string>com.apple.driver.AppleEthernetAquantiaAqtion</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>20.99.99</string>
				<key>MinKernel</key>
				<string>19.00.00</string>
				<key>Replace</key>
				<data>
				Zg8fRAAA
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>
			<dict>
				<key>Arch</key>
				<string>Any</string>
				<key>Base</key>
				<string>__ZN27AppleEthernetAquantiaAqtion5startEP9IOService</string>
				<key>Comment</key>
				<string>Aquantia Monterey</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				QcdFAAAAAADp
				</data>
				<key>Identifier</key>
				<string>com.apple.driver.AppleEthernetAquantiaAqtion</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>21.99.99</string>
				<key>MinKernel</key>
				<string>21.0.0</string>
				<key>Replace</key>
				<data>
				QcdFAAEAAADp
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

As for black screen, enable WEG and add agdpmod=pikera  to boot argument in "csr-active-config".

39 minutes ago, valmeida said:

I tried it and  this is what I get when booting to Big Sur 

Are you booting from Sabrent drive or Samsung? Best to use Sabrent. Also disable NVMeFix kext for a test.

I also did not check your Mmiowhite list, keeping it the same as we have different mobos. Double check it.

On 8/12/2021 at 4:37 PM, valmeida said:

I'm trying to update my EFI so that in can boot to Big Sur and Install Monetay. Im getting this error when booting to BigSur.

EFI.zip 14.73 MB · 0 downloads

The error msgs are probably due to out of date kext files.

As for the EFI, there are many errors in your config file when trying to run ocvalidate, which could also contribute to the error msgs. I've fixed all errors and updated to OC v073.

I've updated whole EFI, including kexts. I removed several items and inactivated some; changed patches, used different SSDT files, and re-vamped the NVRAM section.

Also what exact BT/Wifi are you using? It's not clear what you're using; you had an odd mix of BT files which made no sense to me. I inactivated for now; you should not need BT/Wifi to boot (unless you only have BT mouse, but for trouble shooting, I only recommend wired mouse & KB). I've found that Monterey works with AIC without any kexts (but this depends on AIC, etc).

Attempt to boot as is without changing anything in EFI. If this boots (and it should work with either Big Sur or Monterey), post an IORE file and I can possibly customize the USB devices with an SSDT.

EFI-valmeida-update.zip

I too updated to ß5 without any problems.

52 minutes ago, fabiosun said:

 

I agree with a lot of what you write, on the last part I just ask myself more questions:

 

1) what has changed in the app and in the kext to be now necessary to activate that quirk (which is quite important regarding power management)?

2) an old question of mine was the correlation between that quirk, the bios versions (MSR) and the patches we have to use..but I couldn't find an answer

 

However, on this platform the story is still to be written and in part we have all contributed to making some parts clearer.

 

I also have another question / curiosity

Why does the activation of the dummypower management quirk seem unnecessary here?

 

I try to explain better, under what conditions the use or not of a kernel patches that seems "unnecessary" to start the system or a quirk like the one mentioned could create a problem, but maybe by activating a simple autologin you can make malfunctioning a system that was basically stable?

As to why the DummyPowerManagement quirk might be important:

The developer asked me to look at the Kernel panic log when the computer froze. I did so and found the following (Spoiler; small extract from end of panic log).

MC4yLjAuMSkgICAgICAgICAgICAgICAgPERBMEVBREQyLTc4QUMtMzkxRS05QTYyLUYyQkNCRTM3QjQyRT4gIC9TeXN0ZW0vTGlicmFyeS9FeHRlbnNpb25zL3B0aHJlYWQua2V4dC9Db250ZW50cy9NYWNPUy9wdGhyZWFkCg==","notes":"Stackshot source : disk","macOSPanicString":"panic(cpu 0 caller 0xffffff801821efa7): CPU 63 has no HPET assigned to it\nPanicked task 0xffffff8829fef6a0: 296 threads: pid 0: kernel_task\nBacktrace (CPU 0), panicked thread: 0xffffff882a5816e0, Frame : Return Address\n0xffffffd1d514bc70 : 0xffffff8016ca34fd \n0xffffffd1d514bcc0 : 0xffffff8016dfcc35 \n0xffffffd1d514bd00 : 0xffffff8016dec603 \n0xffffffd1d514bd50 : 0xffffff8016c42a60 \n0xffffffd1d514bd70 : 0xffffff8016ca38cd \n0xffffffd1d514be90 : 0xffffff8016ca3086 \n0xffffffd1d514bef0 : 0xffffff8017519aa9 \n0xffffffd1d514bf60 : 0xffffff801821efa7 \n0xffffffd1d514bfa0 : 0xffffff8016c4218e \n      Kernel Extensions in backtrace:\n         com.apple.driver.AppleIntelCPUPowerManagement(222.0)[C976299C-7A0C-3F2C-8A3A-524D89DEF7C6]@0xffffff8018219000->0xffffff8018235fff\n\nProcess name corresponding to current thread (0xffffff882a5816e0): kernel_task\nBoot args: agdpmod=pikera \n\nMac OS version:\n21A5294g\n\nKernel version:\nDarwin Kernel Version 21.0.0: Thu Jul 22 19:52:31 PDT 2021; root:xnu-8019.0.72.141.3~2\/RELEASE_X86_64\nKernel UUID: 43AA07BC-5319-3B90-A977-9050C6C2F8D7\nKernelCache slide: 0x0000000016a00000\nKernelCache base:  0xffffff8016c00000\nKernel slide:      0x0000000016a10000\nKernel text base:  0xffffff8016c10000\n__HIB  text base: 0xffffff8016b00000\nSystem model name: MacPro7,1 (Mac-27AD2F918AE68F61)\nSystem shutdown begun: NO\nPanic diags file unavailable, panic occurred prior to initialization\nHibernation exit count: 0\n\nSystem uptime in nanoseconds: 90982254187\nLast Sleep:           absolute           base_tsc          base_nano\n  Uptime  : 0x000000152ef70980\n  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000\n  Wake    : 0x0000000000000000 0x0000002478dab456 0x0000000000000000\n\n\n"}

To highlight the important part:

 "Kernel Extensions in backtrace:\n com.apple.driver.AppleIntelCPUPowerManagement (222.0)[C976299C-7A0C-3F2C-8A3A-524D89DEF7C6]@0xffffff8018219000->0xffffff8018235fff\n\nProcess name corresponding to current thread (0xffffff882a5816e0)".

He suggested that the problem with the freeze was probably due to macOS's Intel PM (power management), which would require the DummyPowerManagement quirk to be enabled to fix the kernel panic. I tried this and found that by enabling this quirk, the crash (kernel panic) stopped.

8 hours ago, fabiosun said:

Mmmh you know my way to think about not mandatory stuff..

I am trying automatic load of amd power gadget and I have no problem

i have to check  if I have enabled dummy power management 

usually I have not enabled it so I think no

For x570 is mandatory and also for @Ploddles and @Arrakisi think

but if I have understood well

arrakis has some hangs with new app..

I will try tomorrow menu disappearing bug

but I think I have not that problem🤞

@iGPU

by the way

this week I will receive icegiant elite cooler..

I hope it will better or similar of my actual AIO

 

 

I do not view recommended settings as mandatory, but beneficial. That is, I view recommended settings as a way of allowing most users to have the most trouble-free functionality as possible: the basic common denominator (so to speak) for all. 

It's like learning to drive a car: there are many steps and rules that are not always obvious at the start, but end up benefiting most people, allowing for an overall enjoyable experience. Those who later wish to race cars or do stunt tricks will abandon those basic rules, stretching the limits by acquiring more more esoteric knowledge.

Similarly, if we can get a generalized config file that is useful to as many users as possible, giving them an easy, enjoyable experience, then we've accomplished something good for most TRX40 users.

So far, the only unique settings, aside from AIC and specialized SSDT files, are the MmioWhitelist (which is unique for each mobo/manufacturer, and even those have much in common with each other) and Memory configurations (which also can be simplified into 2 or 3 basic settings). Later, those who wish to streamline their config files, can trim the config file, and erase portions, to their heart's content.

Using the DummyPowerManagement as an example, while I don't need this Quirk to boot, it now seems to allow me to use the AMDPG app whenever I wish, without having the computer freeze up. Meanwhile, GB mobo owners do need this Quirk. So why not include it as part of a basic, recommended config file for TRX40 users?  

On 8/9/2021 at 7:56 AM, fabiosun said:

@iGPU

 

I have enabled it to test..I rebooted

but app does not start in automatic , and to have it running I have to launch via usual icon

..so another bug here

I can't see in location you said any AMDSPinach plist

so maybe other problem here..

I am testing in Monterey b4

 

EDIT:

SIP Enabled here

 

 

EDIT2:

with sip disabled it starts automatically 

Let see if it hangs 

 

EDIT3:

Does not hang here and  I can see option to disable automatic app running

 

 

In discussion with the developer, the freezing (hang) problem is solved by simply enabling the DummyPowerManagement quirk (inside Kernel/Emulate as shown in Spoiler).

I'm now of the opinion that, from now on, we should keep this quirk enabled for all TRX40 mobos. (I don't see any downsides to this view.) 

There are still issues with the AMD Power Gadget (AMDPG) app having the submenus disappear if "statusbarenabled" Is enabled (plist file location shown below). And I see this menu problem whether SIP is enabled or disabled. This bug needs to be fixed.

But at least now there seems to be no further computer lock-ups when using the AMDPG app!

13 hours ago, Arrakis said:

I have the same problem as @iGPUwith the new version SMCAMDPProcessor.kext making my system unstable

and moreover I no longer have the temperature near the CPU in iStat Menus (I use this application because I have GPU temperatures and other constants ...)

I reverted to the previous version. The ExposeSensitiveData value is indeed 8 to recognize my motherboard.

After several more crashes (everything locks up, freezing mouse–––the computer if left alone will re-boot; if impatient, a forced shutdown is required), I think I've isolated the problem...

Each new kext seems okay. I can have a stable computer if one or both are running. I can even run the AMD Power Gadget app and the computer is stable. The problem is if the app has the feature to "Launch in menu bar at login" enabled (StartAtLogin in the plist file discussed below) through it's menu, shown below.

Once this is enabled and the computer re-booted, the menu is no longer accessible to disable and now the computer locks up in less than 60 seconds after each re-boot due to the auto-login feature of the AMD Power Gadget app.

I had to boot into Big Sur (or use another EFI where the AMD Spinach kexts were not enabled) to remove the AMD Spinach plist file. This file is located in the User/Library/Preferences folder as shown below. You can either delete it or better is to edit and set "startAtLogin" to "NO" (and while you're at it, also set "startAtLoginAsked' to "YES" to avoid a pop-up window shown in Spoiler below).

In looking more deeply in the CrashReport log, one can find the following (an excerpt from that log file). I'll provide this info to the developer and maybe they can provide a fix.

The bottom line, in its present state, the AMD Power Gadget system is usable (at least for me), if the Auto-Login feature of the AMD Gadget app is not activated.

ADDENDUM:

I found out through playing with the wtf.spinach.AMD-Power-Gadget.plist file that the menu is inactivated if "StartAtLoginAsked" is enabled and "statusbarenabled" is set to "YES". I'm leaving "statusbarenabled" set to "NO" in order to have access to the AMD Power Gadget app's menu bar.

After writing the above, the system began locking up even if only the AMDRyzenCPUPowerManagement.kext was enabled (and no AMD Power Gadget app was running). This is after a morning of the computer running fine with both kexts enabled but no app running. It was only after enabling auto log-in did all the troubles start once more. Odd. I've presently disabled both kext files and have contacted the developer.

2 hours ago, Rocket88 said:

I had to make a change to my Kernel patches to get ethernet to work under Monterey. I changed MaxKernel to 21.99.99.

Your reminder to update the MaxKernel is a good one, as this step is often over-looked when updating to a new macOS.

However, under Monterey, the problem isn't with Aquantia ethernet ports, but with I210 and I211 ports. These ports seem to be no longer properly responding to the kexts which were working under Big Sur.

I've literally spent a dozen hours or more working on the I211 problem (discussed here and here), and so far have had no success.

3 hours ago, carlo_67 said:

I personally have not found any problems, even changing in Misc / Security / ExposeSensitiveData from 0 to 8, it also detects my motherboard,

 

@fabiosun la mia carretta 🤬

This is interesting. I again tried and had crashes. I thought something might be amiss with Mß4, so I re-installed it through Recovery. Once more, AMD Power tools would crash the computer. I tried disabling various kexts and had no success. I think it is the app that is causing the crashes. I did not see any crashes with the older version from last fall with all things in the config file and BIOS being the same.

I've had ExposeSensitiveData set to 14 for some time (previously having had it set at 3 or 8). I'll give the 8 setting a go.

On 7/30/2021 at 7:54 AM, fabiosun said:

https://github.com/trulyspinach/SMCAMDProcessor/releases/tag/0.7

new version for AMD Power Gadget

@fabiosun ,

I've begun having sudden crashes since using the new AMD Power Gadget (only tested in Monterey ß4).

The computer locks up after about 3 or 4 minutes or will even spontaneously re-boot from the login screen. It happens whether or not SMCAMDProcessor is enabled, so it would seem to be a problem with either AMDRyzenCPUPowerManagement or the Power Gadget app. I did not see this with the older version.

I now have the new kexts disabled and the computer has been stably running for hours, just like before.

Have you noticed any problems?

9 hours ago, tuxy said:

I have been comparing my config 0.7.1 with the one you have posted. I was expecting the new quirks but I could not find it.

BTW I did the comparison by hand so maybe I could miss it but basically I could not find any difference between the two of them.

 

 

@tuxy,

I don't know if you were asking for help with patches for the X570 or not. If you were, then maybe the attached config file for OC v072 will be helpful. It was used to boot a GB Aorus Master X570 into Big Sur 11.5.1 with the latest patches with a 3950X CPU. It was not verified with Monterey or earlier macOSes.

I've removed most custom SSDT references, but please check and adjust the ACPI, DevProp and Kernel/kext sections for your own set up. SNs were removed. Finally, if you are using a different core count from the 3950X, adjust the first 2 patches accordingly.

If you only want the patches, then throw everything else away. 😉

config-X570-v072-basic.plist.zip

11 hours ago, fabiosun said:

Tested in a rush Opencore new Patches!

Work fine

"algrey - _cpuid_set_generic_info - Disable check to allow leaf7 - 10.13/10.14/10.15/11.0/12.0"

as before is not needed to boot..

I have asked if there is some unknown reason to maintain it

As always thanks to the devs and patches maintainers!

 

Besides the leaf7 patch, and ignoring patches specifically for < Big Sur, these 2 have not been required for the TRX40:

9 hours ago, Arrakis said:

 

The config-arrakis-2 step starts Big Sur but I get the same error as the onfig-arrakis-1 step config for the Monterey installation.

 

The config-arrakis-3 step starts Big Sur but very unstable restarts or freezes.

On the other hand, starts the installer Monterey Beta 3 and begins the installation but freezes at various stages. (I tried several times without changing anything)

One other thing to consider from Intel experience, if weird things happen, your BIOS may be corrupted. The solution is to re-flash BIOS, then re-do you settings.

Next, I would literally remove as many things from your computer as possible. Only USB-2 KB/mouse, no other USB connections. Also, look at Energy Saver setting inside System Preferences. I would check Prevent your Mac... and uncheck the others.

Finally, boot into your most recently stable OS (Big Sur 11.4?), let it run for several minutes to see if re-boots or freezes. If okay, then proceed with booting into Monterey on another disk.

This may be of interest to few, but I've updated this post on the TRX40 EFI structure, specifically to show how to completely remove a device through an SSDT file.

[The EFI itself is somewhat out-of-date due to the recent Patch incorporation, but the other sections are still applicable.]

While the earlier post did accurately show how to remove the USB power from the internal AX200 WiFi/BT device, the WiFi portion was still attached at BYS4. Through the use of an SSDT file, the whole device can be completely removed.  These results are shown in the Update, using HackCheck, at the bottom of the post.

2 hours ago, Allubz said:

Slightly off the mainstream topic (12.x booting), I have some random crashes I'm trying to figure out. The system works well, but sometimes, though seemingly randomly, I get a reboot.

 

I attached a screen. It seems to be CPU related, if I look at the listed kexts. But what could cause the random reboots? No over/underclock settings, CPU is at stock in BIOS.

Cheers!

 

PS: Good luck with 12x Monty, all the power to you 🙂

Unrelated to patches and EFIs, reboots on Hakintoshes (both AMD and Intel) can be due to USB problems.

To trouble-shoot, try removing all un-necessary USB devices, including a TB AIC if you're using one. (I've posted on this thread how the TB AIC alone caused reboots.)

5 hours ago, Driftwood said:

Have we got an upgrade from Big Sur to Monterey b3 working yet without having to do fresh. Hope you all well, been busy filming!

I upgraded one drive with Big Sur 11.4 to M-ß3 and the Monterey OS was corrupted (e.g., no ethernet functionality; and who knows what else wasn't working. I had to do a fresh install and then all was working as expected. This is the recommended way even on the Intel side.

After the fresh install, you can do a data migration.

17 hours ago, Arrakis said:

I managed to install the Monterey B1 version from an EFI OpenCore 0.7.1.

 

 

 

Then I tried to boot with Shanne's PR EFI OpenCore 0.7.2 without success.

Even try all eGPU suggestions once again. Here

 

I spent my day trying multiple studies of combinations to no avail. I am stopping there for the moment.

I'm not even talking about attempts to upgrade Monterey B3 which each time breaks the installation of beta B1 and back to square one.😒

3 comments.

1. Remove the TB AIC during all testing.
2. Since not using Shaneee's EFI with internalized Patch  0, did you adjust Patch 0 for your CPU core count, as fabiosun described here?
3. Some Patch 0 variations use core-1, the above link, no "-1"; try both.