Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 21 April 2008 08:52:00 Rafał Miłecki wrote: > 2008/4/17, Michael Buesch <[EMAIL PROTECTED]>: > > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > > > I'm glad it is not working. > > > > Haha. And people call _me_ inhuman. :D > > Oh come on. Make that device working and we will be even gladder ;) Ah, you're too late. :P Patch is already sent upstream. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
21-04-08, Stefanik Gábor <[EMAIL PROTECTED]> napisał(a): > Rafał, read the mailing list archive. The 4301 has 0x in the > BoardFlags field of its SPROM, which should be treated as 0x > according to the specification. This treatment was missed in SSB. A > patch has been submitted for this issue. The 4318 (Asus WL-138G V2, > specific to this card) also had incorrect BoardFlags settings, with > BFL_BTCOEXIST incorrectly set to 1. This has also been worked around > by a patch, but neither patches are in the tree yet. Oh... I've read about that, every single post, but I thought it's separate problem. Thanks for explaining :) -- Rafał Miłecki ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Rafał, read the mailing list archive. The 4301 has 0x in the BoardFlags field of its SPROM, which should be treated as 0x according to the specification. This treatment was missed in SSB. A patch has been submitted for this issue. The 4318 (Asus WL-138G V2, specific to this card) also had incorrect BoardFlags settings, with BFL_BTCOEXIST incorrectly set to 1. This has also been worked around by a patch, but neither patches are in the tree yet. On Mon, Apr 21, 2008 at 8:52 AM, Rafał Miłecki <[EMAIL PROTECTED]> wrote: > 2008/4/17, Michael Buesch <[EMAIL PROTECTED]>: > > > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > > > I'm glad it is not working. > > > > Haha. And people call _me_ inhuman. :D > > Oh come on. Make that device working and we will be even gladder ;) > > Can you post any further informations about work with this card? > > -- > Rafał Miłecki > > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
2008/4/17, Michael Buesch <[EMAIL PROTECTED]>: > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > > I'm glad it is not working. > > Haha. And people call _me_ inhuman. :D Oh come on. Make that device working and we will be even gladder ;) Can you post any further informations about work with this card? -- Rafał Miłecki ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Thursday 17 April 2008 21:49:53 Stefanik Gábor wrote: > On Thu, Apr 17, 2008 at 5:18 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > [ 966.619496] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor > > 0x4243) > > [ 966.619496] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor > > 0x4243) > > [ 966.619496] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) > > [ 966.619496] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor > > 0x4243) > > [ 966.637500] ssb: SPROM revision 2 detected. > > [ 966.658366] ssb: Sonics Silicon Backplane found on PCI device > > :02:05.0 > > [ 966.674476] b43-phy3: Broadcom 4318 WLAN found > > [ 966.714105] b43-phy3 debug: Found PHY: Analog 3, Type 2, Revision 7 > > [ 966.714105] b43-phy3 debug: Found Radio: Manuf 0x17F, Version 0x2050, > > Revision 8 > > [ 966.734069] phy3: Selected rate control algorithm 'pid' > > [ 966.736778] Broadcom 43xx driver loaded [ Features: PNR, Firmware-ID: > > FW13 ] > > [ 988.593922] input: b43-phy3 as /class/input/input8 > > [ 987.781568] b43-phy3: Loading firmware version 351.126 (2006-07-29 > > 05:54:02) > > [ 987.781568] b43-phy3 warning: You are using an old firmware image. > > Support for old firmware will be removed in July 2008. > > [ 987.781568] b43-phy3 warning: You must go to > > http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download > > the latest firmware (version 4). > > [ 987.895936] b43-phy3 debug: Chip initialized > > [ 987.896206] b43-phy3 debug: 32-bit DMA initialized > > [ 988.967223] b43-phy3 debug: Wireless interface started > > [ 988.967247] b43-phy3 debug: Adding Interface type 2 > > [ 988.981264] phy3: HW CONFIG: freq=2412 > > [ 991.039238] b43-phy3 debug: Removing Interface type 2 > > [ 991.061533] b43-phy3 debug: Wireless interface stopped > > [ 990.024893] b43-phy3 debug: DMA-32 rx_ring: Used slots 0/64, Failed > > frames 0/0 = 0.0%, Average tries 0.00 > > [ 990.026360] b43-phy3 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, > > Failed frames 0/0 = 0.0%, Average tries 0.00 > > [ 990.031396] b43-phy3 debug: DMA-32 tx_ring_AC_BE: Used slots 0/128, > > Failed frames 0/0 = 0.0%, Average tries 0.00 > > [ 990.038040] b43-phy3 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, > > Failed frames 0/0 = 0.0%, Average tries 0.00 > > [ 990.048005] b43-phy3 debug: DMA-32 tx_ring_AC_VO: Used slots 0/128, > > Failed frames 0/0 = 0.0%, Average tries 0.00 > > [ 990.056402] b43-phy3 debug: DMA-32 tx_ring_mcast: Used slots 0/128, > > Failed frames 0/0 = 0.0%, Average tries 0.00 > > > Hmm, that looks like no data reaches the TX rings. Yeah, because I didn't transmit anything. > For comparision, can you > post the output of a non-Asus 4318? What happens if you flash a non-Asus > SPROM into the card? Yeah well. Most likely nothing. This data wasn't meant for giving me advise on how to proceed. It was more to show what card that really is and people can compare that to their card. However, the two fully working 4318 that I own have _exactly_ the same core and PHY revisions like this one. It seems that I can DMA data to the device, but the firmware cannot handle it properly. But I must confirm this first by doing some debugging on the microcode. When I try to transmit a packet with a corrupt TX header nothing happens. It should actually produce a PHY error in that case. So I _think_ that the problem is some packet handling in the firmware. Now sure yet, however, as I have to verify my theories first. Printing the status reports of the DMA engine seems to indicate that it works properly. There's also no power emmitted by the device (except for half a second during PHY initialization.) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Thu, Apr 17, 2008 at 5:18 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > [ 966.619496] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor > 0x4243) > [ 966.619496] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor > 0x4243) > [ 966.619496] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) > [ 966.619496] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor > 0x4243) > [ 966.637500] ssb: SPROM revision 2 detected. > [ 966.658366] ssb: Sonics Silicon Backplane found on PCI device > :02:05.0 > [ 966.674476] b43-phy3: Broadcom 4318 WLAN found > [ 966.714105] b43-phy3 debug: Found PHY: Analog 3, Type 2, Revision 7 > [ 966.714105] b43-phy3 debug: Found Radio: Manuf 0x17F, Version 0x2050, > Revision 8 > [ 966.734069] phy3: Selected rate control algorithm 'pid' > [ 966.736778] Broadcom 43xx driver loaded [ Features: PNR, Firmware-ID: > FW13 ] > [ 988.593922] input: b43-phy3 as /class/input/input8 > [ 987.781568] b43-phy3: Loading firmware version 351.126 (2006-07-29 > 05:54:02) > [ 987.781568] b43-phy3 warning: You are using an old firmware image. > Support for old firmware will be removed in July 2008. > [ 987.781568] b43-phy3 warning: You must go to > http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download > the latest firmware (version 4). > [ 987.895936] b43-phy3 debug: Chip initialized > [ 987.896206] b43-phy3 debug: 32-bit DMA initialized > [ 988.967223] b43-phy3 debug: Wireless interface started > [ 988.967247] b43-phy3 debug: Adding Interface type 2 > [ 988.981264] phy3: HW CONFIG: freq=2412 > [ 991.039238] b43-phy3 debug: Removing Interface type 2 > [ 991.061533] b43-phy3 debug: Wireless interface stopped > [ 990.024893] b43-phy3 debug: DMA-32 rx_ring: Used slots 0/64, Failed > frames 0/0 = 0.0%, Average tries 0.00 > [ 990.026360] b43-phy3 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, > Failed frames 0/0 = 0.0%, Average tries 0.00 > [ 990.031396] b43-phy3 debug: DMA-32 tx_ring_AC_BE: Used slots 0/128, > Failed frames 0/0 = 0.0%, Average tries 0.00 > [ 990.038040] b43-phy3 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, > Failed frames 0/0 = 0.0%, Average tries 0.00 > [ 990.048005] b43-phy3 debug: DMA-32 tx_ring_AC_VO: Used slots 0/128, > Failed frames 0/0 = 0.0%, Average tries 0.00 > [ 990.056402] b43-phy3 debug: DMA-32 tx_ring_mcast: Used slots 0/128, > Failed frames 0/0 = 0.0%, Average tries 0.00 Hmm, that looks like no data reaches the TX rings. For comparision, can you post the output of a non-Asus 4318? What happens if you flash a non-Asus SPROM into the card? -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: >> I'm glad it is not working. > > Haha. And people call _me_ inhuman. :D > Believe me, you have no corner on that market! You just happen to be the only one that has been called that on this list. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > >> I'm glad it is not working. >> > > Haha. And people call _me_ inhuman. :D > > No, _people_ did not call you inhuman. A non-human called you inhuman. E ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Thursday 17 April 2008 19:07:22 Larry Finger wrote: > I'm glad it is not working. Haha. And people call _me_ inhuman. :D -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > > Yeah well. I got the card and indeed it isn't able to transmit any data. > Of course I can't make any forecasts on whether I will be able to solve > this issue, but I will look into it. > Thanks a lot for _finally_ providing me one of these cards instead of > providing only hatemail (not you, but other people) :) > > The device doesn't produce any transmit status reports. I'm glad it is not working. I was afraid that you would get it, and by some quirk of nature everything would work there. I will be very interested in seeing what turns out to be the problem. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 17:56:30 Larry Finger wrote: > > > Any ASUS WL-138G V2 R3.00 or R3.01 would fit the bill. The chip is a > > > BCM4318. If anyone has one in Europe and is willing to participate, > > > that would be great. If not, I could send the one that I have. It was > > > donated to me, and I would not need it to be replaced; however, > > > amazon.de has one for sale for 16 Euro, which is about what it would > > > cost for me to ship mine to you if you want it anytime soon. > > > > This one? > > > > http://www.amazon.de/ASUS-WL-138G-Funk-LAN-Adapter-Mbps/dp/B000H5UYCC/ref=sr_1_1?ie=UTF8&s=ce-de&qid=1208186185&sr=8-1 > > > > I'll immediately order it, if you're sure that's one that doesn't work. > > > > The picture looks exactly like mine. Yeah well. I got the card and indeed it isn't able to transmit any data. Of course I can't make any forecasts on whether I will be able to solve this issue, but I will look into it. Thanks a lot for _finally_ providing me one of these cards instead of providing only hatemail (not you, but other people) :) The device doesn't produce any transmit status reports. That's what I see from a first look. Here come some hardware details in case somebody is interested: [ 966.619496] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) [ 966.619496] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) [ 966.619496] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) [ 966.619496] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) [ 966.637500] ssb: SPROM revision 2 detected. [ 966.658366] ssb: Sonics Silicon Backplane found on PCI device :02:05.0 [ 966.674476] b43-phy3: Broadcom 4318 WLAN found [ 966.714105] b43-phy3 debug: Found PHY: Analog 3, Type 2, Revision 7 [ 966.714105] b43-phy3 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 [ 966.734069] phy3: Selected rate control algorithm 'pid' [ 966.736778] Broadcom 43xx driver loaded [ Features: PNR, Firmware-ID: FW13 ] [ 988.593922] input: b43-phy3 as /class/input/input8 [ 987.781568] b43-phy3: Loading firmware version 351.126 (2006-07-29 05:54:02) [ 987.781568] b43-phy3 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008. [ 987.781568] b43-phy3 warning: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4). [ 987.895936] b43-phy3 debug: Chip initialized [ 987.896206] b43-phy3 debug: 32-bit DMA initialized [ 988.967223] b43-phy3 debug: Wireless interface started [ 988.967247] b43-phy3 debug: Adding Interface type 2 [ 988.981264] phy3: HW CONFIG: freq=2412 [ 991.039238] b43-phy3 debug: Removing Interface type 2 [ 991.061533] b43-phy3 debug: Wireless interface stopped [ 990.024893] b43-phy3 debug: DMA-32 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 990.026360] b43-phy3 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 990.031396] b43-phy3 debug: DMA-32 tx_ring_AC_BE: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 990.038040] b43-phy3 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 990.048005] b43-phy3 debug: DMA-32 tx_ring_AC_VO: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 [ 990.056402] b43-phy3 debug: DMA-32 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
I don't know about Larry's card, but mine doesn't transmit at all, except for maybe noise. When I tried to associate with my AP, while kismetting on an RT73 USB card on the same channel placed 1M from my 4318's antenna, I couldn't record any transmission. Trying the other way around (associating through the RT73 and kismetting on the 4318) shown the association packets in Kismet. On Wed, Apr 16, 2008 at 5:10 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Wednesday 16 April 2008 16:42:16 Larry Finger wrote: > > Stefanik Gábor wrote: > > > Looks like this is an Asus-specific issue. Can you try flashing the > > > attached SPROM file (with a modified MAC address, of course) into your > > > card to see if it results in *any* transmission? (Back up your SPROM > > > first!) This is from a non-Asus 4318/02, extracted from a working > card. > > > (I can't test it myself now, as I don't have a usable Linux system > ATM.) > > > > > > Also, what radio is WL-138G V2 using? Is it the same radio as other > > > 4318/02 cards? Someone with a broken WL-138G V2 should check. (With a > > > broken one, since you need to remove the radio's cover.) > > > > I agree that this is an ASUS-specific issue; however, as I have been > > chastised about too much speculation over this problem, > > Oh, wasn't meant like this. :) > I just wanted to say that you're most likely not going to find the bug > this way. :) > > > I have to be > > careful. My one question is as follows: If the problem were to be due > > to the contents of the SPROM, or even the radio used by the chip, how > > does bcm43xx manage to make it work when b43 cannot? > > Well, the SPROM code was completely rewritten and the radio code was > partially rewritten. So there's enough room for bugs. :) > There are several SPROM values that affect TX heavily. > > Do you have a WLAN spectrum analyzer btw? Can you test whether there > actually > is a signal produced by the card? > I hope that my card will arrive soon, so I can test this as well... > > -- > Greetings Michael. > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Wednesday 16 April 2008 16:42:16 Larry Finger wrote: > Stefanik Gábor wrote: > > Looks like this is an Asus-specific issue. Can you try flashing the > > attached SPROM file (with a modified MAC address, of course) into your > > card to see if it results in *any* transmission? (Back up your SPROM > > first!) This is from a non-Asus 4318/02, extracted from a working card. > > (I can't test it myself now, as I don't have a usable Linux system ATM.) > > > > Also, what radio is WL-138G V2 using? Is it the same radio as other > > 4318/02 cards? Someone with a broken WL-138G V2 should check. (With a > > broken one, since you need to remove the radio's cover.) > > I agree that this is an ASUS-specific issue; however, as I have been > chastised about too much speculation over this problem, Oh, wasn't meant like this. :) I just wanted to say that you're most likely not going to find the bug this way. :) > I have to be > careful. My one question is as follows: If the problem were to be due > to the contents of the SPROM, or even the radio used by the chip, how > does bcm43xx manage to make it work when b43 cannot? Well, the SPROM code was completely rewritten and the radio code was partially rewritten. So there's enough room for bugs. :) There are several SPROM values that affect TX heavily. Do you have a WLAN spectrum analyzer btw? Can you test whether there actually is a signal produced by the card? I hope that my card will arrive soon, so I can test this as well... -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Stefanik Gábor wrote: > Looks like this is an Asus-specific issue. Can you try flashing the > attached SPROM file (with a modified MAC address, of course) into your > card to see if it results in *any* transmission? (Back up your SPROM > first!) This is from a non-Asus 4318/02, extracted from a working card. > (I can't test it myself now, as I don't have a usable Linux system ATM.) > > Also, what radio is WL-138G V2 using? Is it the same radio as other > 4318/02 cards? Someone with a broken WL-138G V2 should check. (With a > broken one, since you need to remove the radio's cover.) I agree that this is an ASUS-specific issue; however, as I have been chastised about too much speculation over this problem, I have to be careful. My one question is as follows: If the problem were to be due to the contents of the SPROM, or even the radio used by the chip, how does bcm43xx manage to make it work when b43 cannot? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Is that the same radio as the one used by other 4318 cards? It might be interesting to know. Also, has anyone tested a WL-138gE (BCM4318E chipset with RangeBooster and SpeedBooster) with b43? Supposedly that one uses a different radio. On Wed, Apr 16, 2008 at 11:09 AM, kala mazoo <[EMAIL PROTECTED]> wrote: > > > Stefanik G?bor wrote: > > Also, what radio is WL-138G V2 using? Is it the same radio as other > > 4318/02 cards? Someone with a broken WL-138G V2 should check. > > (With a broken one, since you need to remove the radio's cover.) > > I sent Larry the card, so this info should be good for his example as > well > > The RF shield cover removes quite easily ~ I take it the radio IC is the > 16 > legged SOIC device? If so, it's markings read ; > >sst >12LP14A >707233 > > If you need know anything else about what's in the can, let me know. > > >Regards, > > Donald > _ > Search for local singles online @ Lavalife - Click here > > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
> Stefanik G?bor wrote: > Also, what radio is WL-138G V2 using? Is it the same radio as other > 4318/02 cards? Someone with a broken WL-138G V2 should check. > (With a broken one, since you need to remove the radio's cover.) I sent Larry the card, so this info should be good for his example as well The RF shield cover removes quite easily ~ I take it the radio IC is the 16 legged SOIC device? If so, it's markings read ; sst 12LP14A 707233 If you need know anything else about what's in the can, let me know. Regards, Donald _ Search for local singles online @ Lavalife - Click here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Oops, sorry, here is the attached SPROM file. On Tue, Apr 15, 2008 at 11:39 PM, Stefanik Gábor <[EMAIL PROTECTED]> wrote: > Looks like this is an Asus-specific issue. Can you try flashing the > attached SPROM file (with a modified MAC address, of course) into your card > to see if it results in *any* transmission? (Back up your SPROM first!) This > is from a non-Asus 4318/02, extracted from a working card. (I can't test it > myself now, as I don't have a usable Linux system ATM.) > > Also, what radio is WL-138G V2 using? Is it the same radio as other > 4318/02 cards? Someone with a broken WL-138G V2 should check. (With a broken > one, since you need to remove the radio's cover.) > > > > On Tue, Apr 15, 2008 at 3:37 AM, Larry Finger <[EMAIL PROTECTED]> > wrote: > > > Stefanik Gábor wrote: > > > > > Larry, can you attach an SPROM dump of your PCI BCM4318? I'm suffering > > > from the exact same problem, and it would be interesting to find out what > > > is > > > actually happening. Also, what card do you have? (Mine is an Asus WL-138G > > > V2 > > > R3.01, but R3.00 is affected too.) Please attach an lspci -v and lspci -vn > > > output too (or at least the revision number reported by lspci). > > > > > > > Here is the dump of the SPROM: > > > > 01200F1043101843008002100018FF > > FF > > 1B0061FC61194230CA157DFA38FF3E > > 003E00490002FF424709FF81130242 > > > > My card is an ASUS WL-138G V2 R3.00. I forgot to get the lspci output, > > but will send it tomorrow. > > > > Larry > > > > > > -- > Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) 4318.sprom Description: Binary data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Looks like this is an Asus-specific issue. Can you try flashing the attached SPROM file (with a modified MAC address, of course) into your card to see if it results in *any* transmission? (Back up your SPROM first!) This is from a non-Asus 4318/02, extracted from a working card. (I can't test it myself now, as I don't have a usable Linux system ATM.) Also, what radio is WL-138G V2 using? Is it the same radio as other 4318/02 cards? Someone with a broken WL-138G V2 should check. (With a broken one, since you need to remove the radio's cover.) On Tue, Apr 15, 2008 at 3:37 AM, Larry Finger <[EMAIL PROTECTED]> wrote: > Stefanik Gábor wrote: > > > Larry, can you attach an SPROM dump of your PCI BCM4318? I'm suffering > > from the exact same problem, and it would be interesting to find out what is > > actually happening. Also, what card do you have? (Mine is an Asus WL-138G V2 > > R3.01, but R3.00 is affected too.) Please attach an lspci -v and lspci -vn > > output too (or at least the revision number reported by lspci). > > > > Here is the dump of the SPROM: > > 01200F1043101843008002100018FF > FF > 1B0061FC61194230CA157DFA38FF3E > 003E00490002FF424709FF81130242 > > My card is an ASUS WL-138G V2 R3.00. I forgot to get the lspci output, but > will send it tomorrow. > > Larry > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Stefanik Gábor wrote: > Larry, can you attach an SPROM dump of your PCI BCM4318? I'm suffering > from the exact same problem, and it would be interesting to find out > what is actually happening. Also, what card do you have? (Mine is an > Asus WL-138G V2 R3.01, but R3.00 is affected too.) Please attach an > lspci -v and lspci -vn output too (or at least the revision number > reported by lspci). Here is the dump of the SPROM: 01200F1043101843008002100018FF FF 1B0061FC61194230CA157DFA38FF3E 003E00490002FF424709FF81130242 My card is an ASUS WL-138G V2 R3.00. I forgot to get the lspci output, but will send it tomorrow. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 17:56:30 Larry Finger wrote: > > This one? > > > > http://www.amazon.de/ASUS-WL-138G-Funk-LAN-Adapter-Mbps/dp/B000H5UYCC/ref=sr_1_1?ie=UTF8&s=ce-de&qid=1208186185&sr=8-1 > > > > I'll immediately order it, if you're sure that's one that doesn't work. > > > > The picture looks exactly like mine. Ok, I ordered it. Let's hope they didn't upgrade the chipset in the meantime :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 17:01:04 Larry Finger wrote: > Michael Buesch wrote: > > > > What do the target_idle_tssi from SPROM and the current_idle_tssi read > > from the PHY look like? They should be almost equal. If not, this could > > result in a complete TX breakage. > > Would an idle_tssi problem also prevent DMA interrupts? That doesn't > seem likely to me. I don't know. But I think this whole discussion is too much based on theoretical speculations on what _could_ be going on. The _only_ way I found out why stuff didn't work in the past was by printing random values and registers. That's really the only way you can get a _whole_ picture of what's going on. So you have some assumptions that you know are right and then you check them. In this case the idle_tssi. We know that abs(current - idle) <= 20, so we should check whether that's the case. If it is, fine, go over to the next check. This way we got several PCI, SSB, and PCMCIA chips working and I'm pretty sure it's the only way to get a device working, until someone proves me wrong. :) Of course on regressions one can also compare some code. But in this case the code changes are simply too big. It's basically a rewrite. So that would not be the first thing I'd do. In fact, it would be the very last. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 16:56:56 Larry Finger wrote: > Michael Buesch wrote: > > > > I'd really _love_ to know where to get a b43 (not legacy) device > > that worked in bcm43xx and broke in b43. Somebody any pointers? Or maybe > > someone > > could probably donate one? We can also do things like: You ship > > me your card that doesn't work and I will buy you another one that does > > work. > > Anyone? > > > > Any ASUS WL-138G V2 R3.00 or R3.01 would fit the bill. The chip is a > BCM4318. If anyone has one in Europe and is willing to participate, > that would be great. If not, I could send the one that I have. It was > donated to me, and I would not need it to be replaced; however, > amazon.de has one for sale for 16 Euro, which is about what it would > cost for me to ship mine to you if you want it anytime soon. This one? http://www.amazon.de/ASUS-WL-138G-Funk-LAN-Adapter-Mbps/dp/B000H5UYCC/ref=sr_1_1?ie=UTF8&s=ce-de&qid=1208186185&sr=8-1 I'll immediately order it, if you're sure that's one that doesn't work. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > > What do the target_idle_tssi from SPROM and the current_idle_tssi read > from the PHY look like? They should be almost equal. If not, this could > result in a complete TX breakage. Would an idle_tssi problem also prevent DMA interrupts? That doesn't seem likely to me. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > > I'd really _love_ to know where to get a b43 (not legacy) device > that worked in bcm43xx and broke in b43. Somebody any pointers? Or maybe > someone > could probably donate one? We can also do things like: You ship > me your card that doesn't work and I will buy you another one that does work. > Anyone? > Any ASUS WL-138G V2 R3.00 or R3.01 would fit the bill. The chip is a BCM4318. If anyone has one in Europe and is willing to participate, that would be great. If not, I could send the one that I have. It was donated to me, and I would not need it to be replaced; however, amazon.de has one for sale for 16 Euro, which is about what it would cost for me to ship mine to you if you want it anytime soon. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 02:42:55 Pavel Roskin wrote: > On Sun, 2008-04-13 at 19:36 -0500, Larry Finger wrote: > > > Do you have any PCI (not Cardbus) devices that work with b43? Do you > > know of anyone that does? > > I have MiniPCI cards with bcm4306 and bcm4318, and both are working fine > with the latest b43. I tired them in a PCI adapter and in a Thinkpad > T30 laptop, which has a MiniPCI slot. No problems whatsoever. I'd really _love_ to know where to get a b43 (not legacy) device that worked in bcm43xx and broke in b43. Somebody any pointers? Or maybe someone could probably donate one? We can also do things like: You ship me your card that doesn't work and I will buy you another one that does work. Anyone? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Monday 14 April 2008 01:08:53 Stefano Brivio wrote: > On Tue, 08 Apr 2008 14:11:04 -0500 > Larry Finger <[EMAIL PROTECTED]> wrote: > > > 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was > > finally able to read beacons; however, no output interrupts were > > delivered. > > [...] > > > I'm still looking for some differences > > between bcm43xx and b43legacy regarding B-PHY and/or radio > > initialization. > > Same here, without any appreciable result. Packets reach the PHY, and the > radio seems to be set up correctly, but still nothing hits the air. I'll > investigate further. > > Out of curiosity, do you get weird values for LEDs in SPROM too? On my > bcm4301, it looks like a lot of values in SPROM are unknown or somehow > misinterpreted, like these ones: > [ 6781.374512] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x44 > [ 6781.374520] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x46 > [ 6781.374527] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x12 > [ 6781.374534] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x4D What do the target_idle_tssi from SPROM and the current_idle_tssi read from the PHY look like? They should be almost equal. If not, this could result in a complete TX breakage. > But I don't actually think that this is causing the issues we are seeing > with TX. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Larry, can you attach an SPROM dump of your PCI BCM4318? I'm suffering from the exact same problem, and it would be interesting to find out what is actually happening. Also, what card do you have? (Mine is an Asus WL-138G V2 R3.01, but R3.00 is affected too.) Please attach an lspci -v and lspci -vn output too (or at least the revision number reported by lspci). On Mon, Apr 14, 2008 at 2:36 AM, Larry Finger <[EMAIL PROTECTED]> wrote: > Stefano Brivio wrote: > > On Tue, 08 Apr 2008 14:11:04 -0500 > > Larry Finger <[EMAIL PROTECTED]> wrote: > > > >> 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was > >> finally able to read beacons; however, no output interrupts were > >> delivered. > > > > [...] > > > >> I'm still looking for some differences > >> between bcm43xx and b43legacy regarding B-PHY and/or radio > >> initialization. > > > > Same here, without any appreciable result. Packets reach the PHY, and > the > > radio seems to be set up correctly, but still nothing hits the air. I'll > > investigate further. > > > > Out of curiosity, do you get weird values for LEDs in SPROM too? On my > > bcm4301, it looks like a lot of values in SPROM are unknown or somehow > > misinterpreted, like these ones: > > [ 6781.374512] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x44 > > [ 6781.374520] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x46 > > [ 6781.374527] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x12 > > [ 6781.374534] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x4D > > > > But I don't actually think that this is causing the issues we are seeing > > with TX. > > I don't either. Yes, I got those same warnings until I turned RFKILL, > etc. off in my config. In any case, the LEDS are in the back where I > cannot see them anyway. > > Do you have any PCI (not Cardbus) devices that work with b43? Do you > know of anyone that does? > > I tried my PCI-based BCM4318 with the version of b43 that was > introduced in the 2.6.24 merge, but it didn't work either. I can > receive data, but not transmit. The code gets all the way to where it > pokes the DMA transmission, and the interrupts are all enabled > correctly, but no TX interrupts are delivered. This is a regression > against bcm43xx, but has been in b43 and b43legacy since they were > introduced into mainline. My gut says that both b43 and b43legacy are > affected by a common problem. I no longer have a wireless-2.6 tree to > check back further, but it may be necessary to do so. > > Larry > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Sun, 2008-04-13 at 19:36 -0500, Larry Finger wrote: > Do you have any PCI (not Cardbus) devices that work with b43? Do you > know of anyone that does? I have MiniPCI cards with bcm4306 and bcm4318, and both are working fine with the latest b43. I tired them in a PCI adapter and in a Thinkpad T30 laptop, which has a MiniPCI slot. No problems whatsoever. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Stefano Brivio wrote: > On Tue, 08 Apr 2008 14:11:04 -0500 > Larry Finger <[EMAIL PROTECTED]> wrote: > >> 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was >> finally able to read beacons; however, no output interrupts were >> delivered. > > [...] > >> I'm still looking for some differences >> between bcm43xx and b43legacy regarding B-PHY and/or radio >> initialization. > > Same here, without any appreciable result. Packets reach the PHY, and the > radio seems to be set up correctly, but still nothing hits the air. I'll > investigate further. > > Out of curiosity, do you get weird values for LEDs in SPROM too? On my > bcm4301, it looks like a lot of values in SPROM are unknown or somehow > misinterpreted, like these ones: > [ 6781.374512] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x44 > [ 6781.374520] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x46 > [ 6781.374527] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x12 > [ 6781.374534] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x4D > > But I don't actually think that this is causing the issues we are seeing > with TX. I don't either. Yes, I got those same warnings until I turned RFKILL, etc. off in my config. In any case, the LEDS are in the back where I cannot see them anyway. Do you have any PCI (not Cardbus) devices that work with b43? Do you know of anyone that does? I tried my PCI-based BCM4318 with the version of b43 that was introduced in the 2.6.24 merge, but it didn't work either. I can receive data, but not transmit. The code gets all the way to where it pokes the DMA transmission, and the interrupts are all enabled correctly, but no TX interrupts are delivered. This is a regression against bcm43xx, but has been in b43 and b43legacy since they were introduced into mainline. My gut says that both b43 and b43legacy are affected by a common problem. I no longer have a wireless-2.6 tree to check back further, but it may be necessary to do so. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Tue, 08 Apr 2008 14:11:04 -0500 Larry Finger <[EMAIL PROTECTED]> wrote: > 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was > finally able to read beacons; however, no output interrupts were > delivered. [...] > I'm still looking for some differences > between bcm43xx and b43legacy regarding B-PHY and/or radio > initialization. Same here, without any appreciable result. Packets reach the PHY, and the radio seems to be set up correctly, but still nothing hits the air. I'll investigate further. Out of curiosity, do you get weird values for LEDs in SPROM too? On my bcm4301, it looks like a lot of values in SPROM are unknown or somehow misinterpreted, like these ones: [ 6781.374512] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x44 [ 6781.374520] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x46 [ 6781.374527] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x12 [ 6781.374534] b43legacy-phy2 warning: LEDs: Unknown behaviour 0x4D But I don't actually think that this is causing the issues we are seeing with TX. -- Ciao Stefano ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Wednesday 09 April 2008 18:13:20 Larry Finger wrote: > Michael Buesch wrote: > > > So, well. I'd say the new code is identical. The IHR bit is set earlier. > > The INFRA bit is just bogus to set here. We set it later when selecting > > the operation mode. b43legacy_adjust_opmode() > > > > The fact that the while-loop does exit without an error means that the > > microcode > > does in fact run properly. > > > > I'd probably print the value of the MACCTL register just after > > the IRQ_REASON write. > > I don't know what happened, but when I tested further, the extra test > of the ucode running was not needed. > > I have some questions about the MACCTL register and phy->gmode. Should > the GMODE bit in MACCTL only be set if the device has a G PHY, and > should phy->gmode stay zero for my B-PHY device? I have no idea. I _guess_ it should be set. "Gmode" does actually mean "use the 2.4GHz-band PHY", as far as I can tell. The gmode bit in the MACCTL is not that important. In fact, we didn't set it for a long time and I think bcm43xx doesn't properly set that, too. But phy->gmode is pretty important to get right. But usually it results in machine-check exceptions when set wrong on a unicore-PHY. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
Michael Buesch wrote: > So, well. I'd say the new code is identical. The IHR bit is set earlier. > The INFRA bit is just bogus to set here. We set it later when selecting > the operation mode. b43legacy_adjust_opmode() > > The fact that the while-loop does exit without an error means that the > microcode > does in fact run properly. > > I'd probably print the value of the MACCTL register just after > the IRQ_REASON write. I don't know what happened, but when I tested further, the extra test of the ucode running was not needed. I have some questions about the MACCTL register and phy->gmode. Should the GMODE bit in MACCTL only be set if the device has a G PHY, and should phy->gmode stay zero for my B-PHY device? Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Tuesday 08 April 2008 22:56:33 Michael Buesch wrote:
> On Tuesday 08 April 2008 21:11:04 Larry Finger wrote:
> > Michael,
> >
> > I'm gaining on my problems with 2 PCI (not Cardbus) cards, which are
> > as follows:
> >
> > 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was
> > finally able to read beacons; however, no output interrupts were
> > delivered. By comparing the code in bcm43xx with that of b43legacy, I
> > found a section that had not been transferred. In it all bits are set
> > in B43legacy_MMIO_GEN_IRQ_REASON, the magic number 0x20402 is written
> > to B43legacy_MMIO_MACCTL, and the program spins waiting for IRQ_READY.
> > I was able to simplify the code to the following:
> >
> > b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_REASON,
> > 0x);
> > b43legacy_write32(dev, B43legacy_MMIO_MACCTL, 0x00020402);
> > msleep(1);
> > b43legacy_read32(dev, B43legacy_MMIO_GEN_IRQ_REASON);
>
> _where_ is this code?
>
Oh I see. This is the code that waits for microcode init.
Well. In fact this code _has_ been transferred. It has just been un-magic'ed.
1623 b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_REASON,
1624 B43legacy_IRQ_ALL);
1625
1626 /* Start the microcode PSM */
1627 macctl = b43legacy_read32(dev, B43legacy_MMIO_MACCTL);
1628 macctl &= ~B43legacy_MACCTL_PSM_JMP0;
1629 macctl |= B43legacy_MACCTL_PSM_RUN;
1630 b43legacy_write32(dev, B43legacy_MMIO_MACCTL, macctl);
1631
1632 /* Wait for the microcode to load and respond */
1633 i = 0;
1634 while (1) {
1635 tmp = b43legacy_read32(dev, B43legacy_MMIO_GEN_IRQ_REASON);
1636 if (tmp == B43legacy_IRQ_MAC_SUSPENDED)
1637 break;
1638 i++;
1639 if (i >= B43legacy_IRQWAIT_MAX_RETRIES) {
1640 b43legacyerr(dev->wl, "Microcode not
responding\n");
1641 b43legacy_print_fw_helptext(dev->wl);
1642 err = -ENODEV;
1643 goto error;
1644 }
1645 msleep_interruptible(50);
1646 if (signal_pending(current)) {
1647 err = -EINTR;
1648 goto error;
1649 }
1650 }
1651 /* dummy read follows */
1652 b43legacy_read32(dev, B43legacy_MMIO_GEN_IRQ_REASON);
The macctl bits of the magic number are:
190 #define B43legacy_MACCTL_PSM_RUN0x0002
193 #define B43legacy_MACCTL_IHR_ENABLED0x0400
195 #define B43legacy_MACCTL_INFRA 0x0002
So, well. I'd say the new code is identical. The IHR bit is set earlier.
The INFRA bit is just bogus to set here. We set it later when selecting
the operation mode. b43legacy_adjust_opmode()
The fact that the while-loop does exit without an error means that the microcode
does in fact run properly.
I'd probably print the value of the MACCTL register just after
the IRQ_REASON write.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with PCI (not Cardbus) BCM43xx
On Tuesday 08 April 2008 21:11:04 Larry Finger wrote: > Michael, > > I'm gaining on my problems with 2 PCI (not Cardbus) cards, which are > as follows: > > 1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was > finally able to read beacons; however, no output interrupts were > delivered. By comparing the code in bcm43xx with that of b43legacy, I > found a section that had not been transferred. In it all bits are set > in B43legacy_MMIO_GEN_IRQ_REASON, the magic number 0x20402 is written > to B43legacy_MMIO_MACCTL, and the program spins waiting for IRQ_READY. > I was able to simplify the code to the following: > > b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_REASON, >0x); > b43legacy_write32(dev, B43legacy_MMIO_MACCTL, 0x00020402); > msleep(1); > b43legacy_read32(dev, B43legacy_MMIO_GEN_IRQ_REASON); _where_ is this code? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
