trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[iGPU]

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. 

 

 

Edited July 17, 2021 by iGPU

[iGPU]

 

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.

 

Spoiler

 

Edited July 17, 2021 by iGPU

[fabiosun]

I use Aquantia card of MSI trx40 pro 

same b1 patch you can find in my Efi

i think I used yours posted time ago

no problem there

 

[Ploddles]

Disabling all kexts except lilu and virtualsmc and also deleting networkinterfaces.plist made absolutely no difference. BS still either freezes after I enter my password and stays locked up or reboots a few minutes after logging in and displaying the desktop.

 

Monterey will not boot to the logon screen and just reboots half way through loading.

 

My next test will be resetting all my quirks back to those that enable me to boot with my old EFI.

 

Wish me luck, but I'm not too hopeful atm!!

[Ploddles]

Well that was another hour or so wasted, no joy with kexts or quirks set the same as my original EFI, exactly the same happens. 
 

Next test will be to try @fabiosun’s 0.7.2 build of OC to see if I can get any further but that will have to wait until tomorrow afternoon. 

[jsl2000]

9 hours ago, fabiosun said:

maybe we could refine also this patch:

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

maybe on this MaxKernel should be 20.99.99
it seems not mandatory for  Monterey B3

I can confirm that with  the released OC 0.7.1 that "algrey - _cpuid_set_info - GenuineIntel to AuthenticAMD" is not needed for Monterey ß3 in my FX-6300 hackintoshs, but I can NOT enable ProvideCurrentCpuInfo which always got dead on red screen !

[jsl2000]

19 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 · 15 downloads

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 · 9 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

This OC 0.7.2 debug-Shanee can not boot legacy FX-6300 which always got immediate dead on booting. So I stay at released OC 0.7.1 which worked perfectly in my both FX-6300 and Ryzen 1700X hackintoshs now.

[fabiosun]

@jsl2000with 072 debug of shaneee have you disabled patch 0?

[jsl2000]

28 minutes ago, fabiosun said:

@jsl2000with 072 debug of shaneee have you disabled patch 0?

No.

Should I enable CurrentCpuInfo and disable patch 0 for re-testing ?

Can I apply these 3 patches ?

Which one is correct for 6C/6T ?

Edited July 18, 2021 by jsl2000

[fabiosun]

No need of it if you use PR EFI edition

it is included in quirk you use👍

I mean you don’t need of those 3 patches

core count is inside provide cpu info quirk

[jsl2000]

27 minutes ago, fabiosun said:

No need of it if you use PR EFI edition

it is included in quirk you use👍

I mean you don’t need of those 3 patches

core count is inside provide cpu info quirk

Thanks.

So even RestrictEvents.kext can be disabled  ?

[iGPU]

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.

 

 

 

[fabiosun]

I agree with all above written @iGPU

and, He remarked well about our TRX40 chipset

 

@jsl2000has a different chipset and I think MMIO is not important for him

 

I add an option to the comprehensive methodological list explained by iGPU

The Clover Bootloader option 🙂

If you win the right dislikes as it is not as clear as it can work today .. It is a great option to try the patches without having to re-edit your config

Months ago I reduced the number of patches I used thanks to one of the first clover(512x) who copied the way of working of opencore.

Not completely reliable but it helps a lot to understand some relationships for example between patches,quirks

(not all quirks are present)

 

a bit OT below:

 

now that we have all the same tools to start with the "new" patches ..

As soon as you solve the problems you have with the updates and kext in use useful for you ..

I would like to "attack" another controversial topic ..

Relationship between:

 

A) Quirk

B) Patches

 

Not in the conventional way or based only on configuration.pdf or on very famous guides that have often copied things from us (and pass me the joke, even in a wrong way) 🙂

so I would like to understand with you when you have your system fully functional the relationship between for example:

 

0) patches

1) DummyPowerManagement

2) RebuildAppleMemoryMap

3) SetupVirtualMap

4) ProvideCurrentCpuInfo

 

in particular, because 1) not all trx40 users need it, but all Gigabyte users for example and x570 users

Because 2) it can be circumvented in some cases

4) why an important patch like Disable _x86_validate_topology some need it and others don't and if it is not needed, what happens by activating the superquirk 4)?

 

These are just thoughts of a midsummer morning 😉

but I wanted to share them with you!

Edited July 18, 2021 by fabiosun
added clover option

[fabiosun]

7 hours ago, Ploddles said:

Well that was another hour or so wasted, no joy with kexts or quirks set the same as my original EFI, exactly the same happens. 
 

Next test will be to try @fabiosun’s 0.7.2 build of OC to see if I can get any further but that will have to wait until tomorrow afternoon. 

 

Just to explain that that EFI is not mine, but it is the same one you can get by downloading from here:

https://github.com/Shaneee/OpenCorePkg

 

later to compile it yourself. you can run the command found in the downloaded folder from the terminal :

build_oc.tool

you will find after some minutes in binaries folder two zip:

 

[Arrakis]

2 hours ago, fabiosun said:

Not in the conventional way or based only on configuration.pdf or on very famous guides that have often copied things from us (and pass me the joke, even in a wrong way) 🙂

so I would like to understand with you when you have your system fully functional the relationship between for example:

 

0) patches

1) DummyPowerManagement

2) RebuildAppleMemoryMap

3) SetupVirtualMap

4) ProvideCurrentCpuInfo

 

in particular, because 1) not all trx40 users need it, but all Gigabyte users for example and x570 users

Because 2) it can be circumvented in some cases

4) why an important patch like Disable _x86_validate_topology some need it and others don't and if it is not needed, what happens by activating the superquirk 4)?

 

These are just thoughts of a midsummer morning 😉

but I wanted to share them with you!

@fabiosun

As you can see, I have the exact same quirks as yours.
This means that it is starting to have uniformity between motherboards. (MSI TRX40 Creator, Gigabyte TRX40 Aorus Xtreme, MSI Trx40 Pro 10G, Gigabyte TRX40 Designare)

I have to keep the DummyPowerManagement activated otherwise I get this error (Screen capture)
I'm still on your version of Open Core 0.7.2.

I will try to remake a Monterey B3 instal today if I have time.

 

 

@PloddlesDo you also have to activate Dummy Power Management?

[fabiosun]

@Arrakis i cant see on your image first KP part..

dummypowermanagemt is in my opinion the last thing to understand well togheter topology patch you need (included now in ProvideCpuInfo quirk)

[Arrakis]

@fabiosunI can't get the screenshot because the behavior is different. I can log into the session then after 1 min reboot .... and so on.
The screenshot is when I switch the efi back to the other with dummypowermanagement enabled.
I don't know if this can help?

[Ploddles]

@Arrakis Yes, I need dummypowermanagement otherwise my system will not boot.

[fabiosun]

@Arrakis

I was seeing your EFI posted in the first post of this thread. Opencore 070 and use of the patch:

 

algrey - cpu_topology_sort -disable _x86_validate_topology

 

this patch later included in the ProvideCurrentCpuInfo quirk

It allows you to start without having that patch in the config.plist just by activating the mentioned quirk

 

The patch in that form is no longer available, there is another one instead:

 

XLNC - Disable _x86_validate_topology - 10.13/10.14/10.15/11.0/12.0

 

It is completely different and, in my opinion, much more invasive

Now, it seems that you are unable to use neither this patch nor the quirk to go through the second phase of the installation ..

I would not want the patch in this form to be invalid for your cpu.

Although, in case it could be a big problem even for users of platforms lower than ours

 

have to try asking other x570 platform users if they use this patch on their working rigs

In case, can you post the config.plist you are trying to start Monterey with?

thank you

 

[Arrakis]

1 hour ago, fabiosun said:

have to try asking other x570 platform users if they use this patch on their working rigs

In case, can you post the config.plist you are trying to start Monterey with?

thank you

 

here is my config.plist under your Opencore 0.7.2 version

Arrakisconfig.plistzip.zip

[fabiosun]

6 minutes ago, Arrakis said:

here is my config.plist under your Opencore 0.7.2 version

could you see if you do a step more with this?

 

config-3-Arrakis.plist.zip

[Arrakis]

@fabiosunit's the same, here are the last lines loading the system and the debug file

opencore-2021-07-18-161248.txt.zip

Edited July 18, 2021 by Arrakis

[iGPU]

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.

Spoiler

 

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):

Spoiler

 

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

Spoiler

 

And you might try a MmioWhitelist variation:

Spoiler

 

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

Spoiler

 

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

Spoiler

 

Edited July 18, 2021 by iGPU
add UEFI

[Arrakis]

1 hour ago, iGPU said:

 

 

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.

  Reveal hidden contents

 

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):

  Reveal hidden contents

 

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

  Reveal hidden contents

 

And you might try a MmioWhitelist variation:

  Reveal hidden contents

 

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

  Reveal hidden contents

 

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

  Reveal hidden contents

 

I started under 11.4 with the efi modified according to your remarks.

I launched the installation on a volume from the disk image which is in the application folder of BigSur 11.4 so a clean instal.

Same result, the first part is installed correctly but on the second start always the same error.

my modified config.plist following your remarks and the debug file.

config.plist Arrakis modified following Egpu.zipopencore-2021-07-18-171901.txt.zip

[fabiosun]

It seems many people have some problems to update to beta 3 from Big sur 

I have had no problem in update from beta 1 and from 11.5 rc

also all is fine from a clean installation from usb pen