Jump to content
d5aqoep

Success: AQC107 10 GbE native support in High Sierra 10.13.2

222 posts in this topic

Recommended Posts

Starting with macOS High Sierra 10.13.2 there will be native support for Aquantia AQtion based 10GbE network cards.

digging around in the latest developer beta of 10.13.2 revealed a KEXT named "AppleEthernetAquantiaAqtion.kext".

path to the KEXT: /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/

 

this has to be the 10GbE NIC of the soon to be released iMac Pro. it might be easy to get 10Gb ethernet in the near future...

 

supported PCI Vendor/Device IDs found in the KEXT:

 

Vendor 1d6a -> Aquantia Corp.

 

pci1d6a,1

pci1d6a,b1

pci1d6a,d100

pci1d6a,d107 <<-- AQtion AQC-107

pci1d6a,d108 <<-- AQtion AQC-108 5GbE also supported?

pci1d6a,7b1

pci1d6a,8b1

pci1d6a,9b1

 

possibly compatible cards:

 

ASUS ROG AREION 10G

https://www.asus.com/Motherboard-Accessory/ROG-AREION-10G/

 

Aquantia AQtion AQN-107

https://www.aquantia.com/products/aqtion/nics/

https://s3-us-west-1.amazonaws.com/...tent/uploads/2017/10/AQN-107-Brief-052417.pdf

 

GIGABYTE GC-AQC107 (Works and confirmed)

https://www.gigabyte.com/Motherboard/GC-AQC107

 

ASUS XG-C100C (This one works and confirmed by me)

https://www.asus.com/Networking/XG-C100C/

 

I already have ASUS PCIe XG-C100C card and......

 

Now it is working on my Hackintosh.

 

Here's what I did:

 

1. Used Clover v4380

2. Used OsxAptioFix3Drv-64.efi

3. SBIOS: iMac18,3

4. Update 10.13.3 Beta 4 to 10.13.3 Beta 5 triggered a firmware upgrade of my card and made it compatible. However someone has confirmed that upgrading 10.13.2 to 10.13.3 Beta 6 has also triggered the same firmware upgrade (This is the main thing to do)

 

If upgrading firmware by Apple without checking DeviceID & SubsystemID is a bug and fixed in future, a simple kext patch should also make it compatible for future users.

 

Plus Points by getting this firmware updated:

1. Any card which is AQC107 will run native on macOS from 10.13.2 onwards.

2. No need for any patch or kexts

 

Negatives of this

1. We have to rely on Apple's Aquantia64 drivers found on iMacPro1,1 bootcamp package (Download it using an app called Brigadier on Windows) or download from link given below.

2. Cannot use ASUS's own drivers found on Support site. This might work with future driver updates but cannot guarantee.

3. Card absolutely refuses to work on Ubuntu 17.10 and 18.04 nightly given the change in DeviceID & SubsystemID

t4nCVEn.png

 

fpjTnBw.png

 

jIGAXk6.png

 

I have enclosed my clover EFI folder. Just change the serial number before using it.

 

YAY!!

 

Apple's AQC107 drivers found in iMacPro1,1 bootcamp package.

http://www12.zippyshare.com/v/lAckTVG1/file.html

CLOVER.zip

Share this post


Link to post
Share on other sites
Advertisement

Ohh boy!! I removed the ASUS XG-C100C from the attic and inserted into my Hackintosh running HS 10.13.2 and behold

 

It's getting detected correctly. But network settings shows as network cable unplugged

 

It is working correctly in Windows 10 with driver downloaded from ASUS site so there is no cable unplugged problem.

 

We are so near!!!!!

Share this post


Link to post
Share on other sites

At first glance it looks like the kext's code checks the device subsystem's id and vendor for Apple provided devices and this might be the reason why it refuses to work properly with your ASUS card but this needs further investigation as I only took a quick look at the code.

 

Mieze

Share this post


Link to post
Share on other sites

Ohh boy!! I removed the ASUS XG-C100C from the attic and inserted into my Hackintosh running HS 10.13.2 and behold

 

It's getting detected correctly. But network settings shows as network cable unplugged

 

VGqXtru.pngIt is working correctly in Windows 10 with driver downloaded from ASUS site so there is no cable unplugged problem.

 

We are so near!!!!!

Did you see something like "Starting AXGE:" in kernel log?

Share this post


Link to post
Share on other sites

iMac:~ d5aqoep$ ifconfig -v
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 index 1
eflags=12000000<ECN_DISABLE,SENDLIST>
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
link quality: 100 (good)
state availability: 0 (true)
timestamp: disabled
qosmarking enabled: no mode: none
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 index 2
eflags=1000000<ECN_ENABLE>
state availability: 0 (true)
qosmarking enabled: no mode: none
stf0: flags=0<> mtu 1280 index 3
eflags=1000000<ECN_ENABLE>
state availability: 0 (true)
qosmarking enabled: no mode: none
XHC20: flags=0<> mtu 0 index 4
eflags=41000000<ECN_ENABLE,FASTLN_ON>
state availability: 0 (true)
qosmarking enabled: yes mode: none
XHC0: flags=0<> mtu 0 index 5
eflags=41000000<ECN_ENABLE,FASTLN_ON>
state availability: 0 (true)
qosmarking enabled: yes mode: none
XHC1: flags=0<> mtu 0 index 6
eflags=41000000<ECN_ENABLE,FASTLN_ON>
state availability: 0 (true)
qosmarking enabled: yes mode: none
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 7
eflags=41000180<TXSTART,RXPOLL,ECN_ENABLE,FASTLN_ON>
options=64<VLAN_MTU,TSO4,TSO6>
ether 02:03:93:5b:9c:01
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: inactive
type: Ethernet
state availability: 0 (true)
scheduler: FQ_CODEL
qosmarking enabled: yes mode: none
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 8
eflags=412008c0<ACCEPT_RTADV,TXSTART,ARPLL,NOACKPRI,ECN_ENABLE,FASTLN_ON>
ether 88:63:df:c9:6c:37
inet6 fe80::80f:7d5:6ddf:4732%en1 prefixlen 64 secured scopeid 0x8
inet 192.168.1.155 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
type: Wi-Fi
link quality: 100 (good)
state availability: 0 (true)
scheduler: FQ_CODEL (driver managed)
uplink rate: 233.10 Mbps [eff] / 273.78 Mbps
downlink rate: 233.10 Mbps [eff] / 273.78 Mbps [max]
qosmarking enabled: yes mode: none
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 index 9
eflags=41000080<TXSTART,ECN_ENABLE,FASTLN_ON>
ether 0a:63:df:c9:6c:37
media: autoselect
status: inactive
type: Wi-Fi
state availability: 0 (true)
scheduler: FQ_CODEL (driver managed)
link rate: 10.00 Mbps
qosmarking enabled: yes mode: none
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484 index 10
eflags=413e0080<TXSTART,LOCALNET_PRIVATE,ND6ALT,RESTRICTED_RECV,AWDL,NOACKPRI,ECN_ENABLE,FASTLN_ON>
ether f2:b5:e9:d7:e2:a5
inet6 fe80::f0b5:e9ff:fed7:e2a5%awdl0 prefixlen 64 scopeid 0xa
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
type: Wi-Fi
state availability: 0 (true)
scheduler: FQ_CODEL (driver managed)
link rate: 10.00 Mbps
qosmarking enabled: yes mode: none
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 index 11
eflags=1002080<TXSTART,NOAUTOIPV6LL,ECN_ENABLE>
inet6 fe80::6ca6:a9e7:2f00:befb%utun0 prefixlen 64 scopeid 0xb
nd6 options=201<PERFORMNUD,DAD>
agent domain:ids501 type:clientchannel flags:0xc3 desc:"IDSNexusAgent ids501 : clientchannel"
state availability: 0 (true)
scheduler: FQ_CODEL
qosmarking enabled: no mode: none
Here is how it appears in System Profiler

 

PMeqFtA.png

 

I am unable to manually select speed and autoselect is the only option available.

 

KBT2cVH.png

Share this post


Link to post
Share on other sites

@d5aqoep: The interface is still down. Try to enable it. In Terminal type "sudo ifconfig en0 up" in order to enable it. Please report back what happens after that. Good luck!

 

Mieze

Share this post


Link to post
Share on other sites

@d5aqoep: The interface is still down. Try to enable it. In Terminal type "sudo ifconfig en0 up" in order to enable it. Please report back what happens after that. Good luck!

 

Mieze

Nothing happened. Network cable still unplugged. It works correctly if I boot into Windows.

Share this post


Link to post
Share on other sites

Nothing happened. Network cable still unplugged. It works correctly if I boot into Windows.

What about the kernel logs? Are there any error messages which explain what happened?

 

Mieze

Share this post


Link to post
Share on other sites

What about the kernel logs? Are there any error messages which explain what happened?

 

Mieze

 

Here it is

2017-12-14 21:14:48.207775+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) IO80211Controller::createIOReporters 0x95d71e0dd32e47a1

2017-12-14 21:14:48.208085+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) CCFlags: 0x0, CCLevel: 5 ConsoleFlags: 0x0, ConsoleLevel: -1

2017-12-14 21:14:48.209133+0530 0xea Default 0x0 0 0 kernel: (corecapture) No Service found 1000002c3

2017-12-14 21:14:48.209135+0530 0xea Default 0x0 0 0 kernel: (corecapture) configureInterests - nElements <= 0!

2017-12-14 21:14:48.209139+0530 0xea Default 0x0 0 0 kernel: (corecapture) Failed to configure interests

2017-12-14 21:14:48.209147+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) IO80211Controller::addSubscriptionForThisReporterFetchedOnTimer() Failed to addSubscription for group Chip subgroup Bytes Transferred driver 0x95d71e0dd32e47a1 - data underrun

2017-12-14 21:14:48.209151+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) IO80211ControllerMonitor::configureSubscriptions() failed to add subscription

2017-12-14 21:14:48.209264+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) CCFlags: 0x0, CCLevel: 5 ConsoleFlags: 0x0, ConsoleLevel: -1

2017-12-14 21:14:48.209310+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) CCFlags: 0x0, CCLevel: 5 ConsoleFlags: 0x0, ConsoleLevel: -1

2017-12-14 21:14:48.209334+0530 0xea Default 0x0 0 0 kernel: (IO80211Family) IO80211Controller::start _controller is 0x95d71e0dd32e47a1, provider is 0x95d71e0c566c9ca1

2017-12-14 21:14:48.216301+0530 0xdc Default 0x0 0 0 kernel: (AppleEthernetAquantiaAqtion) WARNING: using bogus hardcoded station address

2017-12-14 21:14:48.234582+0530 0xdc Default 0x0 0 0 kernel: (AppleEthernetAquantiaAqtion) AssertMacros: status, file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleEthernetAquantiaAqtion/AppleEthernetAquantiaAqtion-16.30.11/AppleEthernetAquantiaAqtion/if_axge.cpp, line: 5785, value: 0

2017-12-14 21:14:48.234654+0530 0xdc Default 0x0 0 0 kernel: (AppleEthernetAquantiaAqtion) AssertMacros: status, file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleEthernetAquantiaAqtion/AppleEthernetAquantiaAqtion-16.30.11/AppleEthernetAquantiaAqtion/if_axge_kdb.cpp, line: 71, value: 0

Share this post


Link to post
Share on other sites

@d5aqoep: Initialization of the chip fails but I'm still unsure why.

 

Try booting with kernel parameter "apple-axge-debug=0xff" and send me the kernel logs again.

 

Mieze

Forum is acting up a bit and not allowing me to edit my post but I have found out that the mac address which 10.13.2 is showing is not that of my ASUS XG-C100C card.

 

Windows shows totally different mac address.

 

We just need kext patch for clover to start up this card.

Share this post


Link to post
Share on other sites

Forum is acting up a bit and not allowing me to edit my post but I have found out that the mac address which 10.13.2 is showing is not that of my ASUS XG-C100C card.

 

Windows shows totally different mac address.

 

We just need kext patch for clover to start up this card.

I disassembled the code which tries to read the permanent MAC address from the chips register space and compared it with the sources of the linux driver. The address you've got is a default value which is used when getting the real MAC address fails. From my own driver projects I know that this is something which usually results from a DSDT problem making it impossible for the driver to access the hardware. Are you injecting a patched DSDT/SDDT? Does your Clover config file include the fix regions patch?

 

Mieze

Share this post


Link to post
Share on other sites

I disassembled the code which tries to read the permanent MAC address from the chips register space and compared it with the sources of the linux driver. The address you've got is a default value which is used when getting the real MAC address fails. From my own driver projects I know that this is something which usually results from a DSDT problem making it impossible for the driver to access the hardware. Are you injecting a patched DSDT/SDDT? Does your Clover config file include the fix regions patch?

 

Mieze

 

I am not using any DSDT/SSDT patches. My EFI/Clover/ACPI/Patched folder is empty. I am unsure if my Clover config includes fix regions patch.

Share this post


Link to post
Share on other sites

I am not using any DSDT/SSDT patches. My EFI/Clover/ACPI/Patched folder is empty. I am unsure if my Clover config includes fix regions patch.

If not patched DSDT then no need to patch regions.

Share this post


Link to post
Share on other sites

the source code for the linux driver can be downloaded from ASUS. maybe this'll help?

 

http://dlcdnet.asus.com/pub/ASUS/wireless/XG-C100C/DR_XG_C100C_5005_Linux.zip

I used the source code from https://www.kernel.org

Any progress on this?

No, but please send me a complete ACPI dump of your machine and an IOReg dump (use IORegistryExplorer V3.0.2 to create it) with the card installed.

 

Mieze

Share this post


Link to post
Share on other sites

I used the source code from https://www.kernel.org

No, but please send me a complete ACPI dump of your machine and an IOReg dump (use IORegistryExplorer V3.0.2 to create it) with the card installed.

 

Mieze

Linux driver loops through BARs to map IO memory:  https://elixir.free-electrons.com/linux/v4.14.9/source/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c#L121

 

MacOS uses kIOPCIConfigBaseAddress0 (0x10) directly: 0x18ca calls mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0),

 

 

 __ZN27AppleEthernetAquantiaAqtion14setup_slave_ioEv:        // AppleEthernetAquantiaAqtion::setup_slave_io()

0000000000001872         pushq      %rbp                                        ; CODE XREF=__ZN27AppleEthernetAquantiaAqtion5startEP9IOService+249

0000000000001873         movq       %rsp, %rbp

0000000000001876         pushq      %rbx

0000000000001877         pushq      %rax

0000000000001878         movq       %rdi, %rbx

000000000000187b         movq       0x140(%rbx), %rdi

0000000000001882         movq       (%rdi), %rax

0000000000001885         movl       $0x1, %esi

000000000000188a         callq      *0x8d8(%rax) // __ZN11IOPCIDevice18setBusMasterEnableEb

0000000000001890         movq       0x140(%rbx), %rdi

0000000000001897         movq       (%rdi), %rax

000000000000189a         movl       $0x1, %esi

000000000000189f         callq      *0x8c8(%rax)  // __ZN11IOPCIDevice15setMemoryEnableEb

00000000000018a5         movq       0x140(%rbx), %rdi

00000000000018ac         movq       (%rdi), %rax

00000000000018af         xorl       %esi, %esi

00000000000018b1         xorl       %edx, %edx

00000000000018b3         callq      *0x8d0(%rax) // __ZN11IOPCIDevice11setIOEnableEbb

00000000000018b9         movq       0x140(%rbx), %rdi

00000000000018c0         movq       (%rdi), %rax

00000000000018c3         movl       $0x10, %esi

00000000000018c8         xorl       %edx, %edx

00000000000018ca         callq      *0x908(%rax)   // __ZN11IOPCIDevice27mapDeviceMemoryWithRegisterEhj

00000000000018d0         movq       %rax, 0x150(%rbx)

00000000000018d7         testq      %rax, %rax

 

00000000000018da         je         loc_192f  // jump to failure or get virtual address from memory map and save to 0x658(%rbx)

 

 

The registers seem to be offset by 0x10, linux reads register 0x374  for MAC address.

https://elixir.free-electrons.com/linux/v4.14.9/source/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c#L396

 

MacOS reads 0x364,

 

  __ZN27AppleEthernetAquantiaAqtion10get_lladdrEv:        // AppleEthernetAquantiaAqtion::get_lladdr()

 

000000000000292c         pushq      %rbp

     ... ...

     loc_2a48:

0000000000002a48         movl       $0x364, %esi                                ; CODE XREF=__ZN27AppleEthernetAquantiaAqtion10get_lladdrEv+125

0000000000002a4d         addq       0x658(%rbx), %rsi

0000000000002a54         leaq       var_2C(%rbp), %r14

0000000000002a58         movq       %rbx, %rdi

0000000000002a5b         movq       %r14, %rdx

0000000000002a5e         call       __ZN27AppleEthernetAquantiaAqtion9reg_get32EPjS0_ ; AppleEthernetAquantiaAqtion::reg_get32(unsigned int*, unsigned int*)

0000000000002a63         movl       $0xa0, %esi

0000000000002a68         addl       (%r14), %esi

0000000000002a6b         movl       %esi, (%r14)

0000000000002a6e         leaq       var_20(%rbp), %rdx

0000000000002a72         movl       $0x8, %ecx

0000000000002a77         movq       %rbx, %rdi

0000000000002a7a         call       __ZN27AppleEthernetAquantiaAqtion7ram_getEjPhm ; AppleEthernetAquantiaAqtion::ram_get(unsigned int, unsigned char*, unsigned long)

0000000000002a7f         movl       %eax, %r14d

0000000000002a82         testl      %r14d, %r14d

 

Linux writes some random stuff https://elixir.free-electrons.com/linux/v4.14.9/source/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c#L385

before reads MAC address.

Share this post


Link to post
Share on other sites

@d5aqoep and ydeng: Thanks for the IOReg dump. The BARs might be the right approach. According to the IOReg dump, the chip has 3 device memory areas pointing to a 64K space (function unknown), a 4K space which points most likely to the MSI-X vector space (irrelevant to macOS) and a 4M space. One of them, either the 64K or the 4M space must be the one pointing to the chip's control register space. Provided the order they appear in IOReg corresponds to the BARs order, the 64K space would be the first and the one Apple's driver is using but it could be the wrong BAR. We could make the driver use the correct BAR with a patch but in order to create it, we need to know the physical layout of the BARs (order and if they are 32bit or 64bit BARs).

 

Can someone post a dump of the chip's PCI config space (created with lspci under Linux or macOS or RW-everyting under Windows)?

 

Mieze

Share this post


Link to post
Share on other sites

Mieze, on 01 Jan 2018 - 12:42 AM, said:

@d5aqoep and ydeng: Thanks for the IOReg dump. The BARs might be the right approach. According to the IOReg dump, the chip has 3 device memory areas pointing to a 64K space (function unknown), a 4K space which points most likely to the MSI-X vector space (irrelevant to macOS) and a 4M space. One of them, either the 64K or the 4M space must be the one pointing to the chip's control register space. Provided the order they appear in IOReg corresponds to the BARs order, the 64K space would be the first and the one Apple's driver is using but it could be the wrong BAR. We could make the driver use the correct BAR with a patch but in order to create it, we need to know the physical layout of the BARs (order and if they are 32bit or 64bit BARs).

 

Can someone post a dump of the chip's PCI config space (created with lspci under Linux or macOS or RW-everyting under Windows)?

 

Mieze

Happy New Year everyone.

Here is the screenshot of RW-everything ad PCI dump one is raw and other is binary. If something else, let me know.

6obqT5H.png

rw-everythng.zip

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×