Re: opensource firmware now accept version 410 frames
Hmmm, I think the cookies should actually be more or less sequential, if QoS and PIO are not used. That's rather strange. Can you try with original fw and see what the cookies look like? Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 and cookie value goes from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Saturday 31 January 2009 12:20:18 Lorenzo Nava wrote: Hmmm, I think the cookies should actually be more or less sequential, if QoS and PIO are not used. That's rather strange. Can you try with original fw and see what the cookies look like? Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 and cookie value goes from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? Why are your cookies endianness swapped? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 31, 2009, at 12:23 PM, Michael Buesch wrote: On Saturday 31 January 2009 12:20:18 Lorenzo Nava wrote: Hmmm, I think the cookies should actually be more or less sequential, if QoS and PIO are not used. That's rather strange. Can you try with original fw and see what the cookies look like? Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 and cookie value goes from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? Why are your cookies endianness swapped? I forgot to say that these numbers are related to tx header, so I now need to check what report_tx_status send back... -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add LP-PHY register definitions
This adds register definitions for the LP-PHY.
This also adds a few minor empty function bodies for the LP-init.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
I'll let you decide whether you queue this for the next feature release
or the next -rc. I lost track of what the rules are for this kind of change.
Note that all this code currently is under BROKEN dependency.
So it won't even be compiled without changing the Kconfig first.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009-01-31
13:15:22.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy_lp.c 2009-01-31
13:35:47.0 +0100
@@ -57,8 +57,41 @@ static void b43_lpphy_op_free(struct b43
dev-phy.lp = NULL;
}
+static void lpphy_table_init(struct b43_wldev *dev)
+{
+ //TODO
+}
+
+static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
+{
+ B43_WARN_ON(1);//TODO rev 2 not supported, yet.
+}
+
+static void lpphy_baseband_rev2plus_init(struct b43_wldev *dev)
+{
+ //TODO
+}
+
+static void lpphy_baseband_init(struct b43_wldev *dev)
+{
+ lpphy_table_init(dev);
+ if (dev-phy.rev = 2)
+ lpphy_baseband_rev2plus_init(dev);
+ else
+ lpphy_baseband_rev0_1_init(dev);
+}
+
+static void lpphy_radio_init(struct b43_wldev *dev)
+{
+ //TODO
+}
+
static int b43_lpphy_op_init(struct b43_wldev *dev)
{
+ /* TODO: band SPROM */
+ lpphy_baseband_init(dev);
+ lpphy_radio_init(dev);
+
//TODO
return 0;
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.h 2009-01-31
14:04:07.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy_lp.h 2009-01-31
14:20:09.0 +0100
@@ -4,8 +4,281 @@
/* Definitions for the LP-PHY */
+/* The CCK PHY register range. */
+#define B43_LPPHY_B_VERSIONB43_PHY_CCK(0x00) /* B PHY
version */
+#define B43_LPPHY_B_BBCONFIG B43_PHY_CCK(0x01) /* B PHY
BBConfig */
+#define B43_LPPHY_B_RX_STAT0 B43_PHY_CCK(0x04) /* B PHY RX
Status0 */
+#define B43_LPPHY_B_RX_STAT1 B43_PHY_CCK(0x05) /* B PHY RX
Status1 */
+#define B43_LPPHY_B_CRS_THRESH B43_PHY_CCK(0x06) /* B PHY CRS
Thresh */
+#define B43_LPPHY_B_TXERRORB43_PHY_CCK(0x07) /* B PHY
TxError */
+#define B43_LPPHY_B_CHANNELB43_PHY_CCK(0x08) /* B PHY
Channel */
+#define B43_LPPHY_B_WORKAROUND B43_PHY_CCK(0x09) /* B PHY
workaround */
+#define B43_LPPHY_B_TEST B43_PHY_CCK(0x0A) /* B PHY Test
*/
+#define B43_LPPHY_B_FOURWIRE_ADDR B43_PHY_CCK(0x0B) /* B PHY
Fourwire Address */
+#define B43_LPPHY_B_FOURWIRE_DATA_HI B43_PHY_CCK(0x0C) /* B PHY
Fourwire Data Hi */
+#define B43_LPPHY_B_FOURWIRE_DATA_LO B43_PHY_CCK(0x0D) /* B PHY
Fourwire Data Lo */
+#define B43_LPPHY_B_BIST_STAT B43_PHY_CCK(0x0E) /* B PHY Bist
Status */
+#define B43_LPPHY_PA_RAMP_TX_TOB43_PHY_CCK(0x10) /* PA
Ramp TX Timeout */
+#define B43_LPPHY_RF_SYNTH_DC_TIMERB43_PHY_CCK(0x11) /* RF Synth
DC Timer */
+#define B43_LPPHY_PA_RAMP_TX_TIME_IN B43_PHY_CCK(0x12) /* PA ramp TX
Time in */
+#define B43_LPPHY_RX_FILTER_TIME_INB43_PHY_CCK(0x13) /* RX Filter
Time in */
+#define B43_LPPHY_PLL_COEFF_S B43_PHY_CCK(0x18) /* PLL
Coefficient(s) */
+#define B43_LPPHY_PLL_OUT B43_PHY_CCK(0x19) /* PLL Out */
+#define B43_LPPHY_RSSI_THRES B43_PHY_CCK(0x20) /* RSSI
Threshold */
+#define B43_LPPHY_IQ_THRES_HH B43_PHY_CCK(0x21) /* IQ
Threshold HH */
+#define B43_LPPHY_IQ_THRES_H B43_PHY_CCK(0x22) /* IQ
Threshold H */
+#define B43_LPPHY_IQ_THRES_L B43_PHY_CCK(0x23) /* IQ
Threshold L */
+#define B43_LPPHY_IQ_THRES_LL B43_PHY_CCK(0x24) /* IQ
Threshold LL */
+#define B43_LPPHY_AGC_GAIN B43_PHY_CCK(0x25) /* AGC Gain */
+#define B43_LPPHY_LNA_GAIN_RANGE B43_PHY_CCK(0x26) /* LNA Gain
Range */
+#define B43_LPPHY_JSSI B43_PHY_CCK(0x27) /* JSSI */
+#define B43_LPPHY_TSSI_CTL B43_PHY_CCK(0x28) /* TSSI
Control */
+#define B43_LPPHY_TSSI B43_PHY_CCK(0x29) /* TSSI */
+#define B43_LPPHY_TR_LOSS B43_PHY_CCK(0x2A) /* TR Loss */
+#define B43_LPPHY_LO_LEAKAGE B43_PHY_CCK(0x2B) /* LO Leakage
*/
+#define B43_LPPHY_LO_RSSIACC B43_PHY_CCK(0x2C) /* LO RSSIAcc
*/
+#define B43_LPPHY_LO_IQ_MAG_ACCB43_PHY_CCK(0x2D) /* LO
IQ Mag Acc */
+#define
[PATCH] b43: Add LP-PHY baseband init for =rev2
This adds code for the baseband init of LP-PHY =2.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009-01-31
16:16:57.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/Makefile 2009-01-31
16:17:18.0 +0100
@@ -6,6 +6,7 @@ b43-y += phy_g.o
b43-y += phy_a.o
b43-$(CONFIG_B43_NPHY) += phy_n.o
b43-$(CONFIG_B43_PHY_LP) += phy_lp.o
+b43-$(CONFIG_B43_PHY_LP) += tables_lpphy.o
b43-y += sysfs.o
b43-y += xmit.o
b43-y += lo.o
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009-01-31
14:28:05.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy_lp.c 2009-01-31
16:45:19.0 +0100
@@ -3,7 +3,7 @@
Broadcom B43 wireless driver
IEEE 802.11g LP-PHY driver
- Copyright (c) 2008 Michael Buesch m...@bu3sch.de
+ Copyright (c) 2008-2009 Michael Buesch m...@bu3sch.de
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -25,6 +25,7 @@
#include b43.h
#include phy_lp.h
#include phy_common.h
+#include tables_lpphy.h
static int b43_lpphy_op_allocate(struct b43_wldev *dev)
@@ -69,7 +70,80 @@ static void lpphy_baseband_rev0_1_init(s
static void lpphy_baseband_rev2plus_init(struct b43_wldev *dev)
{
- //TODO
+ struct b43_phy_lp *lpphy = dev-phy.lp;
+
+ b43_phy_write(dev, B43_LPPHY_AFE_DAC_CTL, 0x50);
+ b43_phy_write(dev, B43_LPPHY_AFE_CTL, 0x8800);
+ b43_phy_write(dev, B43_LPPHY_AFE_CTL_OVR, 0);
+ b43_phy_write(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0);
+ b43_phy_write(dev, B43_LPPHY_RF_OVERRIDE_0, 0);
+ b43_phy_write(dev, B43_LPPHY_RF_OVERRIDE_2, 0);
+ b43_phy_write(dev, B43_PHY_OFDM(0xF9), 0);
+ b43_phy_write(dev, B43_LPPHY_TR_LOOKUP_1, 0);
+ b43_phy_set(dev, B43_LPPHY_ADC_COMPENSATION_CTL, 0x10);
+ b43_phy_maskset(dev, B43_LPPHY_OFDMSYNCTHRESH0, 0xFF00, 0x78);
+ b43_phy_maskset(dev, B43_LPPHY_DCOFFSETTRANSIENT, 0xF8FF, 0x200);
+ b43_phy_maskset(dev, B43_LPPHY_DCOFFSETTRANSIENT, 0xFF00, 0x7F);
+ b43_phy_maskset(dev, B43_LPPHY_GAINDIRECTMISMATCH, 0xFF0F, 0x40);
+ b43_phy_maskset(dev, B43_LPPHY_PREAMBLECONFIRMTO, 0xFF00, 0x2);
+ b43_phy_mask(dev, B43_LPPHY_CRSGAIN_CTL, ~0x4000);
+ b43_phy_mask(dev, B43_LPPHY_CRSGAIN_CTL, ~0x2000);
+ b43_phy_set(dev, B43_PHY_OFDM(0x10A), 0x1);
+ b43_phy_maskset(dev, B43_LPPHY_CCKLMSSTEPSIZE, 0xFF01, 0x10);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0xFF00, 0xF4);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0x00FF, 0xF100);//FIXME specs
are different
+ b43_phy_write(dev, B43_LPPHY_CLIPTHRESH, 0x48);
+ b43_phy_maskset(dev, B43_LPPHY_HIGAINDB, 0xFF00, 0x46);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xE4), 0xFF00, 0x10);
+ b43_phy_maskset(dev, B43_LPPHY_PWR_THRESH1, 0xFFF0, 0x9);
+ b43_phy_mask(dev, B43_LPPHY_GAINDIRECTMISMATCH, ~0xF);
+ b43_phy_maskset(dev, B43_LPPHY_VERYLOWGAINDB, 0x00FF, 0x5500);
+ b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0xF81F, 0xA0);
+ b43_phy_maskset(dev, B43_LPPHY_GAINDIRECTMISMATCH, 0xE0FF, 0x300);
+ b43_phy_maskset(dev, B43_LPPHY_HIGAINDB, 0x00FF, 0x2A00);
+ b43_phy_maskset(dev, B43_LPPHY_LOWGAINDB, 0x00FF, 0x1E00);
+ b43_phy_maskset(dev, B43_LPPHY_VERYLOWGAINDB, 0xFF00, 0xD);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xFE), 0xFFE0, 0x1F);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xFF), 0xFFE0, 0xC);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0x100), 0xFF00, 0x19);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xFF), 0x03FF, 0x3C00);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xFE), 0xFC1F, 0x3E0);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xFF), 0xFFE0, 0xC);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0x100), 0x00FF, 0x1900);
+ b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0x83FF, 0x5800);
+ b43_phy_maskset(dev, B43_LPPHY_CLIPCTRTHRESH, 0xFFE0, 0x12);
+ b43_phy_maskset(dev, B43_LPPHY_GAINMISMATCH, 0x0FFF, 0x9000);
+
+ if (dev-phy.rev 2) {
+ //FIXME this will never execute.
+
+ //FIXME 32bit?
+ b43_lptab_write(dev, B43_LPTAB32(0x11, 0x14), 0);
+ b43_lptab_write(dev, B43_LPTAB32(0x08, 0x12), 0x40);
+ } else {
+ //FIXME 32bit?
+ b43_lptab_write(dev, B43_LPTAB32(0x08, 0x14), 0);
+ b43_lptab_write(dev, B43_LPTAB32(0x08, 0x12), 0x40);
+ }
+
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev,
[PATCH] b43: Add LP 2062 radio init
This adds initialization code for the 2062 radio.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009-01-31
17:19:22.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy_lp.c 2009-01-31
19:24:28.0 +0100
@@ -91,7 +91,7 @@ static void lpphy_baseband_rev2plus_init
b43_phy_set(dev, B43_PHY_OFDM(0x10A), 0x1);
b43_phy_maskset(dev, B43_LPPHY_CCKLMSSTEPSIZE, 0xFF01, 0x10);
b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0xFF00, 0xF4);
- b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0x00FF, 0xF100);//FIXME specs
are different
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0x00FF, 0xF100);
b43_phy_write(dev, B43_LPPHY_CLIPTHRESH, 0x48);
b43_phy_maskset(dev, B43_LPPHY_HIGAINDB, 0xFF00, 0x46);
b43_phy_maskset(dev, B43_PHY_OFDM(0xE4), 0xFF00, 0x10);
@@ -155,11 +155,114 @@ static void lpphy_baseband_init(struct b
lpphy_baseband_rev0_1_init(dev);
}
-static void lpphy_radio_init(struct b43_wldev *dev)
+struct b2062_freqdata {
+ u16 freq;
+ u8 data[6];
+};
+
+/* Initialize the 2062 radio. */
+static void lpphy_2062_init(struct b43_wldev *dev)
+{
+ u32 crystalfreq, pdiv, tmp, ref;
+ unsigned int i;
+ const struct b2062_freqdata *fd = NULL;
+
+ static const struct b2062_freqdata freqdata_tab[] = {
+ { .freq = 12000, .data[0] = 6, .data[1] = 6, .data[2] = 6,
+.data[3] = 6, .data[4] = 10, .data[5] = 6, },
+ { .freq = 13000, .data[0] = 4, .data[1] = 4, .data[2] = 4,
+.data[3] = 4, .data[4] = 11, .data[5] = 7, },
+ { .freq = 14400, .data[0] = 3, .data[1] = 3, .data[2] = 3,
+.data[3] = 3, .data[4] = 12, .data[5] = 7, },
+ { .freq = 16200, .data[0] = 3, .data[1] = 3, .data[2] = 3,
+.data[3] = 3, .data[4] = 13, .data[5] = 8, },
+ { .freq = 18000, .data[0] = 2, .data[1] = 2, .data[2] = 2,
+.data[3] = 2, .data[4] = 14, .data[5] = 8, },
+ { .freq = 19200, .data[0] = 1, .data[1] = 1, .data[2] = 1,
+.data[3] = 1, .data[4] = 14, .data[5] = 9, },
+ };
+
+ b2062_upload_init_table(dev);
+
+ b43_radio_write(dev, B2062_N_TX_CTL3, 0);
+ b43_radio_write(dev, B2062_N_TX_CTL4, 0);
+ b43_radio_write(dev, B2062_N_TX_CTL5, 0);
+ b43_radio_write(dev, B2062_N_PDN_CTL0, 0x40);
+ b43_radio_write(dev, B2062_N_PDN_CTL0, 0);
+ b43_radio_write(dev, B2062_N_CALIB_TS, 0x10);
+ b43_radio_write(dev, B2062_N_CALIB_TS, 0);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ)
+ b43_radio_set(dev, B2062_N_TSSI_CTL0, 0x1);
+ else
+ b43_radio_mask(dev, B2062_N_TSSI_CTL0, ~0x1);
+
+ crystalfreq = 0;//FIXME
+
+ if (crystalfreq = 3000) {
+ pdiv = 1;
+ b43_radio_mask(dev, B2062_S_RFPLL_CTL1, 0xFFFB);
+ } else {
+ pdiv = 2;
+ b43_radio_set(dev, B2062_S_RFPLL_CTL1, 0x4);
+ }
+
+ tmp = (8 * pdiv + crystalfreq) / (3200 * pdiv);
+ tmp = (tmp - 1) 0xFF;
+ b43_radio_write(dev, B2062_S_RFPLL_CTL18, tmp);
+
+ tmp = (2 * crystalfreq + 100 * pdiv) / (200 * pdiv);
+ tmp = ((tmp 0xFF) - 1) 0x;
+ b43_radio_write(dev, B2062_S_RFPLL_CTL19, tmp);
+
+ ref = (1000 * pdiv + 2 * crystalfreq) / (2000 * pdiv);
+ ref = 0x;
+ for (i = 0; i ARRAY_SIZE(freqdata_tab); i++) {
+ if (ref freqdata_tab[i].freq) {
+ fd = freqdata_tab[i];
+ break;
+ }
+ }
+ if (B43_WARN_ON(!fd))
+ return;
+
+ b43_radio_write(dev, B2062_S_RFPLL_CTL8,
+ ((u16)(fd-data[1]) 4) | fd-data[0]);
+ b43_radio_write(dev, B2062_S_RFPLL_CTL9,
+ ((u16)(fd-data[3]) 4) | fd-data[2]);//FIXME specs
are different
+ b43_radio_write(dev, B2062_S_RFPLL_CTL10, fd-data[4]);
+ b43_radio_write(dev, B2062_S_RFPLL_CTL11, fd-data[5]);
+}
+
+/* Initialize the 2063 radio. */
+static void lpphy_2063_init(struct b43_wldev *dev)
{
//TODO
}
+static void lpphy_sync_stx(struct b43_wldev *dev)
+{
+ //TODO
+}
+
+static void lpphy_radio_init(struct b43_wldev *dev)
+{
+ /* The radio is attached through the 4wire bus. */
+ b43_phy_set(dev, B43_LPPHY_FOURWIRE_CTL, 0x2);
+ udelay(1);
+ b43_phy_mask(dev, B43_LPPHY_FOURWIRE_CTL, 0xFFFD);
+ udelay(1);
+
+ if (dev-phy.rev 2) {
+ lpphy_2062_init(dev);
+ } else {
+ lpphy_2063_init(dev);
+
Re: opensource firmware now accept version 410 frames
On Jan 31, 2009, at 7:54 AM, Larry Finger wrote: Francesco, I changed the dma.c code to WARN_ON rather than BUG_ON and also dump the cookie for the erring case. Of course, the system no longer crashes, nor even stops on the first error. I have no idea how many errors occurred before I got it stopped, but the cookies for the first few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, 0x2050, and 0x2052. When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and obtained: [cut] Larry, many thanks for your help in debugging. However I can't reproduce that error. I tried all this afternoon with a 4306rev3 on a CardBus board but all efforts to freeze the PC were useless. I checked again the difference between r5.0 and r5.1 but it is only 10 lines... so easy to debug that I'm pretty sure that error is not due to changes into header offsets. Is there any way for me to me to freeze the interface when the first error occurs without inducing a kernel panic? I don't understand completely your question: if you need to stop the firmware without having its memory corrupted we can add a semaphore just after the WARN_ON into shm so that next loop after state_machine_start we enter an infinite loop. However this would happen after hundreds cycles. Tell me if we can helping adding debug blocks into the firmware. What kind of PC are you testing your CardBus adapter? Is that a 32bit or 16bit? Cheers, -FG Larry --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Saturday 31 January 2009 20:15:22 Francesco Gringoli wrote: On Jan 31, 2009, at 7:54 AM, Larry Finger wrote: Francesco, I changed the dma.c code to WARN_ON rather than BUG_ON and also dump the cookie for the erring case. Of course, the system no longer crashes, nor even stops on the first error. I have no idea how many errors occurred before I got it stopped, but the cookies for the first few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, 0x2050, and 0x2052. When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and obtained: [cut] Larry, many thanks for your help in debugging. However I can't reproduce that error. I tried all this afternoon with a 4306rev3 on a CardBus board but all efforts to freeze the PC were useless. I checked again the difference between r5.0 and r5.1 but it is only 10 lines... so easy to debug that I'm pretty sure that error is not due to changes into header offsets. Is there any way for me to me to freeze the interface when the first error occurs without inducing a kernel panic? I don't understand completely your question: if you need to stop the firmware without having its memory corrupted we can add a semaphore just after the WARN_ON into shm so that next loop after state_machine_start we enter an infinite loop. However this would happen after hundreds cycles. Tell me if we can helping adding debug blocks into the firmware. You can stop the PSM immediately, if you need to, with the MAC_CONTROL. See b43-fwdump, it uses it to get a consistent dump. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add LP 2062 radio init
Michael Buesch pisze:
This adds initialization code for the 2062 radio.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009-01-31
17:19:22.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy_lp.c2009-01-31
19:24:28.0 +0100
@@ -91,7 +91,7 @@ static void lpphy_baseband_rev2plus_init
b43_phy_set(dev, B43_PHY_OFDM(0x10A), 0x1);
b43_phy_maskset(dev, B43_LPPHY_CCKLMSSTEPSIZE, 0xFF01, 0x10);
b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0xFF00, 0xF4);
- b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0x00FF, 0xF100);//FIXME specs
are different
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xDF), 0x00FF, 0xF100);
b43_phy_write(dev, B43_LPPHY_CLIPTHRESH, 0x48);
b43_phy_maskset(dev, B43_LPPHY_HIGAINDB, 0xFF00, 0x46);
b43_phy_maskset(dev, B43_PHY_OFDM(0xE4), 0xFF00, 0x10);
@@ -155,11 +155,114 @@ static void lpphy_baseband_init(struct b
lpphy_baseband_rev0_1_init(dev);
}
-static void lpphy_radio_init(struct b43_wldev *dev)
+struct b2062_freqdata {
+ u16 freq;
+ u8 data[6];
+};
+
+/* Initialize the 2062 radio. */
+static void lpphy_2062_init(struct b43_wldev *dev)
+{
+ u32 crystalfreq, pdiv, tmp, ref;
+ unsigned int i;
+ const struct b2062_freqdata *fd = NULL;
+
+ static const struct b2062_freqdata freqdata_tab[] = {
+ { .freq = 12000, .data[0] = 6, .data[1] = 6, .data[2] = 6,
+ .data[3] = 6, .data[4] = 10, .data[5] = 6, },
+ { .freq = 13000, .data[0] = 4, .data[1] = 4, .data[2] = 4,
+ .data[3] = 4, .data[4] = 11, .data[5] = 7, },
+ { .freq = 14400, .data[0] = 3, .data[1] = 3, .data[2] = 3,
+ .data[3] = 3, .data[4] = 12, .data[5] = 7, },
+ { .freq = 16200, .data[0] = 3, .data[1] = 3, .data[2] = 3,
+ .data[3] = 3, .data[4] = 13, .data[5] = 8, },
+ { .freq = 18000, .data[0] = 2, .data[1] = 2, .data[2] = 2,
+ .data[3] = 2, .data[4] = 14, .data[5] = 8, },
+ { .freq = 19200, .data[0] = 1, .data[1] = 1, .data[2] = 1,
+ .data[3] = 1, .data[4] = 14, .data[5] = 9, },
+ };
+
+ b2062_upload_init_table(dev);
+
+ b43_radio_write(dev, B2062_N_TX_CTL3, 0);
+ b43_radio_write(dev, B2062_N_TX_CTL4, 0);
+ b43_radio_write(dev, B2062_N_TX_CTL5, 0);
+ b43_radio_write(dev, B2062_N_PDN_CTL0, 0x40);
+ b43_radio_write(dev, B2062_N_PDN_CTL0, 0);
+ b43_radio_write(dev, B2062_N_CALIB_TS, 0x10);
+ b43_radio_write(dev, B2062_N_CALIB_TS, 0);
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ)
+ b43_radio_set(dev, B2062_N_TSSI_CTL0, 0x1);
+ else
+ b43_radio_mask(dev, B2062_N_TSSI_CTL0, ~0x1);
+
+ crystalfreq = 0;//FIXME
+
+ if (crystalfreq = 3000) {
+ pdiv = 1;
+ b43_radio_mask(dev, B2062_S_RFPLL_CTL1, 0xFFFB);
+ } else {
+ pdiv = 2;
+ b43_radio_set(dev, B2062_S_RFPLL_CTL1, 0x4);
+ }
+
+ tmp = (8 * pdiv + crystalfreq) / (3200 * pdiv);
+ tmp = (tmp - 1) 0xFF;
+ b43_radio_write(dev, B2062_S_RFPLL_CTL18, tmp);
+
+ tmp = (2 * crystalfreq + 100 * pdiv) / (200 * pdiv);
+ tmp = ((tmp 0xFF) - 1) 0x;
+ b43_radio_write(dev, B2062_S_RFPLL_CTL19, tmp);
+
+ ref = (1000 * pdiv + 2 * crystalfreq) / (2000 * pdiv);
+ ref = 0x;
+ for (i = 0; i ARRAY_SIZE(freqdata_tab); i++) {
+ if (ref freqdata_tab[i].freq) {
+ fd = freqdata_tab[i];
+ break;
+ }
+ }
+ if (B43_WARN_ON(!fd))
+ return;
+
+ b43_radio_write(dev, B2062_S_RFPLL_CTL8,
+ ((u16)(fd-data[1]) 4) | fd-data[0]);
+ b43_radio_write(dev, B2062_S_RFPLL_CTL9,
+ ((u16)(fd-data[3]) 4) | fd-data[2]);//FIXME specs
are different
+ b43_radio_write(dev, B2062_S_RFPLL_CTL10, fd-data[4]);
+ b43_radio_write(dev, B2062_S_RFPLL_CTL11, fd-data[5]);
+}
+
+/* Initialize the 2063 radio. */
+static void lpphy_2063_init(struct b43_wldev *dev)
{
//TODO
}
+static void lpphy_sync_stx(struct b43_wldev *dev)
+{
+ //TODO
+}
+
+static void lpphy_radio_init(struct b43_wldev *dev)
+{
+ /* The radio is attached through the 4wire bus. */
+ b43_phy_set(dev, B43_LPPHY_FOURWIRE_CTL, 0x2);
+ udelay(1);
+ b43_phy_mask(dev, B43_LPPHY_FOURWIRE_CTL, 0xFFFD);
+ udelay(1);
+
+ if (dev-phy.rev 2) {
+ lpphy_2062_init(dev);
+ } else {
+ lpphy_2063_init(dev);
+
Re: opensource firmware now accept version 410 frames
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. What am I missing? Many thanks, Cheers, -FG What looks strange to me is that, if the error is somewhere in the tx_header definition, every transmission will result in an error from the b43_dma_handle_txstatus. If a field is not in the correct position, it is always wrong: it can't be sometimes right and sometimes wrong, don't you agree? I had similar problem beacause of the wrong header offsets definitions, but that made every transmission generate a BUG report... I don't understand how it is possible that almost always things went fine and sometimes report status was not correct... Well, you should probably patch the driver to print the cookie when the WARN_ON happens and reproduce. Please Michael, if you can, can you please check shm.inc header definition? Not yet. Maybe later. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Sunday 01 February 2009 00:47:35 Michael Buesch wrote: On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. The tx-status-queue-full condition most likely is an external condition in the firmware. Don't ask me which one, however. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 12:49 AM, Michael Buesch wrote: On Sunday 01 February 2009 00:47:35 Michael Buesch wrote: On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. The tx-status-queue-full condition most likely is an external condition in the firmware. Don't ask me which one, however. Ok, this could be a problem. Will check next days how to solve. I suppose now that the length of that report_tx_status queue is very device dependent as mine can grow it more than one hundred elements and status continues to be correctly reported. Cheers, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
