Hi All, HAL code a mess.... Hmmm explains a LOT of things to me. My brand new EeePC associates with the open-mesh.com Meraki Mini node but sometimes won't connect. On some powerups it does 'work', but it dies after a while.
And nothing I can do on either end seems to help??!! So Realtek doesn't talk reliably to Atheros.... If I could just tell each Wifi to play dumb.... I remember that the early versions of MIT roofnet had these sorts of problems. Then a "special" version of the Atheros driver appeared. MUCH smaller and it ONLY sent and received RAW packets. I assume whomever did that mod had sources or a good reverse compiler. We could REALLY use a good reverse compiler. Just send and receive RAW packets; now that would be a REALLY NICE feature to have in ANY new 'drivers' from whichever manufacturer. Get the bit transport working reliably before providing 'clever' features and modes and proprietary protocol extensions! And have a "dumb" mode in the driver. i.e.- 1 Mbit mode ONLY. So at least something will work reliably. Very glad to see this discussion :). And it sounds like Atheros MAY be the manufacturer of choice in the near future? warm regards from cold NH, John On Tue, 6 Jan 2009, Nick Kossifidis wrote: > 2009/1/6 Maxim Levitsky <maximlevit...@gmail.com>: > > > > Glad to hear that. > > > > That what I meant btw, that this is related to phy (or radio as they > > call it) > > > > > > The chip that is on aspire one seems to be AR5007EG > > which consist of AR5212 (mac) and AR2425 (phy,radio,analog part..) > > > > I have such a chip from an eeepc and it works fine here (only the rate > problem you also report), your reset problem probably has to do with > phy calibration and various enviromental issues or other card related > issues (not chip related) that we haven't worked on yet. The way i see > it this is the issue here, not the tx performance. Your reset problem > is something new... > > > > > Btw while reading the sources I find that it might be worth to put part > > specific code in separate parts, it is hard to understand, and on top of > > that there are many different versions for different chipsets, so what > > do you think. > > > > These parts are not that different, it's easier to maintain the code > this way, helps you have a bigger picture and keeps the whole code > updated. If you see HAL sources they are full of duplicated code and > you can see that some parts are more frequently updated than others, > it's a mess trust me. Our code also supports 5211 for example (and i > get full 27Mbits) without having to maintain a separate directory, > different rfregs functions and reset sequence (eg. RF5111 is used also > with 5212 chips) etc. The fact is that there are very few differences > and all of them are commented on the code and handled fine (only some > 5210 stuff is missing but it's a really old chip and it's not a > priority right now). Various PHY versions have some differences but we > also handle them fine with this design. > > > Btw, the hal although opensource contains so many 'magic numbers', it > > hardly describes any registers there, and there is an intial register > > dump that isn't documented at all. > > > > The initial register dump is nothing weird, it's just the default set > of settings to get the card working, check out initvals.c, we try to > make it easier than hal to understand what's going on. Some parts are > really low level, there are some registers that aren't documented and > eg some tables that are just filled with increasing numbers etc but it > doesn't affect us, we only know that we have to write this thing > during reset and it works ;-) Rf registers are even worse (you won't > find anything on rf registers, not even Atheros's TLAs have docs on > that) but we still are fine as long as these settings work (and i've > verified that their ndis driver is doing the same thing). I'll do an > update on initvals and phy.c to follow legacy-hal and sam's hal but > it's not a priority right now (tests have shown that initvals are fine > -we took them from binary hal and ndis driver via rev. engineering > anyway-). > > Our hw problems right now are to fix PHY stuff (tx power calibration > and rf regs update), then make a few other fixes, update reset > sequence and put ANI support (and then fix 5210 support and move on > with other things). It'll take some time but it's on the way. > > > So I would suggest (but this might be large work, to create a central > > table for each chip and document all known registers there, like a > > name/description for known regs, and 'working values'/different values > > for different modes for unknown ones, maybe even create a wiki, so dumps > > form different drivers might be put there. > > > > We are doing this already on reg.h, eeprom.h and initvals.c, we can't > put the whole documentation on the driver, what we have right now is > enough to work with. If you want something more specific you can > always ask. > > > It just that speed issues like I was worried are connected to wrong > > setup of the phy, and with little documentation it is hard to to know > > what to do > > > > We now know what we have to do, only a few questions remain and i > expect Atheros to answer them soon so i can go on and finish tx power > stuff asap. They 've already provided help with ANI issues etc so no > problem there. It's just a matter of time... > > -- > GPG ID: 0xD21DB2DB > As you read this post global entropy rises. Have Fun ;-) > Nick > _______________________________________________ > ath5k-devel mailing list > ath5k-devel@lists.ath5k.org > https://lists.ath5k.org/mailman/listinfo/ath5k-devel > _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
