Raw WiFi access (for Linux)

Okay, let's get this party started!

One of the biggest gaps in functionality for Linux right now is support for the wireless network adapter.

As a bit of background, networking on the Wii is implemented using several modules, working together:

* SO ("socket") -- this layer vends the Berkeley Socket API (connect, listen, send, receive, etc).

* NCD ("Network Configuration Driver") -- this handles configuring the network adapters, choosing the appropriate one and obtaining an IP for it

* ETH (USB Ethernet driver) -- this is a driver for the official Nintendo USB Ethernet adapter

* WD ("Wireless Driver"?) -- this driver controls the lower-level WL driver; it also is the driver that contains the logic to deal with "Nitro" (DS) connections

* WL ("Wireless Link"?) -- this driver interfaces to the BCM43xx wifi adapter, probably over SDIO.

Currently, libogc uses the network adapter through SO, the high-level interface. This is not an appropriate interface for Linux to use, because its IP stack would really rather be dealing with raw frames. There are evil hacks that can interface that with a BSD-sockets layer, but we really don't want to go there. Networking is supported under Linux using its native driver for the USB-Ethernet adapter, in place of ETH and the rest of the stack.

What we need to do is either find a way to directly talk to the BCM43xx chipset from the Broadway (somewhat unlikely), or find an appropriate interface amongst the above-mentioned modules.

I've placed some info on the Wiibrew Wiki, but I'll expand here in the hopes that someone will take this project and push it further:

* WL -- /dev/wl0 seems to have exactly one ioctl -- 2 -- and it takes in a command ID which is in the range 0-300 or so. If you could match these up cleanly with, say, these docs -- that would be a viable option.

* WD -- WD talks to WL; in part, this is probably so that it can disable normal WiFi and switch to bizarro DS WiFi, but that doesn't mean we couldn't use it. It exposes /dev/net/wd/command, which looks like it might have useful functions like "send frame", but to figure out how you need to call that, you'll need to reverse SO.

* SO -- There is a high-level API (/dev/net/ip/top) that is unsuitable. This driver talks to both the usbeth driver and the wd driver via two similar interfaces -- /dev/net/usbeth/top and /dev/net/wd/top. That seems like a good candidate, because it's an abstraction point over general network interfaces. There is also a /dev/net/ip/bottom, which is probably a low-level version of /dev/net/ip/top -- it would also be a good candidate, but I don't see any code using it yet, so again, you'd have to reverse SO to figure out how it works.

Cheers for the great info as always.
This gotta be gold for Nuvalo :)

Well, yet another solution for this problem may be the ios_stub with IPC functions (just like the python client) once it's done. The whole libusb-like interface the IOS exposes also isn't fully suitable for a kernel module - isobel already demonstrated that it's possible but he wasn't quite happy with that solution either the last time i talked to him. That was a few weeks before the release though so he could've changed his opinion.
Having raw access to starlet's hardware registers is at least in my opinion the sanest solution to add new functionality to linux. The big disadvantage is that none of the current modules would work and that most of them would need to be rewritten and that linux would depend on a custom IOS. But that will happen if we want to read DVDs with every modchip on the other hand.
It would nevertheless require reverse engineering of the hardware registers for the wifi adapter if there currently isn't a driver for it.

Linux already has a driver for this chipset -- bcm43xx -- but I don't know what Starlet registers are used to poke at it in the Wii, at any level.

I thought the wifi card was placed on a mini pci buss, according to your (bushing's) schematic. For Linux to be able to work with the wifi card the first goal would be access to this buss instead, since the system can just figure the rest out on it's own.

There's some debate over that; I originally had it as connected via SDIO, but was peer-pressured at the last moment to change it to MiniPCI. I now regret my moment of weakness.

The Broadway can't access the bus directly, either way. (and what is this "figuring out on its own" you speak of ?!!?)

Oh, that is just refferering to the generic PCI support that most OSes has by now.

... which is there because people implement it when they port an OS to a new platform ...

I posted this on the Wiibrew wiki -- but it might get more visibility here.

We need three pieces on order to talk the WiFi card from the PPC without using the IOS 'WL' driver:

1) High-level BCM43xx driver
2) Low-level glue to poke at registers on the Wii
3) A way for the PPC to poke at registers that only the ARM side can access.

#1 has existed for a while. I don't know much about them, but there are at least three Linux drivers for these chips -- b43, b43legacy, bcm43xx -- which are some combination of open source and binary blobs. They generally talk to these chips via PCI (or some variation thereof).

#2 I just found by accident. Earlier this year, Broadcom seems to have posted the source to a SDIO-based BC43xx driver for Linux at http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=summary. I suspect that most of the code compiled into the WL driver in IOS exists as GPL'd source code in that repository (based on comparing the source to my disassembly of the IOS driver). If you can get that thing to compile, that might be all the code you need. I don't have time to take this on as a project right now, but if someone else wants to take a stab at it I can try to answer any questions about the Wii-specific hardware.

#3 isn't too hard to do with a hacked IOS, but we hope to be releasing part of BootMii ("mini") in the near future. Among other things, it will act as a simple proxy between the PPC and the WiFi card's SDHC registers.

[forum.wiibrew.org]
regards

yeah, that's the driver we looked at last year.