hi nick! you wiki plans sound good!
since you mentioned writing specs, what use would they be of, since we don't do "clean room" reverse engineering anyways? (i wonder since a while where that puts us legally and why other drivers chose that method instead.) i think the txpower stuff is very important. this week i made distance tests with ath5k (AR5212) and they were pretty disappointing. i stopped them at 80 meters :( concerning turbog dumps for 5414 i want to do that but i just can't configure turbo g on madwifi anymore. any pointers on how to set up turbog on madwifi would be helpful (i know http://madwifi.org/wiki/UserDocs/TurboMode but that doesnt work for g). maybe i have the wrong regdomain/countrycode (i tried 0/0 and 0/840)? i'm willing to work on improving the script, but don't quite understand what you want exactly (yet). do you mean: take testbed connection traces, search for last reset cycle, and print it out as ath5k_ini_mode/ath5k_ini_rf tables? that should be easy enough to do. but which parts go into ath5k_ini_mode and which into ath5k_ini_rf? please clarify, what you need, i'll do it :) bruno On Friday 30 November 2007 09:28:49 Nick Kossifidis wrote: > Hello ppl ;-) > > Sorry for not sending patches lately (i've got a few to send) but my > schedule is really tight (exams @ uni again + lab work). I've been > thinking we should start organizing wiki etc to better focus on > current problems: > > a) Create a list of all hw-related functions and how well they > work/match compaired to their binary alternatives for each chip (both > from madwifi's hal and ndiswrapper dumps -seems we can get beautiful > dumps from ndiswrapper/atheros's windows driver. I'll look more into > it and update wiki on how to do it). > > b) Gather all regdumps in one place, cleaned up/sorted per function etc. > > c) Create a supported chips list along with description on what we > miss, what works etc (one page per mac/phy chip with user experiences, > links to above dumps etc). > > d) (far away) Start writing specs from what we have. > > I'm up for it but it'll take some time, also i don't know which wiki > to use (is ath5k.org's wiki ready or should i start on madwifi's wiki > and then move them ?). > > Just to let you know i'm currently checking out eeprom + txpower stuff > and cleaning up the code (mostly rate tables / interrupt handling). I > also have some thoughts on the interrupt handler (you might have seen > my previous mail about per tx queue interrupts -plz if you haven't > take a look at it and post any comments you have, i really wonder why > both madwifi and ath driver use TXDESC and EOL interrupts for tx > queues while interrupt handler doesn't handle them). I hope i'll be > able to post my patches during Christmas because they need testing and > because i'm gathering as many dumps as i can from cards i have > (5210/5211/5212/5413). I'm optimistic that i'll have txpower working > by then, after that i believe we can declare version 0.2.0 since most > basic hw functions will work and we can have a more stable driver. > > Until then it's good to gather as many regdumps as possible for all > cards in a/b/g/turboa/turbog modes to create initial settings tables > (so we can later study them better). For 5414 we miss dumps for turbog > mode so plz if anyone has such card, try getting some dumps as > described in wiki (testbed). For 5424/2424 we have no dumps for all > modes (a/b/g) and we really need some. > > We also need to see what's going on with Pavel's and Majo's cards and > why they return nothing (figure out the right wakeup sequence or > something like that). > > Also it would be great if someone created a program/script that gets > dumps for a/b/g/turboa/turbog modes from separate files, and generated > ath5k_ini_mode/ath5k_ini_rf tables (as in initvals.c/phy.c) (Bruno can > you do your script-magic once again ?). _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
