trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[iGPU]

The latest v070 commit adds a folder name Acidanthera to Resources/Image. If this is not present, you'll only see the text based OC bootloader instead of OpenCanopy's graphic display. I've attached the folder to this post (Acidanthera-orginal.zip).

 

WIthin this folder are 3 others: Chardonnay, GoldenGate and Syrah. Chardonnay will the "Old Icon" (10.4 stye) folder, GoldenGate is the Default. Syrah will store the dark/black images, while Chardonnay will store the lighter colored images.

 

 

The Docs are a little confusing about these definitions. There is no mention of the "Modern-" and "Old-" icons which are still present in the main "Image" folder.

 

The documentation says:

 

 

 

UPDATE:

 

Yes, the items outside of the Acidanthera folder are ignored. So the structure below works just fine.

The original attachment is the stock folder. The second attachment (Acidanthera-modified.zip) is one I use with some darker images inside the GoldenGate & Syrah folders. I placed the "Modern-" images inside the GoldenGate folder and the "Old-" images inside the Chardonnay folder. This modified folder works as expected when Misc/Boot/PickerVariant is set to Auto.

 

 

 

 

 

Acidanthera-modified.zip

Acidanthera-orginal.zip

Edited May 15, 2021 by iGPU

[shutterbug168]

5 hours ago, Arrakis said:

@iGPU 

Approach n ° 1 : Doesn't work for I210 (no internet connection) and I already had DisableWatchDog enable from the start.

Approach n ° 2: Does not work for the I210 (no internet connection) but I will keep the SSDT-TRX40-USBX)

Approach n ° 3: Does not work for the I210 (no internet connection)

Approach N ° 4: Prevents the system from starting, stays on the beginning of the loading stuck eternally on the apple.

 

I did the 1,2,3,4 tests with the SSDT-EC-USBX-DESKTOP.aml and / or the SSDT-TRX40-USBX.aml) as well as the I210 Device Properties enabled or disabled.

This makes a number of test….

I even did a clean instal 11.3.1 then update to 11.4.beta 3.

The installation is absolutely problem-free with my EFI. I just changed a DSDT. I kept the SSDT-TRX40-USBX.aml.

I don't get a PCI card placement errors message the first time I log in (I don't use Kext restrict events).

And still no ethernet connection. The Wifi module works as before.

From the moment I start to order the ports for example, it is unstable. (Kernel panic….)

 

I keep the patch and the pci properties of the I210 as it works as you can see. (Screenshot)

I will wait for the next beta and the new version of OpenCore to redo the tests

I saturate and I am a little annoyed ...😞

@Arrakis, not sure if you had re-flashed your Titan-Ridge TB3 card to the new firmware from the link shared by @iGPU. The new firmware fixed all the random freezes caused by the 11.3.1 OS update on my X3970X hack... 

[fabiosun]

kernel patches 11.4 beta3.plist.zip

 

to boot in OSX 11.4 beta 3  I am using these set of patches

 

[Arrakis]

@shutterbug168 

As I said on a previous post, I removed the Titan Ridge map and I have the same instability under 11.4.beta3 especially since I have absolutely no issues under 11.3.1

My hack has been on for 16:30 with the Titan Ridge card installed with Promise Pegasus2-R storage and an UltraStudio 4K Mini plugged into it. I have no freeze, instability etc…. under 11.3.1.

It works very well with hot and cold connections as well in thunderbolt or USB C.

So I think we can rule out this possibility of instability related to this card.

[Arrakis]

1 hour ago, fabiosun said:

kernel patches 11.4 beta3.plist.zip 2.19 kB · 1 download

 

to boot in OSX 11.4 beta 3  I am using these set of patches

 

@fabiosun

I have three differences the occurrence :

1. The first is algrey - cpu_topology_sort -disable _x86_validate_topology which I am forced to keep since the start of my hack otherwise blocked when starting Opencore as mentioned here
2. The second is lapic_init - remove version check and panic it's not the same values. I checked in the beta patch here there are three occurrences and none match your value. Why ? When did you change these values ?
3. The third Aquantia, it's normal I don't have an Aquantia card.
4. 

[Arrakis]

15 hours ago, iGPU said:

I'm sorry to hear this, but now I'm beginning to wonder about your actual internet connection. The fact that the drivers are reported being loaded on the PCI window makes me think the ports are active.

 

Am I understanding that if you run an older version of OC, your ports are active, but from (what?) v069 onwards there is no activity? If you create a new EFI with the same kexts/dev prop we just worked on and run under v068, it all works?

 

Some more questions.

 

Are there any LEDs on at the RJ45 jacks on the rear panel of your mobo?

 

Do you have other ethernet cables to try? Are you going through a switch? Is the switch working (powered up, etc; I've had them go bad)?

 

Can you directly run an ethernet cable from the rear of the mobo to your modem/router?

 

To help with trouble shooting, there is an Apple utility (Network Utility) that is useful. Unfortunately, Network Utility was dropped for Big Sur. But fortunately, it can be extracted from Catalina. The Catalina version runs just fine under Big Sur. I'll attach a copy to save you digging around for it. (On new installs, Big Sur removes it (I've variably installed in the Application or Utility folders, but hiding it in the Download folder seems best.)

 

If you run it, it will show you packet transmission information. Below is mine for the I210 port. The one for the Aquantia port is similar (I run 2 cables back to my router). You should be able to see something like this.

 

 

Network Utility.app.zip 1.18 MB · 0 downloads

@iGPU

I don't think it's a hardware problem outside the PC, The pc is directly connected to the modem / router. I changed nothing. No cable, no modem / router, etc….

I have just made a 200 GB download with FileZilla from an external server to my hack and conversely a 70 GB upload with Firefox (We transfer) with my current EFI under OpenCore 0.6.9 and Big Sur 11.3.1 and I have encountered no cuts or stability ...

From OpenCore 0.6.2 / Catalina up to OpenCore 0.6.9 / Big Sur 11.3.1 inclusive I had no problem with this I210Intel.

I will do a test with OpenCore 0.6.8 to see if the Intel I210 recognition problem is the same under 11.4 beta 3

[fabiosun]

1 hour ago, Arrakis said:

@fabiosun

 

1. 

this one in 11.4.3 beta 3 does not load (if you try to boot in verbose mode or check your debug log you can verify it if it is the same also for you)

[Arrakis]

@fabiosun I checked in Big Sur 11.3.1 and Big Sur 11.4.beta 3 all patches are loading.

[Arrakis]

16 hours ago, Ploddles said:

@Arrakis This is a long shot but have you tried deleting your NetworkInterfaces.plist file and then rebooting.

 

cd /Library/Preferences/SystemConfiguration

sudo rm NetworkInterfaces.plist

@Ploddles 

I didn’t use the terminal command but went directly to the folder.

The "NetworkInterfaces.plist" file does not exist ....! It is worth saying that it was never created. For which reason …..?

[Ploddles]

46 minutes ago, Arrakis said:

@Ploddles 

I didn’t use the terminal command but went directly to the folder.

The "NetworkInterfaces.plist" file does not exist ....! It is worth saying that it was never created. For which reason …..?

 

That could be your problem, without the plist macOS can't connect to your network cards. If it doesn't exist when the system starts up then it scans your interfaces and creates the file. From then on it just reads the plist without having to fully scan and configure your system again.

[iGPU]

51 minutes ago, Arrakis said:

@Ploddles 

I didn’t use the terminal command but went directly to the folder.

The "NetworkInterfaces.plist" file does not exist ....! It is worth saying that it was never created. For which reason …..?

 

I rather doubt that OC is to blame. Your NIC I210 problem seems more like a Big Sur 11.4 beta issue, and will require future releases to fix.

[iGPU]

@Arrakis 

 

I've found one more thing for you to try. 

 

I must have too much time on my hands; I was going through each entry in OC and came across this "Force" example provided by the OC developers. It 'forces' IONetworkingFamily! This is the main kext file in which is located the plugin AppleIntelI2210Ethernet.kext.

 

If you look under your Kernel/Force/0 entry you will probably see it. If not, then open the Sample.plist file inside the Docs folder and copy and paste it into your config.plist file. Do remember to enable and change the MaxKernel, MinKernel to the values I've shown below.

 

[Arrakis]

@iGPU Merci beaucoup pour l'excellente recherche.😃

 

This is a great lead, for sure my problem is there. I remember in the multitude of backtrace kernel reports related to IONetworkingFamily.

From the start I suspected this issue related to the IONetworkingFamily car kext in BigSur 11.4. beta 3 the wrong kext is loaded (see capture, AppleEthernetE1000.dext....)

I will do the test at the end of the week as I am in production until Friday.

I have looked in the OpenCore documentation (Page 25) this handles issues related to ONetworkingFamily and IOAudioFamily.

Here are the values in my current config.plist.

Edited May 17, 2021 by Arrakis

[fabiosun]

 

11.4 is Out 😉

 

[Ploddles]

23 minutes ago, fabiosun said:

 

11.4 is Out 😉

 

 

At 11.3 stage the RC came out and then further betas were released before the final release. Let's hope this doesn't continue like that one did.

[fabiosun]

it is safe to update..patches are fine (kernel AMD patches)

 

[Rox67er]

On 5/12/2021 at 8:29 PM, iGPU said:

 

Lately, I've been shutting down the computer at night as I've not had any stability issues to study. However, I left computer on last night (running latest beta 4 and with RestrictEvents enabled) and this morning the computer was off. On restart, I got a macOS warning of a crash, so I seemed to have had a shutdown over night. 

 

The Memory section does not add to any stability problems; I checked that last week (and it's part of OC, not RestrictEvents). It sounds like RestrictEvents is the cuilprit.

 

I'm at work now but I'll study later tonight to see if I get a shutdown again, but it must have happened a few hours into the boot, so it might take some time to sort out. (Today the 6900XT is scheduled to arrive and it I exchange the GPU, that might add to any stability issues.)

 

 

I never used RestrictEvents and have had no issue with 11.4 beta's so far.

[iGPU]

On 5/17/2021 at 12:25 AM, Arrakis said:

@iGPU Merci beaucoup pour l'excellente recherche.😃

 

This is a great lead, for sure my problem is there. I remember in the multitude of backtrace kernel reports related to IONetworkingFamily.

From the start I suspected this issue related to the IONetworkingFamily car kext in BigSur 11.4. beta 3 the wrong kext is loaded (see capture, AppleEthernetE1000.dext....)

I will do the test at the end of the week as I am in production until Friday.

I have looked in the OpenCore documentation (Page 25) this handles issues related to ONetworkingFamily and IOAudioFamily.

Here are the values in my current config.plist.

 

Your setting shown above won't work as your MaxKernel is 13.99.99.

 

You must change this to 20.99.99 and the MinKernel to 20.0.3 or 20.0.4

[fabiosun]

and also it seems disabled 🙂

 

[iGPU]

 

24 minutes ago, fabiosun said:

and also it seems disabled 🙂

 

 

Yes, that too.

 

Also change the DevProp LAN injection to the attached data. I've added the "device ID" info, which id 0x1533 (in reverse byte order) for I210.

 

And I have a different patch for you to try.

 

Arrakis-DevProp.plist.zip

Arrakis-kernel patches 11.4.plist.zip

Edited May 18, 2021 by iGPU

[Arrakis]

@iGPU @fabiosun

Thank you very much, I will do the tests on Friday with the new version of Big Sur 11.4 (20F71).😄

[iGPU]

4 hours ago, Arrakis said:

@iGPU @fabiosun

Thank you very much, I will do the tests on Friday with the new version of Big Sur 11.4 (20F71).😄

 

And one more possibility.

 

Using the DevProp injection with its 'device-id' from above post, try adding the attached FakePCIID.kext file.

 

The other attachment (FakePCIID_Intel_I225-V), may work in combination with FakePCIID.kext. The new Intel 2.5G LAN commonly found on new mobos, I225-V NIC, is part of the same AppleIntelI210Ethernet kext that you're having trouble with and may help if used in conjunction with FakePCIID.

 

So this gives at least 2 combinations: DevProp + FakePCIID and DevProp + FakePCIID + FakePCIID_Intel_I225-V.

 

 

 

Note that FakePCIID_Intel_I225-V does not require an ExecutablePath entry:

 

 

 

FakePCIID.kext.zip

FakePCIID_Intel_I225-V.kext.zip

Edited May 18, 2021 by iGPU

[Ploddles]

BS 11.5 beta 1 has been released.

[fabiosun]

 

It is safe to update (kernel patches are still doing their job)

 

[iGPU]

 

Activating AirDrop Guide

 

I've read on many threads on different forums about problems with activating AirDrop. While there are many reasons why AirDrop may not work, most of the problems are hardware related. As for hardware, there are 2 basic choices: use the installed card or use an add-in-card (AIC) that contains a Mac-compatible WLAN. With respect to the former, there are recent threads regarding the use of the Intel AX200, which is the stock WLAN card on most of our TRX40 mobos. There are also some of us who've exchanged this card for a more Mac-compatible WLAN card.

 

I've been experimenting with this issue and will try to present a hopefully lucid explanation. But first, some hardware ground rules: the Fenvi-919, while faster, has some MacOS crashing problems, so I settled on the Fenvi-1200M as the most reliable and Mac-friendly (AirDrop working) PCIe card. This card uses the BRCM-4360 chip (which will become important later when discussing kext files). No other WLAN AIC will be discussed.

 

As for the AX200, it can be left in-situ or can be exchanged for a card similar to the BRCM-4360. Since exchanging cards can be tricky (I've swapped them many times, so not so difficult), and can vary for each mobo, let's assume that the AX200 is left intact, and avoid all discussion of card swapping for purposes of this guide.

 

Now that the hardware is fixed, the AirDrop guide can be broken down into 2 sections: kext files and SSDT files. The kext files are divided into 2 groups: one set supports the AX200, the other set supports the Fenvi-1200M. The SSDT files are also broken into 2 groups: one to support the internal AX200 card, and the other, to inactivate the AX200 card and allow the Fenvi-1200M to properly function.

 

Important:

Without both of these steps, AirDrop will not work. In other words, unless both BT and Wifi are properly working, AirDrop will not work. And BT will not properly work if both the internal AX200 and the Fenvi-1200M are trying to each broadcast BT. Only one device must be allowed to broadcast BT.

 

As a heads-up, so you don't have to study all the details for the AX200: AirDrop presently (as of May, 2021) does NOT work when using the AX200. While BT and WLAN work with the kexts described below on the AX200, AirDrop does not yet work (perhaps with future kext updates it will). So at this time, the only advantage of using the AX200 is the speed of connection, esp regarding Wifi.

 

 

1. Kext Files

 

The AX200 requires a specific set of kext files known as "OpenIntelWireless" that can be downloaded here. You need both the BT set and the WLAN set.

 

The Fenvi-1200M requires a different set of kexts: AirportBrcmFixup, BrcmBluetoothInjector, BrcmFirmwareData, and BrcmPatchRAM3 (all provided in an attachment with this post). While there are some who claim that the Fenvi-1200M works OOTB (without any kexts), I've never, on any platform had such luck, and recommend using all of these kext files for the Fenvi-1200M.

 

The following Spoiler shows the 2 kext setups for both the AX200 and the Fenvi-1200M. You only want to enable one or the other, not both.

 

Kext Setup:

Spoiler

 

There are 2 plug-ins within the AirportBrcmFixup kext file (shown below). If you have the ~NIC-Injector chosen, the Fenvi-1200M WLAN will not be able to connect to your Wifi. Instead, if the highlighted plugin is chosen the Fenvi-1200M WLAN will connect just fine. The correct method of kext injection is shown in the above Spoiler.

 

 

 

 

2. SSDT Files

 

So far, the set of the kext files was fairly easy. The tricky part is getting the SSDT section correct. The SSDT files are essential in order to remove the power supply from the internal AX200. If the power is not removed, BT from the AX200 will compete with BT from the Fenvi-1200M and will AirDrop will be broken. Active power to the AX200 is only seen by examining IORE to see if there are 2 BT sources.

 

The image below from IORE shows what is seen when both are active. In the image, the port named HS05 (XHC0 was renamed to XHC by the SSDT; XHC0/XHC is under S0D2.D2A0.BYUP.BYD8 on my mobo), powers the internal AX200. Meanwhile, HS06 is the power supplied by the internal USB-2 header (again, on my mobo). This internal USB-2 header, on my mobo, also supplies the front USB ports on my chassis, along with other ports. HS06 must remain enabled.

 

Notice below the entry for "IOBluetoothHostControllerUSBTransport" under HS05 (where AX200 is attached) and the 2nd BT entry under HS06 for the "BRCM20702 Hub" (which is coming from the Fenvi-1200M): there are two BT sources. This will prevent AirDrop from working.

 

 

 

As described above, if you want the Fenvi-1200M to provide AirDrop support, you must inactivate HS05. This is done by removing it from the definition in the SSDT file. Shown in the Spoiler below, HS05 and HS06 (HS01-4 are not used and so are removed by "not" defining them). If the HS05 is simply removed, then the BT portion of the AX200 will cease to function.

 

Spoiler

Do note that each USB device for the WLAN modules are defined as 0xFF (or 255). This means they will be assigned as an "Internal" connections, not a USB-3 port (which would be 0x03).

 

 

 

 

A. HS05 ACTIVE (supplying power to the AX200 card for BT):

 

What happens if both HS05 and HS06 are functional and both set of kexts are used? Then the USB power is still supplied to the internal AX200, whether or not any OpenIntelWireless kexts are used). Since both cards are active BT will be broken and AirDrop will not be functional.

 

The active ports are also visible using Hackintool as shown below, along with SystemInformation and IORE findings.

 

Spoiler

Both XHC's HS05 and HS06 ports active as shown in Hackintool at the top of the USB Port section. AirDrop is broken under these conditions. Since both are 0xFF, both show up as "Internal" connections. Other ports on my mobo are also shown.

 

 

 

AX200 BT active (AirDrop broken):

 

 

AX200 WLAN active (bottom red box) and so is the Broadcom from the 1200M (top box):

 

With these settings, IORE will show the AX200 being assigned to S0D2.D2A0.BYUP.BYD4.BYS4. The "AirportitLwm" is provided by the OpenIntelWireless kext. If this kext is not used, the AX200 will not be active and BYS4 will be empty.

 

An aside, on some forums/threads, an SSDT is used to cancel the device at its usual location in IORE. Such an SSDT does not seem to be needed for the TRX40 (simply don't use  the OpenIntelWireless kexts!).

 

 

 

 

B. HS05 CANCELLED (AX200 power supply is removed):

 

When HS05 is cancelled, there is no longer and AX200 BT being broadcast. The above changes to the following (only the Fenvi-1200M is active) and AirDrop works. The Spoiler belows shows SystemInformation and IORE results when there is not power supplied to the internal AX200. Hackintool also reveals that HS05 has disappeared. AirDrop is now working.

 

Spoiler

When HS05 is removed, only XHC's HS06 port active as shown in Hackintool.

 

SysInfo BT (with HS05 disabled, only the Broadcom WLAN is active):

 

SystemInfo WLAN:

 

IORE:

 

 

 

 

If AirDrop is working, you'll see a close-by device, such as the iPhone below. If AirDrop is not working, no device will be shown. Also notice that at the bottom is "Allow me to be discovered by: Everyone". If AirDrop is not working after following the instructions in this guide, make sure that "No One" is not selected; "No One" cancels AirDrop connections.

 

 

 

3. Conclusions

 

In summary, to get functional AirDrop, you need several things to happen.

 

First, you need to cancel the power supply to the internal AX200 by removing HS05 (or what ever USB port supplies your AX200). This will cancel BT from the AX200. You shouldn't have to do anything for the power supply from the internal header except perhaps re-define it as 0xFF, an internal header. (And, of course, you need to physically supply the Fenvi-1200M USB power using its enclosed USB-2 cable!)

 

Next, don't use any AX200 specific kext files, but do use kext files for the Fenvi-1200M as described above. This will prevent activation of Wifi from the AX200 card (prevent it from binding to S0D2.D2A0.BYUP.BYD4.BYS4), while enabling Wifi from the Fenvi-1200M.

 

To make things one stop shopping, I'm attaching the kext files for the Fenvi-1200M. They're up-to-date commits as the writing of this post (20 May 2021). I've also included the USBInjectAll-076 kext, which ensures injection of all ports (although I think this is probably more useful on an Intel platform and I don't use on the TRX40).

 

I've also attaching the SSDT files for reference, they may or may not work as is with your mobos. The SSDT that ends in "-NoIntelBT" removes HS05; the other one labelled "-WithIntelBT" leaves HS05 intact to supply the internal AX200 card.

 

If the SSDT files do not work, then upload an IORE file (using no USB SSDT files), and perhaps one of us can assist you with customization.

 

Finally, I'm attaching an ACPI/Add and Kernel/Add plist excerpt (shown in Spoiler below) that you can use to copy and paste to your own config file. (I did not supply the OpenIntelWireless kext files since they don't allow AirDrop at this time; you can retrieve on your own.)

 

Spoiler

 

 

 

 

 

 

 

 

 

SSDT-USB-Files.zip ACPI-Kext-excerpts.plist.zip

Kexts-for-Fenvi-1200M.zip

Edited May 21, 2021 by iGPU