On Thu, Jul 06, 2006 at 10:25:40AM -0400, Joseph Jezak wrote: > > As far as I can tell, the 4.x firmware isn't all that different, > it's the initvals that are causing the trouble.
Ok. Let's look at the first ten initvals. I don't care about 11+13 initvals at the moment. 4.80.9.1 3.130.. d11b0g0initvals4 d11b0g0initvals2 d11b0g0bsinitvals4 d11b0g0bsinitvals2 d11a0g0initvals4 d11a0g0initvals2 d11a0g0bsinitvals4 d11a0g0bsinitvals2 d11b0g0initvals5 d11b0g0initvals5 d11b0g0bsinitvals5 d11b0g0bsinitvals5 d11a0g0initvals5 d11a0g0initvals5 d11a0g1initvals5 d11a0g1initvals5 d11a0g0bsinitvals5 d11a0g0bsinitvals5 d11a0g1bsinitvals5 d11a0g1bsinitvals5 This is absolutely ok. I don't see a differnt order. Keep also in mind that rev2 and rev4 initvals are identical. It's just another name for the same initvals block. Where do you see a different order? > I guess what I'm trying to say is that instead of assuming that a > certain type of initval follows another, perhaps it would be best to > keep the offset of each initval independent, like what is done for > the uCode. That and it would be nice to have the a/b/g/n/revision > for the initial values instead of the arbitrary numbering scheme we > have now. We have to create new code, if we want to extract 11+13 initvals. This is a good chance to introduce something like .iv_map for our struct. There we can define which numbering scheme is used. We can get rid of REVERSE_ORDER_INITVALS and MISSING_INITVAL_08 flags, too. But adding a bunch of offsets instead is painful. We should avoid that. Basically, the initvals are always arranged in the same order. I do not think that the 4.x problems are caused by any wrong initvals. Martin _______________________________________________ Bcm43xx-dev mailing list [email protected] http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
