✎ soc:2009:oremanj:journal:week10

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Joshua Oreman: 802.11 wireless development ======
===== Journal Week 10 =====

==== Tuesday-Thursday, 28-30 July ====
I've been working on getting the ath5k driver gPXEfied:
  * On branch **ath5k**:
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=1fd55b8b4151e1694c88caab02c3f9744f8d1dea|
[error] Add macro to test type of error returned from another file]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=fb7a4171a6964b49f43d4ddb918f095261610ee4|
[802.11] Expose net80211_duration() as useful to drivers]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=4de68cd3446b641f202b26eb0c422fe351993fcb|
[rtl818x] Update rtl818x driver for API changes]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=10f5eab6a2ad8e7b9eec758bf6248366f5ec03c3|
[Makefile] Build ath5k driver]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=cf45cada24f368ae9426c6165ab26b389671629f|
[ath5k] Further gPXEficiation]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=4495bab0f74a45aacb0a66080f95899294d214e2|
[802.11] Expand channel hw_value field to 16 bits]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=f13c1419806d5d1a63fb4f13532690a386b657b5|
[ath5k] Cleanup for successful compilation]]

I've gotten it to a compilable state, and fixed what runtime bugs I could, but I've run up against one that suggests no more fruitful approach than shooting in the dark:
  ath5k: resetting for channel change (2422 -> 2447 MHz)
  ath5k: reset to channel 0x2b0b4 (2447 MHz)
  ath5k: txq [u] 0, link 0x0
  ath5k: hw reset to channel 0x2b0b4 (2447 MHz)
    <~1second pause>
  ath5k: noise floor calibration timeout (2447 MHz)

Without the noise floor calibration (comments and observation suggest) the card can't receive any packets. A further analysis of the registers reveal that upon setting the NF calibrate bit, nothing happens - the bit remains set (it should be cleared by the card once calibration starts) and the noise floor register doesn't change.

Suffice it to say, I'm rather confused.

==== Friday, 31 July ====
Fixed the noise floor issue, but it's still not receiving packets.
  * On branch **ath5k**:
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=d12bf0a20b0e23f0af465291bf2ee7f20c46218e|
[802.11] Set channels early on to avoid tuning to an undefined channel]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=574a520719942a69db5a2d81127e5243ca42fe71|
[802.11] Fix maximum packet length]]
    * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=918f3b3b7a10e0c5ab68cbc781339fc42529ed19|
[ath5k] Fix confusion between bitfield and counter uses of mode variable]]

The noise floor issue was just the first manifestation of a bug that would seem completely unrelated to it. In the Linux driver code, the various modes of operation (A, B, G, ATurbo, GTurbo, XR) were defined as monotonically increasing enumeration values 0, 1, 2, ..., and then frequently used to set bitfields. In my initial translation of the code for gPXE, I had thought this bitfield use was //all// that the mode values were put to, and redefined the modes to be powers of two. This worked for everything except part of the initialization sequence where the current mode is used to index an array.

For my card, the 802.11g mode had value 3 in the original enumeration, and 8 in my power-of-2 modification. The mode value is used to index a 5-element array. The net result was that register A in 802.11g mode would be initialized with the value that should be used for register A+1 in 802.11b mode. As you might guess, this caused... some issues, of which the noise floor calibration failure was simply the first to appear.

I've since tested the card in Linux and gotten it to work, so I didn't permanently damage my hardware with this coding bug.

Packets are still not being received properly, but the fix will probably reveal itself after slogging through enough diffs and debug statements. I hope to have this driver completely working by the end of next week.

==== Saturday, 1 August ====
Had a meeting this morning. Priorities for the remaining two weeks of GSoC:
  * For the week of 2 August:
    * Get ath5k finished.
    * Figure out why ''REQUIRE_OBJECT()'' doesn't produce a link error for nonexistent objects, and determine the best way to express a dependency of the form "require X if Y is linked in", alternately "produce undefined symbol X if symbol Y is defined". Ideally this would be expressible in C, but if not, we can do it with linker script fragments generated on the fly by a script.
  * For the week of 9 August:
    * Get encryption code, firmware loading, and ath5k driver ready for mainline review.
    * Document!
      * A page for users wanting to boot wirelessly.
      * A page for 802.11 driver developers.
      * Time permitting, a semi-organized brain dump of the 802.11 information I've gleaned over the summer. It's all in the spec, but the spec goes into detail so quickly that it creates a feeling of drowning. A gentler introduction may help future developers.
  * And beyond...

And...
  * On **gPXE mainline**:
    * [[http://git.etherboot.org/?p=gpxe.git;a=commit;h=ce64398f87230d14a62b2ff153a67b851a125d2e|
[802.11] Add support for 802.11 devices with software MAC layer]]
    * [[http://git.etherboot.org/?p=gpxe.git;a=commit;h=14ae602ef0421c15b28d26886fa5eea99c553aca|
[rtl818x] Add driver for Realtek 8180/8185 wireless cards]]

The iwmgmt commit is awaiting a more general solution for the problem of "require this object only if this subsystem is already compiled in", which I'll be working on over the next weeks.
Trace:
Navigation

Search

Toolbox

QR Code
