Go back –> Atheros Linux wireless drivers
ath9k_htc is a driver for new Atheros devices which require firmware. ar9271 is the first targeted supported device, its an 802.11n 1-stream USB chipset. This page covers its development.
- ar9271 hardware details
- Supported products
- Subscribe to this page!
- Mailing list
- Open firmware ?
- ar9271 hw support
- Sharing code between ar9271 and ar6k
- Atheros host target communication
- Bringing up the module
ar9271 hardware details
ar9271 is the next generation of the Atheros 802.11n USB solutions. Contrary to ar9170 it uses an Atheros MAC – ar9170 is using a Zydas MAC. Some feature details to keep in mind:
- 802.11n 1x1 2.4 GHz - 1 stream:
- HT20 - MCS 7, highest MCS index for single stream
- long guard interval (800 ns) @ 65 Mbit/s max theoretical
- short guard interval (400 ns) @ 72.2 Mbit/s max theoretical
- HT40 - MCS 7, highest MCS index for single stream
- long guard interval (800 ns) @ 135 Mbit/s max theoretical
- short guard interval (400 ns) @ 150 Mbit/s max theoretical
- HT20 - MCS 7, highest MCS index for single stream
- TCP/IP throughout rates expected at 2.4 HT40: ~70-95 Mbit/s
- 2 external antennas for TX/RX antenna diversity
- Internal embedded CPU
- TP-Link TL-WN721N
Subscribe to this page!
You should subscribe to this page so you can get e-mail updates on changes and news for ar9271 automatically. You'll get an e-mail as soon as this page gets updated.
Since ar9271 support is not yet upstream and the driver is still being worked on we use the Linux driver project mailing list to track its development and patches:
ar9271 support is still under development. You can only upload the firmware to the device right now. Next step is to get a mac80211 basic driver up and running with monitor support.
If you'd like to work on development for ar9271 get the code first:
If you do not have hardware and are serious about working on a mac80211 driver for ar9271 please contact firstname.lastname@example.org, Atheros is looking to work with the community by providing hardware samples to interested developers. Prior to contacting email@example.com for a device though please consider sending patches to help with the existing code. The HTC/HIF code could use a lot of help to be more upstream-friendly first. You will need hardware once we start working on the mac80211 driver.
Setting up your environment
To work on this you'll need to git clone wireless-testing:
Then wget this file:
You can apply these patches onto your wireless-testing as follows:
git am all-2009-09-23.patch
Configuring your kernel
You'll need to compile and install wireless-testing, before you do so be sure to enable these configuration options:
CONFIG_ATH_COMMON=m CONFIG_ATH9K=m CONFIG_ATH_DEBUG=y
ATH9K is not required but we require you to select it to enable ATH9K_HW for now as ATH9K_HTC is not yet an option upstream.
Boot into your new kernel and you can begin hacking.
ar9271 requires firmware, you can get ar9271fw from:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9271/ar9271.fw sha1sum 9ee744d58e68e531cb2ca910c3980e1f23985226
This firmware was built from an original driver hexed string and converted for use with request_firmware(). For details you can check out:
Open firmware ?
We are first trying to write the driver for ar9271, however one interested community member has expressed interest in working on an open firmware for ar9271. We are working with this community member on trying to get this done but we have nothing certain or guaranteed.
- Initializing WMI (mcgrof)
- HW bring up (mcgrof)
- More HTC/HIF/WMI cleanup - for upstream inclusion
- HTC is designed for only one device - fix this
- Fill in gaps on the mac80211 driver, ath9k_htc.c
You can send patches to:
To: firstname.lastname@example.org Cc: email@example.com
ar9271 hw support
Initial hw support for ar9271 has been committed onto wireless-testing. These patches only added the necessary changes onto ath9k to support the ar9271 hardware. HTC/HIF_USB modules are already on its way on being ported. The last step to support ar9271 will be a new mac80211 driver which makes uses of HTC/HIF_USB and the ath9k hw routines as well as the shared ath.ko for.
ar9271 and ar9170 seem to share a few things, one of which is firmware upload. ar9271's firmware upload routine was modified to make it match ar9170's as much as possible to share it on ath.ko. The only difference between the firmware upload is on ar9170 you can sometimes not account for the success of the last urb submitted which tells the harware the firmware was loaded.
Sharing code between ar9271 and ar6k
Sharing code between ar9271 and ar6k may be possible as the same HTC framework is used. ar6k uses ethernet-like frames though so more review is required.
Atheros host target communication
The Atheros host / target communication framework consists of 3 parts:
- HTC - Host Target Communication
- HIF - Host Interface Layer
- WMI - Wireless Module Interface
Bringing up the module
For HTC devices there is first a module which registers the device IDs to the kernel for the specific transport they use. For ar9271 this happens to be USB, the module in which ar9271 is registered to the kernel as a USB device is ath_fw_usb.c. Upon USB probe ath_fw_usb.c will call ath_hif_usb_probe() to register the new probed usb interface with the HIF USB transport module. ath_hif_usb module will then a struct hif_device_usb for the interface, assign this structure to the usb interface (usb_set_intfdata(interface, hif_dev)), request firmware for it from userspace, allocate URBs for it, upload the loaded firmware to the device, and then notifies HTC of this new functional HIF device ( ... this is still being written ... )
ar9271 relies on the Atheros HTC (Host/Target Communication) for the communication between the host CPU the device is present on and between the ar9271 CPU (target).
The Atheros HTC defines a very basic API which allows designers to build protocols of communication for a specific target (device with CPU) and an interconnect/bus. The protocols of communication are Operating System agnostic and architecture agnostic.
When necessary the HTC APIs can be extended to accommodate different interconnects. HTC can also be extended to make enhancements which would make communication more suitable for an Operating System.
It should be noted HTC was originally implemented to accommodate the Atheros AR6000 wireless chipset on Linux and Windows mobile for use on SDIO and SPI.
HTC TX / RX completion callbacks
These TX and RX callbacks in HTC will themselves check the endpoint target and call a respective callback for each endpoint. Control messages are processed via the endpoint 0. Only the RX completion callback makes use of the control endpoint, messages in the control endpoint for TX are disregarded. Buffers are always freed in the TX completion HTC callback. Buffers are only freed by the RX completion HTC callback if the endpoint target does not have a registered callback or if the endpoint is the control endpoint.
HTC Control messages
Messages sent to the RX completion HTC callback on the control endpoint have a message ID which identifies what control message is being received. There are 3 HTC control messages IDs:
When this message is received HTC calls HTCProcessTargetReady().
When this message is received HTC calls HTCProcessConnectionRsp().
When this message is received HTC calls HTCProcessConfigPipeRsp().
The Host InterFace layer, originally designed first for the AR6000 device, is the interconnect driver interface used by a driver. It uses HTC to register callbacks for device insertion and removal, for registration with HTC. ar9271 is the first HIF USB device, as such we have implemented its own HIF driver for USB. The ar9271 module would use the HIF layer to allocate the URBs needed for communication from/to the device. The HIF layer module also defines the callbacks to deal with URBs after being submitted for processing. During initialization the HIF layer uploads the firmware to the ar9271 device upon device probe.
The Wireless Module Interface, also designed first for AR6000, a wireless protocol of communication for Atheros wireless devices using a host/target split. WMI defines commands which you can issue to the target firmware or that the target firmware can send back for processing. WMI also has events for which callbacks are registered, each event has registered callback.