trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[fabiosun]

On 6/30/2021 at 10:17 PM, Arrakis said:

@iGPU

Wonderful job for simplifying the patches.

I am using your patch except the last two.

The job done is so good that I don't even need the argument : cpu_topology_sort -disable _x86_validate_topology  in the garbage 😄

I envy your talent in this area.

 

----------

 

 

@Arrakis

Now is also more clear why (about topology):

ProvideCurrentCpuInfo did the job

Edited July 12, 2021 by fabiosun
pictures added

[carlo_67]

Clover 12 Patch, Opencore, 9 Patch start Bigsur e thanks to Mario 😇

 

indeed in Clover it does not even serve to enable Quirk

 

 

 

 

 

 

[fabiosun]

Without making any kind of controversy, let me tell you to take a look at this plist and if you want,

try to adapt it to the bootloader you use and remember also patch 0 has a value (1F) for my 3970x, you must adapt to your cores cpu number.

all patches used are public and available

patch 0 later had some adjustments, in particular on the masks and on the count brought to 1

these adjustments are not yet published by the author, but are not necessary to make various modern systems work

 

 the patch published by algrey on insanely mac, allows you to remove several "XLNC" patches

In the usual spirit that has always distinguished us, if you want to try them, if they don't work for you post a debug ...

you will not believe it .. but this thread is also read by people who then solve the problems in the bootloaders 🙂

 

 

 

@carlo_67it should work also on your platform 😉

Mario* thanks you for trying the previous solution

 

* 

 

UPDATE 17-07-2021:

 

 

[tomnic]

16 hours ago, carlo_67 said:

Clover 12 Patch, Opencore, 9 Patch start Bigsur e thanks to Mario 😇

 

indeed in Clover it does not even serve to enable Quirk

 

 

 

 

 

 

 

Amarioooooooo 😄

[Ploddles]

[fabiosun]

 

Link to a news for AMD user :)

 

[fabiosun]

 

macOS Monterey beta 3 (21A5284e)

https://developer.apple.com/news/releases/?id=07142021e

[fabiosun]

[Ploddles]

@fabiosun is that with the beta 2 patches as is or using the "special tool" announced by @Shaneee at amd-osx. https://forum.amd-osx.com/index.php?threads/pre-release-macos-monterey.1841/post-11438

[fabiosun]

also clover 🙂

but it needs more patches

 

@Ploddlesit is not a special tool 🙂

it is a quirk and I have talked time ago here

AMD OSX Patches maintainer have done a pull request to add some patches to this quirks all we have in open core available

I have had an opencore debug boot loader with all these patches inserted in it
Only one patch is not public otherwise I wouldn't be able to boot in Clover Booloader

[fabiosun]

to understand better:

https://github.com/acidanthera/OpenCorePkg/pull/277

 

[fabiosun]

 

these are patches AMD OSX maintainer would like to insert in a quirk with Shaneee pull request, with these you can bypass a lot of patches enabling that quirk

If opencoredevs accept it would be possible to to reduce the list of visible patches in Kernel/patch section

 

 

[iGPU]

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

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

 

Spoiler

 

A) First, open kext by right-clicking on kext and selecting "Show Package Contents":

 

 

B) Next, you'll see:

 

 

C) Then double-click and open Info.plist in your favorite editor. You'll want to edit the IOPCIPrimaryMatch section. You can even duplicate the TRX40 or X299 section and edit that duplicate, using that section for other mobos that you use.

 

 

 

 

 

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

Edited July 15, 2021 by iGPU
Updated uploaded kext file 15 July

[fabiosun]

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

Edited July 15, 2021 by fabiosun
with/without kext

[iGPU]

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.

[fabiosun]

no @iGPUit is a 960 pro 1Tb MVME

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

[iGPU]

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.

 

[A23SS4NDRO]

21 hours ago, iGPU said:

This is probably mostly cosmetic, but under the hood, who knows if Apple doesn't treat the controller differently?

This needs confirmation, since if this is valid it could be easily implemented in NVMeFix.

 

For those who use Samsung drives, I highly recommend either not to use macOS with them or to disable TRIM completely since a fancy rename won't give back support for IONVMeFamily - macOS doesn't like Phoenix controlles which unfortunately affect every Samsung NVMe since forever basically...

 

 

@iGPU

I suggest to open a feature request/discussion on acidanthera bugtracker on the rename from Generic to Apple SSD

8 hours ago, fabiosun said:

Samsung 960 pro is more compatible with apple?

This unfortunately is false, check out this article:

 

https://github.com/dortania/bugtracker/issues/192

Edited July 15, 2021 by A23SS4NDRO
the issue was the 192, not 196

[Jaidy]

for people running Monterey, have you done any benchmarking to compare with Big Sur? Just curious...

[fabiosun]

@Jaidyi did only davinci candle benchmark for graphic

gpu is about 5% slower than latest Big Sur 

cinebench23 is the same as previous os

 

[fabiosun]

@A23SS4NDROmy was a question not a statement 

I have seen your link

i boot with 960 pro in OS X it seems I have not any delay

i will check better

maybe ten seconds from boot menu to login page 

for trim I always used default custom config posted in opencore doc 

[A23SS4NDRO]

2 hours ago, fabiosun said:

i boot with 960 pro in OS X it seems I have not any delay

Check the test from the issue linked before, and try the different SetApfsTimeout

 

Unfortunately it's not specific to a single NVMe, but all Samsung are broken with IONVMeFamily - hence not recommended (since you can have issues with TRIM if it's kept enabled)

The issue with Samsung drives is documented here:

 

 

https://github.com/acidanthera/OpenCorePkg/blob/c5285973bcfd45908c62487cf2e318aa0328af3b/Docs/Configuration.tex#L2616

 

 

and also the additional wear on the drive that is the result of this incompatibility

[fabiosun]

hey guys....maybe you have missed something... 😛

 

b2/b3 patch has been published....

only read me is old....

secret was revealed by Shaneee a day ago or more 🙂 🙂

 

 

the secret is gone 🙂 🙂 🙂

 

[fabiosun]

and this is my patches list now to boot from Big Sur to Monterey beta 3:

 

Patches_BS_MR_1_2_3.plist.zip

 

You have to add (in initial position this):

Force cpuid_cores_per_package

 

from @Shaneee PR or with old one published on insanelyMac by Algrey (with cores number -1)

 

now without -1 for your cores number (not tested by me because i am using a different way)

so core count with above patch is:

 

32 cores - 3970x  =2 0

24 cores - 3960x = 18

16 cores - 3950x = 10

10 cores = 0A

8 cores = 08

6 cores = 06

 

Update:

I prefer to use old patch for "Force Cupid_cores_per_package"

but for someone could be fine to use it also

 

Update:2

Patches in PR works also in clover bootloader , it was a error of mine (missing Procedure on it)

Edited July 16, 2021 by fabiosun
Update 2 with further infos

[jsl2000]

2 hours ago, fabiosun said:

and this is my patches list now to boot from Big Sur to Monterey beta 3:

 

Patches_BS_MR_1_2_3.plist.zip 1.74 kB · 4 downloads

 

You have to add (in initial position this):

Force cpuid_cores_per_package

from @Shaneee PR or with old one published on insanelyMac by Algrey (with cores number -1)

 

now without -1 for your cores number (not tested by me because i am using a different way)

so core count with above patch is:

 

32 cores - 3970x  =2 0

24 cores - 3960x = 18

16 cores - 3950x = 10

10 cores = 0A

8 cores = 08

6 cores = 06

 

Follow your instruction and adapted with your config-patch.plist it still can not boot beta2 or beta3 of Monterey.

It can boot 10.13.x~12.0 beta1 only.

config.plist.zip

Edited July 16, 2021 by jsl2000