This is an old revision of the document!
====== 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.
