The wireless bits are below:
ath0:
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.
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.
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?
ReplyDeleteI'd appreciate your input, thanks!
hr
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.
ReplyDeleteThe 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!
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