-- Hardware --
Conventions
I'm following the conventions of the USB specification to name
16-bit values words and 32-bit values double words (dwords).
Overall
one config, one interface
four non-control endpoints
1: bulk out // data packets
2: bulk in // data packets
3: int in // status info
4: bulk out // register accesses
Architecture
The ZD1211 chip provides the USB interface for the ZD1205
controller, which appears to provide media access control and
baseband processing. The ZD1211 connects to an RF module, which
appears to be the RF2559 on my hardware. But other RF modules have
been seen in the wild as Airoha AL2230.
Address Space
The ZD1211 provides an address space of word-size registers addressable
by word-size addresses. 65536 addresses of two-byte word registers result
in a 128 KByte address space overall.
The EEPROM code of the device is 0x800 words (4 KByte) large and is
mapped at the end of the address space at 0xf800. The EEPROM
appears to contain at offset 0x17 128 word registers.
The firmware is loaded at 0xee00 and is 5120 bytes (0xa00 words)
large and ends exactly before the EEPROM at 0xf800. It contains at
0xee1d (FW_BASE_ADDR_OFFSET) the address of 6 firmware word registers.
The 32-bit registers (double words) are mapped at 0x9000
(CR_BASE_OFFSET). However even and odd addresses reference the
same word. So 0x9000 and 0x9001 reference the same word in the
zd1205. The next word is addressed by 0x9002 and 0x9003. We are
using always the even addresses and notify an error if odd
addresses are used while using the debug version of the driver.
There appear to exist less than 256 byte hardware registers, which are
followed by 0x500 bytes of other dword registers. These hardware
(physical) registers can only be written, if the CR_REG1 register
has the bit 7 (0x80) unset. If it is set write access to the
physical registers is not possible.
The original zydas driver maps the EEPROM and firmware registers
after the end of the zd1205 registers at 0x9900 and 0x9b00
respectively. This approach is not followed by my new driver (see
zd_types.h).
RF2559
The registers of this chip are written over a serial interface.
There is a bit indicating reading or writing followed by 5
register address bits and 18 data bits. Reading doesn't appear to
be supported by the ZD1211. The data can't be written directly by
the host CPU because of timing problems over USB.
Therefore an USB request USB_REQ_WRITE_RF is provided, which can
be used for a single register write of 24 bits. For each bit a 16
bit word is provided based on CR203. Bit RF_IF_LE (1) und RF_CLK
(2) are zeroed, bit RF_DATA (3) contains the data value. Following
the USB request id a value must be provided, which should be 2 for
almost all cases. It is followed by the number of bits and the
16-bit values for each bit.
The RF chip works on 374 MHz IF and is low-band injected at the
RF. The reference frequency is 20 MHz, which is provided by an
external oscillator. The frequency commands from the original
driver are correct under this conditions.
Scanning
For scanning the RX filter must be set accordingly and the radio
needs to be activated.
General WLAN programming
Wireless extension ioctls are serialized throught the rtnl mutex.
Receiving Data Frames
Received data frames must be read over the EP_DATA_IN endpoint. It
consists of 5 byte of the PCLP header, starting with the signal
header. The MAC data frame is following. The ZD1211 appends rx
status information at the end. Signal quality and strength can
only be computed together with PLCP
The 5 byte size of the PLCP header means, that the CCK PLCP header
is not completely provided, so you can't do a CRC16 check on your
own.
-- Driver Architecture --
This doesn't describe the current test implementation, but is
intended to lay out the final driver.
There are four modules:
mac - handles all the network specific function and integrates
into the Linux stack
usb - contains all the code, which handles the USB bus
chip - All code which is accessing chip registers is located
here.
rf - for each rf chip there should be a single file
containing the rf-chip-specific code; the code should be
embedded into the chip code by an rf-chip-independent
interface
Data Structures
There are two types of data structures. There are data structures
send to the device and data structures never be used outside of
the kernel. The first type is marked with __attribute__((packed))
to make sure, that the there is no misunderstanding in the layout.
Fields smaller than a byte (for example u16 foobar:2) are only
allowed for in-kernel data structures.
Locking
Access to data structure is protected by spin locks. This is
independend of whether semaphore protection is in place or not.
Spin locks should not cross external linked functions
(non-static).
Keep in mind that the URB completion handler runs in interrupt
context, so spin locks must be interrupt safe.
Chip initialisation and register access is protected by a
mutex and is not atomic. Wireless extension controls are also
protected by it's own semaphore.
Sending and receiving of frames must be supported in atomic mode.
struct urb has also a spin lock
struct urb_tx and struct urb_rx have each a spin lock
struct chip has a spin lock
struct mac has a single spin lock
=== Personal Telco Project wishlist ===
a) We'd like to be able to use them as an access point.
b) We'd like to be able to use them in adhoc mode to support mesh
networks.
c) We'd like to be able to use them for network stumbling (more than
one at a time in monitor mode with kismet).
d) Support for WDS would be nice too.
e) Add the necessary hooks for it to build in the OpenWrt kamikaze
buildroot.
And actually, the last one would probably be the easiest and yield the
greatest immediate benefit (to me, anyway).
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
