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: 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. 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. 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. 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.) SSDT-USB-Files.zip ACPI-Kext-excerpts.plist.zip Kexts-for-Fenvi-1200M.zip

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

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

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

@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.

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.

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

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

I posted some results on the GPU testing thread here, using Octane X. They are as good as the revised Davinci tests I've run and posted on the same thread.

I've done some other testing using Octane (downloadable from App Store, here). You may have to sign up (register with OTOY) for a free download. On the Octane (OTOY) forum, there is some discussion of testing with 6900XTs here. You may need to register on their forum to gain access. When I run Octane X, I get 7 sec for the 6900XT (although my GPU is constantly listed as an unknown, "AMD Radeon HD GF10 Family Unknown Prototype"). The fastest run was 6 sec; slowest was 8 sec; avg = 7 sec (4G is disabled; ResizableBar is enabled). Details from above image: Their tabulated results would imply that this is actually pretty good. The Radeon VII gives about 19 sec (although, if the 6900XT on my setup is getting 7 sec or 4 sec faster than on their plot below, perhaps the Radeon VII would also be about 4 sec faster, or 15 sec on my setup) if the differences are linear. The RTX-3080 got 8 sec, 3 sec faster than the 6900XT, so maybe 4-5 sec on my setup, assuming linearity. The 3090 is reported on some posts to get 7 sec under Linux with many scenes comparably rendered between the 3090 and the 6900; but on some renders, the 3090 is much faster than the 6900, so the results are scene dependent.

PlistEdit Pro is the editor I use; attached. Or try this one here (OCAT_Mac.dmg) PlistEdit Pro.app.zip

I created the patch. If's in one of the Spoiler sections above (please look at all of the Spoiler sections!) You simply copy from Spoiler and paste into your config.plist file:

Candle Benchmark in DR v17.2 with one AMD 6900XT, using Metal setting. Same results with or without WEG. I also repeated, with same results, ±4G. When 4G was disabled, I tested with ResizableBar enabled; again same results. (BTW, it is not possible, at least with my mobo, to boot with both 4G and ResizableBar enabled.) 18 @ 66 nodes; 23 @ 6 nodes. UDPATE: The above results are incorrect. It now shows the following (4G disabled; Resizablebar enabled): 30 @ 66 nodes; 40 @ 6 nodes. The difference is a patch I'd left engaged for the first set of results. I'd left it enabled (and just remembered this morning), as I didn't see an issue using it with the Radeon VIIs. If you enable this patch, your results are reduced by ~ 50% !! The patch does not have any influence on the Octane X results discussed in the next post.

I updated my above post regarding 6900XT noise. It is now better and should further improve with some more changes.

1600 USD. (But I'm still waiting for refund from eBay for the 1300 I spent for 1st 6900XT that seems now to have been from a scammer.)

Both, but they threw in a free dialysis unit.

The one annoyance I'm seeing (hearing), is noise coming through my USB audio interface (and this is with the interface muted). If nothing on the computer is used, the speakers are quiet. If I scroll a window, I get a noise proportional to the amount of scroll. If I run a GPU test, the noise gets louder, disappearing once the test is complete. I did not have this with the Radeon VIIs or the RX580. I dislike hums and buzzes in my audio systems. It reminds me of the occasional Vega 64 coil whine, but this is worse. If this doesn't improved, I'll sell the 6900XT. I'd rather have a slow, quiet GPU than a fast, noisy one. UPDATE: Better. I was lazy on 1st install and only connected 2 power supply (PS) cables with a jumper from one of these for the 3rd PS jack. Today, I installed a 3rd PCIe PS cable for the GPU, and noise is reduced (not zero, but close enough). The reason to add 3 discrete PS cables rather than use a jumper from one cable is to minimize PS sag. While the new AMD GPUs are more efficient, they require a lot of power under load and this can lead to sag. When the PS sags, it can modulate the PS coils on the GPU, leading to buzz and other noises. In the next day or two, I'll be adding some ferrite collars around the USB cables: one simple clamp on (high freq block) and at the other end, a loop clamp on (lower freq block). Hopefully that will eliminate most all noise. Another option I may try out is a USB filter (they come in various plug shaped combinations). 2nd UPDATE (5/15/21): Neither the ferrite beads nor the USB filter worked to remove the noise. What did work was an isolation transformer (here; these are rather expensive due to the high quality Jensen transformers, fortunately I already had one from another project). All became quiet once the transformer was placed between the output jacks of the USB Audio Interface and the speakers. This fix suggests that there is a ground loop somewhere in the computer/GPU/PS section that the GPU is modulating.

Yes, I posted the dual Radeon VII results back on 9/9/21, here with an early version of BS beta. (The debate at the time was if bare metal was as good as VM.)

@Arrakis Ok, some more approaches... 1) First try one more kext (attached). This one (SmallTreeIntel82576_mod.kext), I'd modified in 2019 (it works with I211 and with I210), adding a 'root' ending to the Info.plist file that was missing from original and would give an occasional panic without. Also, have you set the following in red box to "Yes" (it might help): 2) Are you injecting a DSDT or SSDT that might be interfering? Specifically, I'm wondering what is inside your "SSDT-EC-USBX-DESKTOP.aml". It is possible that the 'DESKTOP' portion is a DSDT extract that may be giving you grief. Instead of enabling this aml file, disable it and use the one attached below (SSDT-TRX40-USBX.aml). BTW, if you want to get a summary of all loaded, non-Apple kext files, enter the following into Terminal: Kextstat | grep -v com.apple My results are in Spoiler below: 3) The next approach is to create a kext patch. Try the attached code shown in the Spoiler below, if the above SSDT swap does not work. 4) Finally, what about trying to inject AppleIntelI210Ethernet.kext? Attached is one I extracted from the latest Big Sur beta. If you use this, I'd try with and without the SmallTree82576 kext enabled, listing the SmallTree after AppleIntelI210Ethernet kext as in Spoiler. In any of these situations, you can probably still use the Device/Properties stuff I uploaded earlier. In fact, in Comet Lake mobos, AppleIntelI210Ethernet can have a kernel panic that is only resolved with a DeviceProperties injection (see here). Also, remember to try re-setting NVRAM. *** If the I210 works, you should see sometime like I see for I211: SDDT-TRX40-USBX.aml.zipSmallTreeIntel82576_mod.kext.zip AppleIntelI210Ethernet.kext.zip

I've only done minimal testing (and I've left on "silent", not "OC", mode). The GPU is so far a bit underwhelming: LuxMark not much better than the Radeon VII results (and the PowerColor 6900XT takes up 3 slots!, so dual cards not possible). Since I never game (I've never seen a purpose in playing computer or board games; my life is too busy), the 6900XT may not a benefit for my build. But I'll test some more. DaVinci will be interesting (as I actually use it), to see if one 6900XT is close to my old dual Radeon VII set up. The 6900XT? eBay.

Yes, I use latest OC commits from here (presently booting with v070, 4cdd360. I update daily (sometimes more often ). I also run ocvalidate (inside OC/Utilities/ocvalidate folder) on current config.plist file to ensure there are no errors; sometimes the docs are behind and ocvalidate will pick up structural changes. Each commit has an updated ocvalidate, so you must use the latest version of ocvalidate to avoid mistakes. The RestrictEvents is also latest (use pop-up box at upper left to navigate amongst the various kexts): here.

I've left the computer on for ~14 hours with no crash or reboot with new 6900XT GPU, using 11.4 Beta (20F5065a). RestrictEvents was enabled; using MacPro7,1 SMBIOS. So, I'm not certain what led to previous reboots.

Try adding the code below into your Device/Properties section to see if that helps. (You should try this ± SmallTreeIntel82576 kext.) From the pcidevices list, I see that you have IOMMU enabled. This is required for VM, but not bare metal. I keep it disabled. I don't know if this would have any influence on LAN behavior; I've never checked. Disabling it might affect MMIOWhitelist. Also in BIOS, do you have Wake on LAN disabled?

6900XT working, using WEG with boot-arg. RestrictEvents left active; will leave on and see if stable.

@Arrakis I looked at the LAN section of your IORE file (BTW, the TB section is PERFECT!): Was the IORE file without a LAN kext? It looks good as is (and maybe needs a DeviceProperties injection). If a kext was used and the LAN was not working, then maybe try the one I've attached. Also, can you upload the txt or plist file from Hackintool for the PCI section for your mobo? If you do, I can work up a DeviceProperties injection for you to maybe enable better LAN functionality. SmallTreeIntel82576-I211.kext.zip