Sunday, September 12, 2010

FreeBSD/MIPS: AR9132 and AR9100 wireless support

I've now made the wireless MAC/PHY work on my AR9132 wireless access point - the TP-LINK TR-WL1043nd.

The wireless bits are below:

ath0: at mem 0x180c0000-0x180effff irq 0 on nexus0
ath0: [ITHREAD]
eepromdata pointer: 0xbfff1000
eeprom: attaching
eeprom: allocating
eeprom: copying the data!
eeprom: endian check
eeprom: swapsies: 0
ath0: AR9100 mac 20.1 RF2133 phy 10.2

It doesn't currently like client mode - it's something to do with the channel changes and aborting some pending queued stuff isn't working. I'll have to go digging at some point soon.

But it works in hostap mode:

# ifconfig wlan0 list sta
ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
1c:4b:d6:97:ac:26 1 6 1M 32.5 15 2 32160 ES AQE WME

# ifconfig wlan0 list channels

Channel 1 : 2412 MHz 11g ht Channel 7 : 2442 MHz 11g ht
Channel 2 : 2417 MHz 11g ht Channel 8 : 2447 MHz 11g ht
Channel 3 : 2422 MHz 11g ht Channel 9 : 2452 MHz 11g ht
Channel 4 : 2427 MHz 11g ht Channel 10 : 2457 MHz 11g ht
Channel 5 : 2432 MHz 11g ht Channel 11 : 2462 MHz 11g ht
Channel 6 : 2437 MHz 11g ht

# ifconfig wlan0 list sta

ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
1c:4b:d6:97:ac:26 1 6 54M 33.5 0 2682 45008 ES AQE WME

# ifconfig wlan0 scan

SSID/MESH ID BSSID CHAN RATE S:N INT CAPS
WLAN Lucy-Gaby 94:44:52:4b:f5:52 6 54M -65:-96 100 EP RSN HTCAP WPA WME
CACHEBOY_DA... 00:25:86:d8:7c:da 6 54M -65:-96 100 EP WPA RSN
davinayarker 00:1c:df:e4:d6:5f 6 54M -83:-96 100 EP MESHCONF MESHCONF WPS HTCAP WPA RSN WME
surbi 00:22:b0:9a:d0:ab 6 54M -88:-96 100 EPS WPA ATH WPS

I haven't yet committed the code anywhere - it's a bit of a mess. In particular:
  • There's some weird stuff surrounding the EEPROM logic determining when to swap what. The existing code assumes that a Big-Endian system requires swapping the byte order - but the EEPROM contents stored in flash are stored in big endian order already! Tsk.
  • There's also a bit of a mess in getting the EEPROM contents out from memory-mapped SPI flash into a private buffer. The linux AR9100 commit(s) mention that accessing it direct can be unreliable.
  • The AR9100 support is sprinkled throughout the AR5416/AR9160 support...
  • .. and I'm sure there's bits that I've missed in porting it from ath9k ..
  • .. and I know there's a few bits here and there which are also missing. I'll check that out later.
I'll look to tidy this code up and get it pushed into something public in the next week or so.

Update

The diff against my GIT repository is available at http://www.creative.net.au/diffs/git_ath_diff_1.diff . The patch includes where the GIT repository can be found.

3 comments:

  1. How do you read the calibration data from am MTD partition and then store it in a buffer? Do you modify the SPI flash driver or do a get on the mtd device and call the read function?
    I'd appreciate your input, thanks!

    hr

    ReplyDelete
  2. The calibration stuff is just handled like all the other devices - via the ath EEPROM code. I supply the ath EEPROM code with a copy of the data from the flash.

    The SPI flash is memory mapped via some CPU trickery, so I just have to memcpy() it from a fixed location. (That memory location is configured in the device "hints"; that way I can support different locations in flash for the EEPROM data.)

    If I ever have to work with a device which has no memory-mapped flash, I can just modify the ahb attach routine to do an SPI device read into a temporary memory buffer and pass that along to the ath EEPROM routines at device attach time.

    Hope that helps!

    ReplyDelete
  3. I actually solved the problem before I read your reply but yes that makes a lot of sense. I ended up supplying the physical base address of the spi flash adding the offset to the base address so the driver can read the calibration data. I had to dd the eeprom partition to get the offset of the MAGIC number. It's working well for now. Thanks for your help!

    ReplyDelete