Contribute
Register

Ethernet problems on Asus Prime Z490-A (Opencore 0.6.2, macOS 10.15.7)

Status
Not open for further replies.
Joined
Jul 5, 2019
Messages
7
Motherboard
ASUS Z490-A
CPU
Intel i7-10700
Graphics
EVGA Geforce GTX 970 SSC
Following Dortania's guide has led me to a (mostly) functioning build of Catalina using opencore 0.6.2, with a few issues:

Primary issue: no ethernet or wifi. Mobo uses Intel I225-V for ethernet, my wifi card is TP-Link TL-WDN4800. Haven't really tried to fix the wifi yet as ethernet would be my primary connection anyway.

Fixes tried so far: Several versions of IntelMausiEthernet, FakePCIID and FakePCIID_Intel_I225_V, with all iterations of enabling and disabling those three, changing the device-id for the relevant PCI-E slot (as per Dortania's guide, with the variations listed within it).

Note: the config and EFI included below have all of the above kexts included, please note I have tried removing and replacing all of them individually to no effect

Other issues: various graphics issues with trying to use the integrated graphics (currently using a GTX 970 as my card for my windows partition which I know is no longer supported), but these are currently more minor problems as I am waiting for the new Radeon RX6800 to be released before I upgrade.


Any help would be greatly appreciated, first time poster so let me know if there is any extra info required.

Thanks

EDIT (18/11/20)
I have also just noticed that I can no longer access the BIOS of my motherboard. I have only just encountered this as an issue when attempting to change the AURA Sync settings. Trying to access it leads to a blank screen; no error messages or hardware reboots. I'm assuming this is an issue with the way I've configured macOS, and I will try removing the SSD catalina boots from to see if that rectifies the issue.
 

Attachments

  • config.plist
    24.2 KB · Views: 145
  • EFI.zip
    2.1 MB · Views: 182
Last edited:
WiFi:
Your TP-Link TL-WDN4800 isn't supported in Mojave or Catalina. It uses an Atheros chipset that Apple stopped supporting with the release of Mojave.

To get it working in Catalina you need to add these two kexts to your /OC/kexts folder and config.plist:
  • AirPortAtheros40.kext
  • ATH9KInjector.kext
Copies of the two kexts are attached below.

I am assuming you already have a recent version of Lilu.kext installed, otherwise you would never have been able to boot your system with OpenCore.

Ethernet:
According to the Dortania guide for Comet Lake systems you don't need any additional kexts for your I225-V Ethernet port. Adding this F2150000 Device-ID to the DeviceProperties section of your config.plist, as instructed in the Comet Lake guide, is supposed to trick macOS into believing the Ethernet port is an I255-LM and using the I210 kext that is part of macOS Catalina.

Adding the FakePCIID kexts may not help, it may just confuse the system. As you have the recommended device ID in your /OC/config.plist, associated with one of the two possible paths.

Have you checked to see which path your Ethernet port uses? Hackintool > PCI tab should show the path for the Ethernet port. As the Comet Lake boards are still fairly new, there may be more than two possible paths. Your board may need a different path set for the Device ID trick to work.
 

Attachments

  • Atheros fix.zip
    659.5 KB · Views: 188
An update following the above advice:

WiFi:
Included Atheros fix kexts had no effect; Airport remains non-functional with seemingly no change.
Install 1080211Family.kext (uploaded as zipped) to your Mojave System Disk's Library /Extensions , System Library/Extensions folder using any of the following ->Kext Utility|Kext Wizard/KextBeast
Tried the above kext from another thread, also to no effect.


Ethernet:
You were correct with the suspicion that the path for the port was different, Hackintool listed it as the alternative path from the Dortania guide: PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0). However, the device-id trick on this path resulted in a kernel panic at boot (see attached image). What is interesting is that the original pathway results in no panic, but also no ethernet connection, so I don't really know what is going on there.

What I did note is that, when opening my config.plist file after this panic from my windows (mounting the EFI from the command line and viewing it using Explorer++) is that the data line for the device-id has changed, without my intervention, to 8hUAAA. Any insight into why this might be happening, or if this is the root of my issues? Is there a way to force the device-id I need?

Current EFI and config files included below as well.

Thanks again.
 

Attachments

  • 16-11-2020.zip
    2.6 MB · Views: 90
  • 20201116_173642.jpg
    20201116_173642.jpg
    5.9 MB · Views: 120
I assume you either added a new WiFi device in your System Preferences > Network pane, or checked that one is present in the list of network adapters, as highlighted in the screenshot below.

Screenshot 2020-11-17 at 18.59.48.png.

The change to the device ID isn't so much a change as a different way of showing the same information using Base64 and ASCII. If you were to view the plist in a Plist Editor on a Mac or Hack, you would see the Device ID has not changed. It is just down to the Base64 format that Explorer++ is using to display the data.

Can you post a copy of your PCIe Device information, can be exported from Hackintool. So I can see what is happening with the Ethernet port.

Screenshot 2020-11-17 at 19.14.20.png

Use the highlighted 'Export' function to save the PCIe details. This function will dump four files on the desktop, compress them all and attach them to a post here.
 
I did try to add new devices, yes, but there wasn't an option for WiFi or Ethernet, only VPN, PPoE and 6-to-4. I've included a screenshot below, alongside the PCIe files you asked for.
 

Attachments

  • Screenshot 2020-11-17 at 19.43.11.png
    Screenshot 2020-11-17 at 19.43.11.png
    2.9 MB · Views: 145
  • pcidevices.zip
    5.2 KB · Views: 80
OK, that shows the Device ID as 15F3. The supported i255-LM Ethernet Controller has a device ID of 15F2, which the Dortania OC guide says should work, even with the alternative ACPI path. The kernel panic image you posed above says differently.

The Dortania guide pads out the device ID with '0000'. I am wondering if it would make any difference if you used F2158680 or even 8680F215 in place of F2150000.

None of the third-party Ethernet kexts I have inspected contain the device ID for either the i255-V or i255-LM ethernet port. This includes IntelMausiEthernet.kext, IntelMausi.kext, AppleIGB.kext, SmallTreeIntel82576.kext. So adding any of these kexts would be counterproductive with a zero net gain.

The only kext I have seen with either device ID's is AppleIntelI210Ethernet.kext, which is a plugin for the macOS Catalina IONetworkingFamily.kext. IONetworkingFamily.kext is located in /System/Library/Extensions and protected by the macOS system from tampering. This kext contains the IOPCIPrimaryMatch 0x15F28086 for the LM version of the port.

Given the way Apple have locked down the system, needing to mount the macOS drive in read-write mode etc. I would expect that editing the kext to include the device id for your i255-V port would lead to a kernel panic, even after a permission repair and kernel cache rebuild. Or trying to inject it with OpenCore from the /OC/Kexts folder, with the appropriate config.plist edit.

I have been looking at the other PCIe Device files you provided and the pcidevices.dsl shows a different setup for the i255-V Ethernet port:

External (_SB_.PCI0.RP05.SL05, DeviceObj)
Device (_SB.PCI0.RP05.SL05) // IOReg ACPI path
{
Name (_ADR, 0x00000000)
Method (_DSM, 4, NotSerialized)
{
If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
Return (Package ()
{
"model", Buffer () { "Intel(R) Ethernet Controller I225-V" },
"device_type", Buffer () { "Ethernet controller" },
"AAPL,slot-name", Buffer () { "Internal@0,28,4/0,0" },
})
}
}


I am wondering if there is a way to use this alternative path (_SB.PCI0.RP05.SL05) in a custom SSDT, to trick the system to thinking your i255-v is an i255-LM port. Expressly telling the system to act as if the 0x15F28086 ID is correct for your port.

Unfortunately I think you need help from someone with a bit more knowledge about this type of Hack, my skills are lacking in this department.
 
That's all useful information though, I really appreciate your help so far! I'll continue to experiment with this new info, and I'll update this thread as things progress.

Thanks again!
 
ps: for your BIOS access, i have the same board and also sometimes get the no bios. it goes directly into OpenCore. F2, or DEL key doesn't do any anything.
I found that the only way to get the BIOS back is to select clear NVRAM from open core. then reboot. then the BIOS is accessible again. (still with all my changes in them, it did not reset my bios).
 
That's all useful information though, I really appreciate your help so far! I'll continue to experiment with this new info, and I'll update this thread as things progress.

Thanks again!
my brand new Asus z490 board is also hving issues w/ built-in ethernet.
it's the same i225-v intel


one latest discovery is when i switched cable to higher Cat (from Cat5 to Cat6), the port started working.
 
Last edited:
Status
Not open for further replies.
Back
Top