This is an old revision of the document!
====== Joshua Oreman: 802.11 wireless development ====== ===== Journal Week 2 ===== ==== Monday, 1 June ==== Banged out the rtl8180 driver today, based on the Linux code, and tweaked things that came up while doing it. * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=2547cd068050eaa797cf8594e6c987c2e651df55| [drivers 802.11] Initial import Realtek 8180/8185 driver from Linux]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=422abfd3907b7fb617c335772b7111a48ca82824| [nvs] Add init function for Atmel 93C66 EEPROM]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=2aa5cec3c8b78c271c6584c97c178fdd8ce68c3e| [802.11] Tweaks to API for clarity and practicality]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=95fb6586a4daf09c678537d7a61809f9448de0bf| [drivers rtl8180] First shot at an rtl8180/8185 driver]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=13f76397b08c51e0a2b7e2d71b89e393e7d495ac| [drivers rtl8180] Fix the main rtl8180 driver filename]] It doesn't link yet, because the 802.11 MAC layer code hasn't been written, but it does compile. This driver was actually surprisingly painless to work on. Like most Realtek cards, it does almost everything in the simplest way possible. The EEPROM on the card is a larger version of one already supported by gPXE's bitbasher, and the driver hasn't been in the Linux kernel long enough to accumulate cruft, so there wasn't too much for me to excise. :-) The Linux support for this card is almost as barebones as gPXE's will be. Code for the driver excluding the variable RF part weighs in at about 3k. For the record, the 8180 is an 802.11b-only card, and the 8185 is 802.11b/g; the programming interfaces are almost identical. One complicating factor for this chipset is that it can be bundled with any of four RF chips, three for the 8180 and one for the 8185. So far I've implemented these using gPXE's linker tables, so the user can compile in the ones they want, e.g. make bin/rtl8180--rtl8180_rtl8225.lkrn for the 802.11g card. The make syntax is a bit ugly, and there may be a way to make it nicer - perhaps the RF chip can be guessed by the PCI ID? Or we could have e.g. a ''rtl8185.c'' file that just ''REQUIRE_OBJECT()''s rtl8180 and rtl8180_rtl8225. The RF code for the 802.11g card is quite bulky due to an unholy number of constants that must be used to initialize the chip; it's about 8k. The 802.11b RF modules are 1k or less each. The Linux driver shared some code with a driver supporting rtl8187 - that's the "rtl818x" that shows up some places. I'll port over the rtl8187 driver if I get some hardware that uses the chipset. ==== Thursday, 4 June ==== Made some pretty good progress on coding the MAC layer: * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=8d60d36fe400799acfd74b8f8988b5dc5a3cd4e9| [netdevice] Add netdev argument to ll_protocol::push, pull]] * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=ab39548abf5261b240c97ac62df317172fd7254a| [802.11] The 802.11 MAC layer, first big commit]] So far I've implemented the basic structure of everything (including a framework to fill in for crypto), link-layer encapsulation, net_device wrapping, and rx defragmentation. I still need to handle received management frames, especially those involved in associating with a network, and write said association code. The beacons received during association also need to be used to construct the lists of channels and rates on which the device can communicate, and those lists need to be freed at the appropriate time. gPXE with the rtl8180 driver now builds cleanly, because I've stubbed the necessary 802.11 functions that haven't been implemented. If you run it it will probably time out waiting for "link-up" (which is how I've chosen to represent association to the network stack) because there's nothing going on to get the association in place. Tomorrow I work on management frame parsing, and maybe get to test all this stuff.
