Jump to content

fabiosun

Recommended Posts

5 hours ago, iGPU said:

 

Agree with what fabiosun says. Additionally, I'd add that there were reports by KPG (now retired) on his threads that updating the Aquantia driver from Windows will cancel Aquantia from working in macOS. Therefore, seeing no good outcome in testing this belief, I've never updated any Aquantia drivers and the port works just fine in macOS, Linux and Windows.

 

My Aquatina is working  fine on Big Sur 11.5.2 but I can not get it to work on Monterey beta 5.

Screen Shot 2021-08-25 at 3.59.58 PM.png

Link to comment
Share on other sites

On 8/26/2021 at 2:15 AM, fabiosun said:

@valmeida

aquatina?

Are you using renaming or device properties?

could you post a screen shot like this?

 

456851386_Screenshot2021-08-26at08_08_01.png.1b836b4182a157032a691bec2c40b6e4.png

 

1150783354_Screenshot2021-08-26at08_15_02.thumb.png.0b17c2197c684be6389ddd4f1162d4a2.png

 

you can achieve it with HackCheck app or similar application 

Here you go . I renamed it.

Screen Shot 2021-08-27 at 5.30.43 PM.png

Screen Shot 2021-08-27 at 5.29.46 PM.png

Edited by valmeida
Link to comment
Share on other sites

  • Moderators
On 8/28/2021 at 8:42 AM, fabiosun said:

@valmeidaweird

it differs in subvendor and sub device id

but it is weird it works in Big Sur and it doesn't in Monterey

By the way you have DDR4 @3200 in signature but Hack check detect them @3000

 

 

 

The sub-vendor and sub-device IDs are based on the mobo's manufacturer. Therefore, our MSI values will be different from those of ASUS. But no matter, as these ID values will not affect the Kernel patches since they are directly applied to Apple's Aquantia kext file without reference to any ID values.

 

And even with the patches applied, I've added cosmetic changes (that is, not essential) via SSDT or DevProp changes, and the Kernel patches still work in Big Sur and Monterey. (I've already cautioned @valmeida to use no DevProp during the test phase.) If an SSDT is used, the attachment point at device BYS3 could be changed but that should not be important at this point.

 

When I look at @valmeida's IORE, which I believe is from a Big Sur boot, we see the following at BYS3. This looks good. And after a boot into Monterey, it should look exactly the same. Please verify.

 

valmeida-BYS3.thumb.png.8b45cf721ecf9896fa144ef964566884.png

 

 

It is not clear to me why @valmeida's Aquantia patch is working on the ASUS mobo in Big Sur, but not working in Monterey. The fact that the port is seen in HackCheck would suggest that the patch is being injected.

 

However, to verify this change, turn off the Aquantia Kernel patch for Monterey in the OC config file. After re-booting, the Aquantia port should not longer be visible in HackCheck.

 

 

To summarize, @valmeida do two things I've written above. Both will be answered in 2 boots (one with the Monterey Aquantia port enabled and one boot with this same patch disabled):

 

1. look at the BYS3 section in IORE after a Monterey boot with and without the Monterey Aquantia patch being enabled.

2. look at HackCheck's Network section, again after a Monterey boot with and without the Monterey Aquantia patch being enabled.

 

*****

 

SPOILER: What I see on my MSI Creator mobo for Aquantia and I211 ports in IORE and HackCheck. While SmallTree is being properly injected, the port is still not active even under Mß6:

 

Spoiler

IORE:

1772609726_M6-Ethernetports.thumb.png.a7491a069126b23dbc36e010faec0592.png

 

HackCheck:

733447263_ScreenShot2021-09-01at8_47_45AM.thumb.png.15d4b3268ffe180bcc96e3dac61309b6.png

 

 

Edited by iGPU
added MSI Creator IORE ethernet section
  • +1 1
Link to comment
Share on other sites

  • Supervisor

700903473_Screenshot2021-08-31at12_46_48.png.f9ba7c7c9f10a12f1f8072460f498cff.png

if you do not see this update put j160 in SecureBootModel in your config if you use MacPro7.1 SMBIOS

 

some problem to update in my case yet

 

 

536834832_Schermata2021-08-31alle11_37_46.png.b27938ff6067f9742271a980bf9cd4bf.png.880ebe8fa61abbffd85670aaf6a41d72.png

Edited by fabiosun
solved
Link to comment
Share on other sites

  • Supervisor

To update to Beta 6 (if you do not see it in update)

If you have MacPro7.1 Smbios, and default or Disabled in Misc/security/SecureBootModel

put in Misc/security/SecureBootModel j160 value

reboot

You will find an update message on software update

download it..DO NOT REBOOT

before reboot change secureBootModel in Disabled

then reboot

And it should then update as usual

 

1943175418_Screenshot2021-08-31at13_45_03.thumb.png.ee5066b2ba500d4d7b20bd066e976736.png

 

  • Like 1
  • Thanks 1
  • Ok 1
Link to comment
Share on other sites

  • Moderators
On 8/31/2021 at 4:22 AM, fabiosun said:

To update to Beta 6 (if you do not see it in update)

If you have MacPro7.1 Smbios, and default or Disabled in Misc/security/SecureBootModel

put in Misc/security/SecureBootModel j160 value

reboot

You will find an update message on software update

download it..DO NOT REBOOT

before reboot change secureBootModel in Disabled

then reboot

And it should then update as usual

 

1943175418_Screenshot2021-08-31at13_45_03.thumb.png.ee5066b2ba500d4d7b20bd066e976736.png

 

 

Completely agree with your findings: when SecureBootModel set to "Disabled" (the usual setting in my config file), the Mß6 update was not offered. Once this setting was changed to "j160" for my SMBIOS (MacPro7,1), and the computer was re-booted, the Mß6 Update became visible. (SecureBootModel was then re-set to "Disabled" before running the Update so that re-boots during the update would be run under "Disabled" and not "j160".)

 

678214037_M6Update.thumb.png.10bb9b0b2a8e284496a5f839b5ca2bf0.png

 

The curious thing is that previous Updates in Big Sur and Monterey were not visible unless SecureBootModel was set to "Disabled" (and csr-active-config set to "00000000"; this setting was unchanged for the Mß6 update). In fact, early on when the SecureBootModel quirk was introduced, I had trouble even booting into macOS if SecureBootModel was anything but "Disabled".

 

 

  • Like 2
Link to comment
Share on other sites

  • Moderators

FYI for new updates coming with OC v073. The latest commits change the structure of OC's driver section as shown below.

 

The OC documentation discusses the changes as seen in the comments inside the ChangeLog file. The changes also include a new driver (OpenLinuxBoot; only needed if booting from OC into Linux):

 

OC-v073-LinuxBoot.png.85fa375d5977043e29be0aedc19176b6.png

 

OC-v073-ChangeLog.thumb.png.020447205a75b7de5e9ae330cf5b73ea.png

 

 

The changes to the config file are shown next.

 

These changes sub-divide the string driver list into an array with 3 parts each. One part is to allow arguments for each driver, the 2nd part is to enable or disable the driver (instead of using a "#" symbol to disable), and the 3rd part is for the driver name (with path if not in the expected Drivers folder).

 

OC-v073-Drivers-Update.thumb.png.b2291163d08b75286c51655e2a407d15.png

 

 

  • Like 2
  • +1 1
Link to comment
Share on other sites

Amazing work guys, a bit quit from my side lately but all is well.

 

Have been reading along with the new developments and I just update my opencore 0.6.8 to latest 0.7.3 and included the new minimised set of patches. Installed latest bios update and after some tweaks all working fine again and just installed latest Monterey Beta on my backup drive which was also painless. Everything working including WiFi / BT / Aquantia / handoff etc. (except still no sleep, wakes immediately just like previous OS versions)

 

Attached my EFI if anyone needs a starting point. I have more or less default BIOS settings, disabled CSM and enabled above 4G.

 

Many thanks for this great community!  

Rox67er EFI ASrock TRX40.zip

  • Like 1
  • +1 3
Link to comment
Share on other sites

On 9/9/2021 at 5:46 PM, Rox67er said:

Amazing work guys, a bit quit from my side lately but all is well.

 

Have been reading along with the new developments and I just update my opencore 0.6.8 to latest 0.7.3 and included the new minimised set of patches. Installed latest bios update and after some tweaks all working fine again and just installed latest Monterey Beta on my backup drive which was also painless. Everything working including WiFi / BT / Aquantia / handoff etc. (except still no sleep, wakes immediately just like previous OS versions)

 

 

 

My sleep always works. For me, I had to set up my USB ports correctly.

Attached are my settings for Asrock TRX40 Creator. Your case settings will be slightly different than mine.

 

* Need Realtek audio port to be defined. Without this, your computer will attempt to sleep and then pop back on.

* On power up, no Realtek audio. Requires 1 sleep to work. Wish I could figure this out.

* My Logitech camera quits working after two sleeps. I have to unplug and replug to get it to work.

* LED Controller port MUST NOT be defined to keep from getting Code 99 problem.

SSDT-TRX40-USB-Port_R88.dsl.zip

  • Like 1
Link to comment
Share on other sites

14 hours ago, Rocket88 said:

 

My sleep always works. For me, I had to set up my USB ports correctly.

Attached are my settings for Asrock TRX40 Creator. Your case settings will be slightly different than mine.

 

* Need Realtek audio port to be defined. Without this, your computer will attempt to sleep and then pop back on.

* On power up, no Realtek audio. Requires 1 sleep to work. Wish I could figure this out.

* My Logitech camera quits working after two sleeps. I have to unplug and replug to get it to work.

* LED Controller port MUST NOT be defined to keep from getting Code 99 problem.

SSDT-TRX40-USB-Port_R88.dsl.zip 2.36 kB · 2 downloads

Thanks for sharing Rocket88, I have some USB setup as without it I kept having the 99 error every second boot and had to fully power down the computer. I will look into your file to see if there are differences. I don't think I have a special setting for the Realtek audio... 

 

Did you do special things in the BIOS?

Link to comment
Share on other sites

On 9/12/2021 at 4:35 PM, Rocket88 said:

 

My sleep always works. For me, I had to set up my USB ports correctly.

Attached are my settings for Asrock TRX40 Creator. Your case settings will be slightly different than mine.

 

* Need Realtek audio port to be defined. Without this, your computer will attempt to sleep and then pop back on.

* On power up, no Realtek audio. Requires 1 sleep to work. Wish I could figure this out.

* My Logitech camera quits working after two sleeps. I have to unplug and replug to get it to work.

* LED Controller port MUST NOT be defined to keep from getting Code 99 problem.

SSDT-TRX40-USB-Port_R88.dsl.zip 2.36 kB · 5 downloads

Have you tried defining with USBToolkit.kext. Using Windows.

 

As you know, I have sleep. And I have Realtek Audio /ALC and LED Controller undefined in USB definitions. I use Above 4G. Also I dont bother with SSDTs

Edited by Driftwood
adding
Link to comment
Share on other sites

One thing Ive noticed with Asrock TRX40 board is if you fully populate all PCI-E slots and all NVMEs, plus a few internal SATAs / SSDs, and even if you've USB set to 15 ports, you can get quite a few problems under Big Sur. I had three M2 nvme's (2x MP600s and a 8tb Rocket). The MP600s on Slot 1 and 2, Rocket on 3. I found Mac BS boot on SSD was very problematic with ethernet and firewire card not working or erratically when they did.

 

If I pulled out the slot 2 MP600 m2 drive all seems perfect!

 

So watch your PCIE resources... they soon add up and begin to cause problems.

 

FIREWIRE+RME Fireface800/400 fix under Big Sur

For anyone with problems getting Firewire and RME Fireface audio working under Big Sur (11.5.2) and onwards, you may find yourself reinstalling the RME drivers time and time again to combat crackling. You shouldn't have to. Simply install, 'Accept' Security and Privacy  for the RME driver, reboot. On reboot, you may hear crackle on audio for the RME first time. However, the switch off RME, then Log Out current User, Switch on RME (wait until red light goes out) and Login again as your user (ie dont reboot), and the RME should reset (orange light and red light should be out, and only two nice green LEDs indicating everything is sweet). Music!

Edited by Driftwood
Link to comment
Share on other sites

Hello there! First thanks for all the efforts on getting OS X running on Threadripper platform! After I found this thread I was certain I could get it working as well and bought the hardware. So far all went really well 🙂

 

I use the Gigabyte TRX 40 Designare v.1. running Big Sur and besides WiFi most things do work really great. I have two interessting issues though:

 

1) if I open a cloud document in Photoshop it loads but as soon as the picture is show, Photoshop just crashes. If I use local files all is fine. Maybe somebody has an idea about that? (minor inconvinience, so not that important)

 

2) my OS X installation is dual boot with Winodws 10. Both have their own SSD drive. After a while (not sure why, how, when) the OS X will not boot any longer. It shows the OS X logo and the progress bar. Just when it gets to roughly 25% the system restarts. So I cannot start into OS X any more. I did a reinstallation and it worked again for two days, now its broken again. No changes to OpenCore or the hardware in those cases so I have no clue what I could do.

 

Thanks for your help!

Edited by gosi
Link to comment
Share on other sites

  • Supervisor
16 minutes ago, gosi said:

1) if I open a cloud document in Photoshop it loads but as soon as the picture is show, Photoshop just crashes. If I use local files all is fine. Maybe somebody has an idea about that? (minor inconvinience, so not that important)

 

2) my OS X installation is dual boot with Winodws 10. Both have their own SSD drive. After a while (not sure why, how, when) the OS X will not boot any longer. It shows the OS X logo and the progress bar. Just when it gets to roughly 25% the system restarts. So I cannot start into OS X any more. I did a reinstallation and it worked again for two days, now its broken again. No changes to OpenCore or the hardware in those cases so I have no clue what I could do.

 

Thanks for your help!

welcome here

1) are you logged in cloud with your email? If so have you patched with @tomnic method you can find on international/general area

2) I suggest to use -v boot-arg and a debug Opencore version to see if all is fine when this weird behaviour happens

 

Link to comment
Share on other sites

No I have not yet patched it, thanks for pointing out, I will try that method and see if it helps!

About the -v, I knew how that works with Clover but with OpenCore if I press space, nothing happens. Any idea what could be the problem? I used the "EFI OP 0.7.0 -Big Sur 11.4 GIGABYTE Trx40 Rev 1.1" from this thread, as it matches my hardware really well and like I said installation worked fine every time, just after a while it dies.

To which OpenCore version could I savely upgrade?

Thanks for your time 🙂
 

PS: What is broken in Monteray if one tries the beta right now?

Link to comment
Share on other sites

  • fabiosun changed the title to [Discussion] - TRX40 Bare Metal - Vanilla Patches

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • There are no registered users currently online
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.