Atheros releases ath5k HAL code

Some other chipsets, including the Intel ones mentioned, do a lot of work on an embedded CPU core in the WiFi module. This often includes basic 802.11 management, such as the entire association sequence, beacon processing, etc. As free software developers, we generally loathe this, because we rarely have access to this code, and so are unable to modify it to add features or fix bugs.

The AR5xxx series (and companion 2.4GHz-only AR2xxx series) does not have this kind of heavyweight firmware. Most processing is done on the host. The hardware clearly has some kind of lightweight microcode, because it is able to do things like sniff the TIM field out of beacons automatically (although not reliably, last I checked), and it parses packets well enough to do encryption and decryption on the fly. However, this microcode has never been field upgradable as far as I know.

The AR6xxx series uses essentially the same MAC and PHY structure as the AR5xxx series. However, it is one complete package, with an embedded CPU added. The embedded CPU runs heavyweight firmware and provides an alternate API for talking to the HAL, through a restricted message-passing interface that is more reminiscent of older chipsets like PRISM. Most of the 802.11 association management is done within the WiFi module, like it is on PRISM, the Intel chipsets, etc. In this case, the HAL that, for the AR5xxx chips, would run on the host CPU, is actually in the software that runs on the embedded CPU. Considerable analysis shows that this HAL is virtually identical to the AR5xxx HALs that they have published source for.

In short, this release appears to provide the source code for all of the upgradable software support for the AR5xxx a/b/g series, with the AR5xxx n series already having been released. I have not seen the source code for the AR6xxx firmware yet, though.

You might wonder why Atheros seems to be going backward by switching to heavyweight firmware in the AR6xxx series. This is largely an issue of mobile hardware design. It is highly desirable for handheld units to be able to put the host CPU to sleep as much as possible and let the WiFi run autonomously to maintain connectivity, and in some cases do wake-on-wireless. In addition, most embedded chipsets use slower and higher latency interfaces, like SDIO, as compared to the PCI bus that the AR5xxx series depends on. For all of these reasons, it's desirable to do more of the 802.11 management on the WiFi module, using a low-complexity and low-power CPU core.