Hacking Hardware We can now use the AX88772B on the Wii U

  • Thread starter Thread starter SDIO
  • Start date Start date
  • Views Views 10,181
  • Replies Replies 50
  • Likes Likes 18

SDIO

Well-Known Member
Member
Joined
Feb 13, 2023
Messages
4,421
Solutions
1
Reaction score
1,783
Trophies
2
Age
30
XP
3,787
Country
Germany
Since the Ethernet Adapter compatible (AX88772) with the Wii U get scarce I made a patch that uses the AX88772B instead: https://github.com/StroopwafelCFW/wafel_ax88772b
This only affects the Wii U side. So in vWii oder Wii VC it still won't work.

To use this, install ISFShax first: https://gbatemp.net/threads/how-to-set-up-isfshax.642258/ (it's also possible to use DeFuse to load it with the fw.img loader every boot, but ISFShax is likely what you want)

For now the patch is only for the AX88772B
The latest version has a number of adapters it works with, I might also be able to make it work with other adapters from the AX88772 series. Some adapters just have their vid and pid changed.
So if you have such a adapter, please respond here, then I can send you a patch for that and we can see if it works.


For vWii have a look here: https://gbatemp.net/threads/ax88772b-c-usb-ethernet-patcher-working-on-vwii.680252/#post-10830815

To use a Apple A1277 USB2.0 Fast Ethernet Adapter, look at this post: https://gbatemp.net/threads/we-can-now-use-the-ax88772b-on-the-wii-u.670646/post-10649148 and this one: https://gbatemp.net/threads/we-can-now-use-the-ax88772b-on-the-wii-u.670646/post-10803994
 
Last edited by SDIO,
That is indeed a great news!! Now pls go ahead and add C/D postfix ones, then we can have indeed budget NIC on wiiu and maybe transfer games via FTP....
 
I am not sure about the D and E. Because these support NCM. The datasheet says they have also a mode for a proprietary driver but not sure if that is compatible with the one in the Wii U. Because since the C revision they removed all details about the USB interface from the datasheet.

So someone with a newer revision would have to test
 
The A one should require even less patching. Just the pid needs to be patched and we need that anyway because Apple has a custom vid and PID.

Can you just send me the VID and PID of the adapter and then I can make the patch for you
 
Here is the patch, it just contains:
C:
U32_PATCH_K(0x12456dd0, 0x05ac1402);

If you already have isfshax, you just extract the zip and put the ipx file into the ios_plugins folder
 

Attachments

  • Love
Reactions: KeinesR
Test report:
My NIC is a 88772B with PID_722B and VID_0B95:
upup.png

it works using version 1.0 ax88772b.ipx, but will stuck at boot if using 2.0 5ax88772.ipx.

Latest fw.img. Has nothing to do with the naming. Tried both on SD and on SLC results are the same.
Post automatically merged:

Test report:
My NIC is a 88772B with PID_722B and VID_0B95:
upup.png

it works using version 1.0 ax88772b.ipx, but will stuck at boot if using 2.0 5ax88772.ipx.

Latest fw.img. Has nothing to do with the naming. Tried both on SD and on SLC results are the same.

Update:
Oh Damn didn't see this Needs at least stroopwafel 1.2: https://github.com/StroopwafelCFW/stroopwafel/releases/
Post automatically merged:

Update 2: OK using 1.2 of 00core.ipx I can boot into OS fine with version 2.0
 
Last edited by neverendsDull,
  • Like
Reactions: SDIO
USB\VID_05AC&PID_1402\1A0D02
I have the same adapter (Apple A1277), and I successfully changed the vid and pid to the ones of the original 0b95:7720

There is a tool which allows reading and writing the configuration eeprom: https://github.com/karosium/asix_eepromtool
I first tried just replacing the vid pid in both locations and that mad the adapter show up as 0b95:772a, which is strange since 772a is nowhere to be found in the rom, but that would be the correct pid for the AX88772A, which the apple one is.
I then flashed just the whole ROM from a UGREEN AX88772 (without A) to the apple one and then the apple one also showed up as 0b95:7720.
I then checked the chipcode of my UGREEN adapter which was bought as the AX88772 one and the chipcode shows it is the A. So it seems that either UGREEN or the amazon seller faked the PID.

Since the A is so similar to the original one, this should work for every AX88772A, which doesn't have the PID change feature fused off. This won't work for the AX88772B and later, since it needs the wii u to write a different value to one register.

I attached the ROM of the ugreen one, that transforms the A into the non A. Try at your own risk. Be careful, this might brick the adapter. Also keep two backups of the original rom somewhere save. Also if you flash it to multiple adapters, you should change the mac address (I recommend to the original one of your adapter) in the ROM or else it would cause problems if they are used on the same network.

With this it should work on a completely stock Wii / Wii U / Switch

EDIT: instead of using the attached ROM, you can get one with a randomly generated MAC here, to avoid conflicts: https://itwasntmewhofarted.com/ethernet/
 

Attachments

Last edited by SDIO,
Another update:

Version2.0 cannot recognize 88772D with the following VID_0B95 and PID_1790, this is Ugreen CR110/30305:
88772DVID.png


Dig into Windows' driver inf and found the following:
INI:
[USB.NTamd64.10.0...22000]
%AX88178A.DeviceDesc% = AX88179.Ndi,USB\VID_0B95&PID_178A
%AX88179.DeviceDesc% = [B]AX88179.Ndi,USB\VID_0B95&PID_1790&REV_0100[/B]
%AX88179A.DeviceDesc% = [B]AX88179A.Ndi,USB\VID_0B95&PID_1790&REV_0200[/B]
%AX88772D.DeviceDesc% = [B]AX88772D.Ndi,USB\VID_0B95&PID_1790&REV_0300[/B]
%AX88279.DeviceDesc% = AX88279.Ndi,USB\VID_0B95&PID_1790&REV_0400
%Sitecom_LN-032.DeviceDesc% = AX88179.Ndi,USB\VID_0DF6&PID_0072
%Lenovo_OneLink_Dock.DeviceDesc% = AX88179.Ndi,USB\VID_17EF&PID_304B
%Toshiba.DeviceDesc% = AX88179.Ndi,USB\VID_0930&PID_0A13
%Samsung.DeviceDesc% = AX88179.Ndi,USB\VID_04E8&PID_A100
%Belkin.DeviceDesc% = AX88179.Ndi,USB\VID_050D&PID_0128
%MCT.DeviceDesc% = AX88179.Ndi,USB\VID_0711&PID_0179
%AT_Giga.DeviceDesc% = ATGiga.Ndi,USB\VID_07C9&PID_000E
%AT_100M.DeviceDesc% = AT100M.Ndi,USB\VID_07C9&PID_000F
%AT_UMC2000SP.DeviceDesc% = ATUMC2000SP.Ndi,USB\VID_07C9&PID_0010
%AT_UMC2000T.DeviceDesc% = ATUMC2000T.Ndi,USB\VID_07C9&PID_0011

Check here:

Code:
%AX88179.DeviceDesc% = AX88179.Ndi,USB\VID_0B95&PID_1790&REV_0100
%AX88179A.DeviceDesc% = AX88179A.Ndi,USB\VID_0B95&PID_1790&REV_0200
%AX88772D.DeviceDesc% = AX88772D.Ndi,USB\VID_0B95&PID_1790&REV_0300

Seems 88772D is the "cripped/inferior" units of the AX88179 that Switch uses!
Also searched ASIX's website, found 88772A/B/C use different drivers than 88772D, so I think 88772D is unlikely to be supported by Wii U's built-in driver.
 
I got the AX88772E yesterday, which shows up as AX88179 too. When I added the PID for that it was detecked, but the link didn't come up. I first assumed they sent me the wrong thing but locking at the linux driver and your post it seems I got the right thing... So yeah the C is likely the last that will work with this plugin. If you want to you can add the pid of your adapte rto the plugin and check what happens, but I expect the same as mine.

I will have a look at the driver, maybe it will behave similar enough if initilized right, but the problem is they removed the register information from the datasheet after the B. so not knowing what a bit in a register does makes it much harder or almost impossible.
 
Added the following to your newest source main.c

C:
{ 0x0b95, 0x1790 }, // AX88772D UGreen

Compiled a 5usbeth.ipx, transfer it to SLC, still no juice, the console reported no LAN adapter connected. Switch back to the 88772B NIC and it worked, so the file compiled is OK, which means, yes, 88772D is no go.
 
So the only one left to test would be the C.
Looking at the driver inside Linux I might try to implement the initialization for the 88179, but I doubt that that would be enough. I think also the format of the headers for the data changed and I am not even sure yet where they are processed in IOSU.
 
All right got my hand on 88772C. Good news, suppoted. Bad news, its P/VID are....

88772C_772B_REV_0002.png


So of course it is supported, just another variant of 88772B...
Anyway I think we can safely assume all devices below(adapted from Windows installation inf) can be supported by WiiU's built-in driver:

INI:
[USB.NTamd64]
%AX88772.DeviceDesc% = AX88772.Ndi,USB\VID_0B95&PID_7720
%AX88772A.DeviceDesc% = AX88772A.Ndi,USB\VID_0B95&PID_772A
%MSI.DeviceDesc% = AX88772A.Ndi,USB\VID_0DB0&PID_A877
%Nokia.DeviceDesc% = AX88772A.Ndi,USB\VID_0421&PID_772A
%MVCI.DeviceDesc% = AX88772.Ndi,USB\VID_125E&PID_180D
%AX88772B.DeviceDesc% = AX88772B.Ndi,USB\VID_0B95&PID_772B&REV_0001
%AX88772B.DeviceDesc% = AX88772B.Ndi,USB\VID_054C&PID_098E
%AX88772C.DeviceDesc% = AX88772B.Ndi,USB\VID_0B95&PID_772B&REV_0002
%AX88772B.DeviceDesc% = 7E2B.Ndi,USB\VID_0B95&PID_7E2B&REV_0001
%LenLan.DeviceDesc% = AX88772B.Ndi,USB\VID_17EF&PID_7203&REV_0001
 
The C one having the PID of the B one isn't a problem, we can differentiate them by the chipcode (like I already do for the A and earlier vs B and later, but since it seems to work we don't need that going by your report for the C).

I will add the other VID/PIDs at some point. If you want you can also do a PR with all the VIDs and PIDs that work. I am still looking at the 88179. But it is just so different. Even the commands have different codes.
 
This is great, I'm surprised it went under my radar! I already have a natively compatible adaptor, but I'm curious, was this solely done because of wider AX88772B availability, or was there another reason? With a little digging, it looks like the only difference between B and base variant is wider operational temperature range.
 

Site & Scene News

Popular threads in this forum