Category Archives: atheros 802.11n

AR9280/AR9285 support now working

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.

AR9280/AR9285 support now working

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.

Saturday night @ ucc: 11n hackery

I'm going to work on the FreeBSD 802.11n support a little more this upcoming Friday night and Saturday at UCC.My short-short term TODO list:
  1. Figure out why crypto isn't working in 11n mode - I've likely just not fully implemented something there;
  2. Hopefully I'll have the AR9220 based SR-71 cards by then - so if I do, see whether my HAL works on the AR9280 and AR9220 based NICs;
  3. Test the legacy HAL (AR5212 support at least) to make sure I haven't broken that;
  4. Make the TX path run-time configurable rather than a compile #ifdef - ie, if the card says it does 11n, use the 11n-aware TX routines;
  5. Keep breaking apart sys/dev/ath/if_ath.c into smaller parts to make this whole thing more manageable moving forward.
That's all I think I need to finish up before I begin preparation for committing this work to FreeBSD-HEAD.

Saturday night @ ucc: 11n hackery

I'm going to work on the FreeBSD 802.11n support a little more this upcoming Friday night and Saturday at UCC.

My short-short term TODO list:

  1. Figure out why crypto isn't working in 11n mode - I've likely just not fully implemented something there;
  2. Hopefully I'll have the AR9220 based SR-71 cards by then - so if I do, see whether my HAL works on the AR9280 and AR9220 based NICs;
  3. Test the legacy HAL (AR5212 support at least) to make sure I haven't broken that;
  4. Make the TX path run-time configurable rather than a compile #ifdef - ie, if the card says it does 11n, use the 11n-aware TX routines;
  5. Keep breaking apart sys/dev/ath/if_ath.c into smaller parts to make this whole thing more manageable moving forward.
That's all I think I need to finish up before I begin preparation for committing this work to FreeBSD-HEAD.

A productive night at the computer club ..

I spent most of Saturday at the UWA Computer Club, participating in their "Hardware Hacking Night". Whilst others were hacking on power supplies, coke machines and the like, I sat down to try and figure out how 11n TX works.Which I did, around 11:30pm last night. I still have a long way to go. The AR9160 NIC seems quite happy pumping out packets all the way up to MCS15. I couldn't figure out how to make things work correctly using the 11n RTSCTS protection - if I configure that in the TX registers, no packets are ever sent. That's the next thing on my plate to figure out.Once I figure that out, I'll worry about the 802.11n "niceities" (short-GI, HT-40 mode to name two) and then see about how to ensure that I'm interoperating (enough!) with legacy non-n devices. There's also hostap and adhoc modes to test.

A productive night at the computer club ..

I spent most of Saturday at the UWA Computer Club, participating in their "Hardware Hacking Night". Whilst others were hacking on power supplies, coke machines and the like, I sat down to try and figure out how 11n TX works.

Which I did, around 11:30pm last night. I still have a long way to go. The AR9160 NIC seems quite happy pumping out packets all the way up to MCS15. I couldn't figure out how to make things work correctly using the 11n RTSCTS protection - if I configure that in the TX registers, no packets are ever sent. That's the next thing on my plate to figure out.

Once I figure that out, I'll worry about the 802.11n "niceities" (short-GI, HT-40 mode to name two) and then see about how to ensure that I'm interoperating (enough!) with legacy non-n devices. There's also hostap and adhoc modes to test.