Atheros HAL: Overview

| Driver | HAL | Supported Hardware | 802.11n support | Debugging |


The Atheros HAL is an abstraction layer which attempts to hide much of the card specific configuration from the rest of the atheros wireless driver.

The HAL takes care of the MAC, baseband and radio. It exports a set of routines which allow the atheros wireless driver to do certain tasks (set channel, configure TX queue, queue TX packet, queue RX buffer, setup interrupts, do calibration, set/get TX power, configure beacon parameters, enter power saving/sleep mode, etc.)

The HAL doesn't keep any kind of state about individual wireless stations; it doesn't handle 802.11 protocol negotiation such as station association or authentication.

It is structured in a way to make it easy to port to another operating system. A minimum set of operating system specific routines are kept in ah_osdep.[ch] in the ath driver directory. These are used by the HAL to do all platform specific tasks such as register/memory manipulation and debugging output.


Directory layout

Chipset? MAC? Baseband? Radio? Huh?

This obviously needs a lot more detail, but a very quick overview should help clear things up.

Atheros wireless solutions traditionally are made up of a variety of modules. You can determine this information from the publicly available HAL source code.

In particular, the AR5212 and later can have different physical radios attached which implement different frequencies. Check out the ar5212Attach() routine in sys/dev/ath/ath_hal/ar5212/ar5212_attach.c for more background.

Later chips (began integrating the radio into the same physical silicon as the MAC/PHY. But the code still exists to support different radio frontends.

EEPROM handling

The Atheros wireless NICs come with EEPROMs which contain various device settings and calibration information. This includes (but isn't limited to):

The EEPROM layouts are documented in sys/dev/ath/ath_hal/ah_eeprom_{v1,v14,v4k,9287}.h.

The EEPROM API provides a consistent API for code to use without needing to know about the version or layout of the underlying EEPROM. This isn't always used - the AR5416 and later chipsets assume a specific EEPROM layout and hard-code access to it.

HAL Capability API

In order for the atheros wireless driver to function with a variety of underlying cards, the various options and configurations of the underlying card need to be somehow available to it in a consistent API that does not depend upon the underlying chipset or code.

The HAL capability API provides this. Each driver determines the set of hardware and software capabilities the specific card has available. The atheros driver then calls the HAL through the capabilities API to determine which features to enable.

Diagnostic API


API layout

HAL API Overview

Further reading


The Madwifi project (now deprecated) began documenting a variety of the atheros wireless driver and HAL functionality.

dev/ath_hal(4) (last edited 2013-09-19 20:21:10 by AdrianChadd)