I've had a busy week in the land of FreeBSD wireless driver hacking.
I've been porting over the AR9280 TX calibration changes from ath9k. The AR9280 NIC in my laptop loves it - but the AR9220 based SR71-12 is still unhappy. I'll go poke around and see if I can figure out what the problem is. I have some other AR9280 series NICs to try out.
I've been using hostap mode on the AR5416 and AR9160 and it still seems quite fine and stable.
I've ported over a number of changes to the AR9285 codebase from Linux ath9k. These include:
Fixing the TX power calibration curve code;
Handling a TX power offset at the beginning of the calibration curve;
Updating how the board is initially calibrated on reset;
Adding PA calibration.
I'm also trying to remove some of the duplicate code in the HAL that has crept up as chipset support was added.
I'm waiting to hear back from some other users about what effects it has on their setup. I still have to port over the (completely rewritten) radio board configuration code from ath9k that sets up all kinds of radio related gain, offset and various things. There's also software antenna diversity to port over. I hope that this all fixes the issues users have been reporting with AR9285 NICs just plain not working in a lot of instances - but working fine in others. I also hope it fixes the AR2427 support.
I'm still very unclear what may be up with the AR9280 support. The Ubiquiti high-powered cards tend to have strange EEPROM calibration settings, so it's quite possible FreeBSD just handles one of the options badly. That's going to take some time to figure out.
There's no point in getting 802.11n support enabled if I can't TX and RX cleanly, so I'm leaving 802.11n alone (for the most part) until the radios and MACs are behaving themselves.
I've had a busy week in the land of FreeBSD wireless driver hacking.
I've been porting over the AR9280 TX calibration changes from ath9k. The AR9280 NIC in my laptop loves it - but the AR9220 based SR71-12 is still unhappy. I'll go poke around and see if I can figure out what the problem is. I have some other AR9280 series NICs to try out.
I've been using hostap mode on the AR5416 and AR9160 and it still seems quite fine and stable.
I've ported over a number of changes to the AR9285 codebase from Linux ath9k. These include:
Fixing the TX power calibration curve code;
Handling a TX power offset at the beginning of the calibration curve;
Updating how the board is initially calibrated on reset;
Adding PA calibration.
I'm also trying to remove some of the duplicate code in the HAL that has crept up as chipset support was added.
I'm waiting to hear back from some other users about what effects it has on their setup. I still have to port over the (completely rewritten) radio board configuration code from ath9k that sets up all kinds of radio related gain, offset and various things. There's also software antenna diversity to port over. I hope that this all fixes the issues users have been reporting with AR9285 NICs just plain not working in a lot of instances - but working fine in others. I also hope it fixes the AR2427 support.
I'm still very unclear what may be up with the AR9280 support. The Ubiquiti high-powered cards tend to have strange EEPROM calibration settings, so it's quite possible FreeBSD just handles one of the options badly. That's going to take some time to figure out.
There's no point in getting 802.11n support enabled if I can't TX and RX cleanly, so I'm leaving 802.11n alone (for the most part) until the radios and MACs are behaving themselves.
One of the issues that I've been having with my AR9280 NIC is that MCS rates aren't being reliable.
Having fiddled with the TX power control with the AR9160 (and I'll write about that soon!) I remembered that badly-configured TX power control would result in the transmit side spitting out a (sometimes very) unclean spectral mask, with noise all over the place.
I did a little digging into how the AR9280 TX-side calibration works. It turns out that there's two methods of TX power control - closed-loop (with a power-detector ADC which compares the signal to a calibrated level) and open-loop (which I'm not yet sure about.) The AR9280 NIC that I have has the "open loop TX power control" bit set in the EEPROM, which indicates it needs open-loop TX power rather than closed-loop. A little digging shows that FreeBSD's HAL doesn't include closed-loop TX power control or any of the newer AR9280 calibration code (in particular the open-loop temperature compensation code.)
Long-story short, I've added the open-loop TX calibration and temperature compensation code from ath9k to the FreeBSD HAL (but I haven't yet committed it and won't until I figure out how to make it tidy) and suddenly all MCS rates TX perfectly fine.
So if you're using an AR9280 NIC, please keep a look out for when I commit this stuff and let me know if it improves things.
One of the issues that I've been having with my AR9280 NIC is that MCS rates aren't being reliable.
Having fiddled with the TX power control with the AR9160 (and I'll write about that soon!) I remembered that badly-configured TX power control would result in the transmit side spitting out a (sometimes very) unclean spectral mask, with noise all over the place.
I did a little digging into how the AR9280 TX-side calibration works. It turns out that there's two methods of TX power control - closed-loop (with a power-detector ADC which compares the signal to a calibrated level) and open-loop (which I'm not yet sure about.) The AR9280 NIC that I have has the "open loop TX power control" bit set in the EEPROM, which indicates it needs open-loop TX power rather than closed-loop. A little digging shows that FreeBSD's HAL doesn't include closed-loop TX power control or any of the newer AR9280 calibration code (in particular the open-loop temperature compensation code.)
Long-story short, I've added the open-loop TX calibration and temperature compensation code from ath9k to the FreeBSD HAL (but I haven't yet committed it and won't until I figure out how to make it tidy) and suddenly all MCS rates TX perfectly fine.
So if you're using an AR9280 NIC, please keep a look out for when I commit this stuff and let me know if it improves things.
I managed to find and fix the AR9280 and AR9285 support.Things that needed repairing:
Updating the AR9280 initvals to the Linux ath9k ones resolved the radio initialisation issues, making everything magically stable!
The v4k EEPROM code (for the AR9285/AR2427) needed some surgery to reflect what was really going on. In particular, the 8 bit radio bias values in the AR9280 (v14) EEPROM are actually lots of 4 bit values; so the bias values being written to the radio were woefully incorrect. This restored AR9285 stability and made the AR2427 function.
The AR9280 RF registers need an extra delay before being written to. I guess since the earlier radios are externally connected via single-bit IO (and thus shift registers are involved), the later radios are too. Without this delay, the AR9220 panics on my MIPS board and I would get occasional unexplained resets when I configured an AR9280 on my eeepc. This fix has resolved both those issues.
I have one more fix to integrate for the AR9220 init path so the Ubiquiti SR71-12 and SR71-15 work; then the AR9220 is supported.The AR2427 baseband seems to hang after a few hours of use, requiring a complete cold (power off) restart. There's some more initialisation code I need to port from ath9k and there's a lot of AR9280/AR9285 calibration code which I need to port over. I hope porting these two over will fix the stability issues that I was seeing. There's also some noise floor calibration fixes from ath9k which I need to integrate into the FreeBSD-HEAD tree.So, there's been quite a bit of progress! I've had reports from users that the AR9280, AR9285 and AR9220 support is now very stable; much more stable than before.
I managed to find and fix the AR9280 and AR9285 support.
Things that needed repairing:
Updating the AR9280 initvals to the Linux ath9k ones resolved the radio initialisation issues, making everything magically stable!
The v4k EEPROM code (for the AR9285/AR2427) needed some surgery to reflect what was really going on. In particular, the 8 bit radio bias values in the AR9280 (v14) EEPROM are actually lots of 4 bit values; so the bias values being written to the radio were woefully incorrect. This restored AR9285 stability and made the AR2427 function.
The AR9280 RF registers need an extra delay before being written to. I guess since the earlier radios are externally connected via single-bit IO (and thus shift registers are involved), the later radios are too. Without this delay, the AR9220 panics on my MIPS board and I would get occasional unexplained resets when I configured an AR9280 on my eeepc. This fix has resolved both those issues.
I have one more fix to integrate for the AR9220 init path so the Ubiquiti SR71-12 and SR71-15 work; then the AR9220 is supported.
The AR2427 baseband seems to hang after a few hours of use, requiring a complete cold (power off) restart. There's some more initialisation code I need to port from ath9k and there's a lot of AR9280/AR9285 calibration code which I need to port over. I hope porting these two over will fix the stability issues that I was seeing. There's also some noise floor calibration fixes from ath9k which I need to integrate into the FreeBSD-HEAD tree.
So, there's been quite a bit of progress! I've had reports from users that the AR9280, AR9285 and AR9220 support is now very stable; much more stable than before.
I acquired a pair of shiny AR9220 minipci NICs last week - Ubiquiti SR71-12 and SR71-15. They're supposed to be like AR9280 but on PCI, not PCIe. Unfortunately they didn't work under FreeBSD. After some sleuthing (read: guessing), I stumbled across an ath9k commit which reworked some workaround for some AR9220's, which include the Ubiquiti SR71 versions.
https://patchwork.kernel.org/patch/90926/
There's also a bus error when reading a random register which is only referenced in a debug statement. That's a whole other bug to try and deal with.
But now I've verified that with both the AR9280 and the AR9220, the FreeBSD code is definitely tickling the radio wrong. Only one of the two radio chains is even active for the most part, and that chain seems to go deaf quite often, resulting in a baseband hang and chip reset. It also explains why I was getting absolutely shocking 11n performance out of it in my 11n branch.
I acquired a pair of shiny AR9220 minipci NICs last week - Ubiquiti SR71-12 and SR71-15. They're supposed to be like AR9280 but on PCI, not PCIe. Unfortunately they didn't work under FreeBSD. After some sleuthing (read: guessing), I stumbled across an ath9k commit which reworked some workaround for some AR9220's, which include the Ubiquiti SR71 versions.https://patchwork.kernel.org/patch/90926/There's also a bus error when reading a random register which is only referenced in a debug statement. That's a whole other bug to try and deal with.But now I've verified that with both the AR9280 and the AR9220, the FreeBSD code is definitely tickling the radio wrong. Only one of the two radio chains is even active for the most part, and that chain seems to go deaf quite often, resulting in a baseband hang and chip reset. It also explains why I was getting absolutely shocking 11n performance out of it in my 11n branch.
I traced down WPA not working to broken CCMP support in FreeBSD-HEAD.This has been broken for some time. It was introduced in r204364 which enabled the multicast key search. I'm not sure why it's broken - I'll have to go through the ath9k/ath5k code; maybe even madwifi has some more up to date code in this area.In any case, that's one less thing to worry about for now. I'm pretty sure that multi-VAP mode has more issues than this so I'll put that on hold for a while.Next - making the 11n TX path a run-time check rather than a compile-time check; then test it with legacy chipsets to ensure things haven't broken.
I traced down WPA not working to broken CCMP support in FreeBSD-HEAD.
This has been broken for some time. It was introduced in r204364 which enabled the multicast key search. I'm not sure why it's broken - I'll have to go through the ath9k/ath5k code; maybe even madwifi has some more up to date code in this area.
In any case, that's one less thing to worry about for now. I'm pretty sure that multi-VAP mode has more issues than this so I'll put that on hold for a while.
Next - making the 11n TX path a run-time check rather than a compile-time check; then test it with legacy chipsets to ensure things haven't broken.
My university exams are over for another semester. Remind me why I put myself through this? :-)So now that they're over, my open source work plate now is rapidly filling up again:FreeBSD 802.11n:
802.11n RX works!
But now I need to grovel through ath9k and figure out how 802.11n TX works.
I'm blissfully ignoring handling sending or receiving A-MPDU and A-MSDU frames for now. That can come (much) later once I have stable 802.11n TX/RX in station and hostap mode (which is enough of a challenge for now, thanks.)
Lusca:
IPv6 client support! I need to finish merging in more stuff to test.
Thread manager - this is an important one.
Find my RPM build patches and include them in the subversion tree.
My university exams are over for another semester. Remind me why I put myself through this? :-)
So now that they're over, my open source work plate now is rapidly filling up again:
FreeBSD 802.11n:
802.11n RX works!
But now I need to grovel through ath9k and figure out how 802.11n TX works.
I'm blissfully ignoring handling sending or receiving A-MPDU and A-MSDU frames for now. That can come (much) later once I have stable 802.11n TX/RX in station and hostap mode (which is enough of a challenge for now, thanks.)
Lusca:
IPv6 client support! I need to finish merging in more stuff to test.
Thread manager - this is an important one.
Find my RPM build patches and include them in the subversion tree.
I've been toying with getting 802.11n working on these atheros AR9160's.
I've got somewhat working 802.11n on the receive side using my public HAL, up to MCS15. But it (currently) isn't implementing AMPDU (datagram aggregation) which is done in software, so it isn't much faster than legacy mode.
But it -does- work - in 20mhz 11ng mode:
root@OpenWrt:~# iw dev wlan0 station dump Station 00:15:6d:84:05:52 (on wlan0) inactive time: 0 ms rx bytes: 41144714 rx packets: 475307 tx bytes: 1059470517 tx packets: 692698 signal: -50 dBm tx bitrate: 130.0 MBit/s MCS 15
I've been toying with getting 802.11n working on these atheros AR9160's.I've got somewhat working 802.11n on the receive side using my public HAL, up to MCS15. But it (currently) isn't implementing AMPDU (datagram aggregation) which is done in software, so it isn't much faster than legacy mode.But it -does- work - in 20mhz 11ng mode:root@OpenWrt:~# iw dev wlan0 station dumpStation 00:15:6d:84:05:52 (on wlan0) inactive time: 0 ms rx bytes: 41144714 rx packets: 475307 tx bytes: 1059470517 tx packets: 692698 signal: -50 dBm tx bitrate: 130.0 MBit/s MCS 15
The Ubiquiti SR-2 is a high-power 11bg card based on the Atheros AR5213 MAC. It has three antenna fittings - one UFL, one MMCX, and a third set of solder pads for a non-existent connector. The first two are treated as separate antennas and are controlled by an external antenna switch. The third looks like it's an alternative to the UFL connector.
I discovered that these cards occasionally calibrate their NF at some impossibly low level - under -100 dBm. The reason? Antenna diversity is occasionally selecting the MMCX connector as the RX antenna - and this never has an antenna attached. Tsk.
Antenna diversity also often chooses the MMCX antenna for TX. Grr.
The Ubiquiti SR-2 is a high-power 11bg card based on the Atheros AR5213 MAC. It has three antenna fittings - one UFL, one MMCX, and a third set of solder pads for a non-existent connector. The first two are treated as separate antennas and are controlled by an external antenna switch. The third looks like it's an alternative to the UFL connector.I discovered that these cards occasionally calibrate their NF at some impossibly low level - under -100 dBm. The reason? Antenna diversity is occasionally selecting the MMCX connector as the RX antenna - and this never has an antenna attached. Tsk.Antenna diversity also often chooses the MMCX antenna for TX. Grr.
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.
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.
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 nexus0ath0: [ITHREAD]eepromdata pointer: 0xbfff1000eeprom: attachingeeprom: allocatingeeprom: copying the data!eeprom: endian checkeeprom: swapsies: 0ath0: AR9100 mac 20.1 RF2133 phy 10.2It 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 staADDR 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 channelsChannel 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 scanSSID/MESH ID BSSID CHAN RATE S:N INT CAPSWLAN Lucy-Gaby 94:44:52:4b:f5:52 6 54M -65:-96 100 EP RSN HTCAP WPA WMECACHEBOY_DA... 00:25:86:d8:7c:da 6 54M -65:-96 100 EP WPA RSNdavinayarker 00:1c:df:e4:d6:5f 6 54M -83:-96 100 EP MESHCONF MESHCONF WPS HTCAP WPA RSN WMEsurbi 00:22:b0:9a:d0:ab 6 54M -88:-96 100 EPS WPA ATH WPSI 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.UpdateThe 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.
