* Malformed RX header on new (rev 6xx) firmware
@ 2011-07-24 20:56 Rafał Miłecki
2011-07-25 9:21 ` Rafał Miłecki
2011-07-25 10:00 ` Rafał Miłecki
0 siblings, 2 replies; 4+ messages in thread
From: Rafał Miłecki @ 2011-07-24 20:56 UTC (permalink / raw)
To: b43-dev
I'm trying to add support for 6xx firmware (like 644.1001). I've
slightly updated TX header (4 more unused u16 fields) and I got rid of
TX transmission errors thanks to that.
Unfortunately every RX header I receive seems to be malformed
(stipped?) and b43 drops packets.
With 508.1103:
[38518.414658] frame_len: 0x008F
[38518.414662] phy_status0: 0x2000
[38518.414664] phy_status2: 0x003D
[38518.414666] phy_status3: 0x0000
[38518.414668] mac_status: 0x01060000
[38518.414670] mac_time: 0x58CC
[3851328.414673] channel: 0x0024 [phy:4; chanid:4]
[38518.415901] frame_len: 0x0089
[38518.415903] phy_status0: 0x2000
[38518.415905] phy_status2: 0x0033
[38518.415907] phy_status3: 0x0000
[38518.415909] mac_status: 0x01060002
[38518.415911] mac_time: 0x5DE8
[38518.415914] channel: 0x0024 [phy:4; chanid:4]
[38518.417940] frame_len: 0x0089
[38518.417943] phy_status0: 0x2000
[38518.417945] phy_status2: 0x0037
[38518.417947] phy_status3: 0x0000
[38518.417949] mac_status: 0x01060002
[38518.417951] mac_time: 0x65DF
[38518.417954] channel: 0x0024 [phy:4; chanid:4]
With 644.1001:
[38421.950019] frame_len: 0x008F
[38421.950024] phy_status0: 0x2000
[38421.950026] phy_status2: 0x002C
[38421.950028] phy_status3: 0x0000
[38421.950030] mac_status: 0x00000000
[38421.950032] mac_time: 0x0000
[38421.950035] channel: 0x0106 [phy:6; chanid:32]
[38421.955783] frame_len: 0x0089
[38421.955787] phy_status0: 0x2000
[38421.955789] phy_status2: 0x003A
[38421.955792] phy_status3: 0x0000
[38421.955794] mac_status: 0x00000000
[38421.955796] mac_time: 0x0002
[38421.955800] channel: 0x0106 [phy:6; chanid:32]
So when using 604.1001 firmware I don't get mac_status, mac_time is
sth random, and chanstat is always 0x106.
Interesting is that RX data seem to be usable (didn't check if 100%
valid). If I comment out dropping package, I get scanning results.
Do you have idea what can be causing it?
1) I've tried changing B43_DMA0_RX_FRAMEOFFSET to 38 (to match wl) but
this didn't help.
+#define B43_DMA0_RX_FRAMEOFFSET 38
2) Dumping RXSTATUS and RXERRRO doesn't show anything interesting, the
result is the same for older and newer firmware
pr_info("RXSTATUS: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXSTATUS));
pr_info("RXERROR: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXERROR));
3) In the TX header we have two differences:
a) Cookie is quite different, but I'm not sure if it's processed by
ucode at all. I think it's just copied by firmware when giving us
feedback about TX we submitted to the hardware.
b) Field mac_ctl differs. We (b43) set B43_TXH_MAC_HWSEQ |
B43_TXH_MAC_STMSDU | B43_TXH_MAC_LONGFRAME. brcm80211 sets
B43_TXH_MAC_STMSDU
4) dwmw2 noticed that wl (in ndiswrapper) does use full address
instead of index for "Descriptor Stop". According to brcm80211
comments it's for allowing sending unaligned packets to the hardware.
--
Rafa?
^ permalink raw reply [flat|nested] 4+ messages in thread* Malformed RX header on new (rev 6xx) firmware
2011-07-24 20:56 Malformed RX header on new (rev 6xx) firmware Rafał Miłecki
@ 2011-07-25 9:21 ` Rafał Miłecki
2011-07-25 10:00 ` Rafał Miłecki
1 sibling, 0 replies; 4+ messages in thread
From: Rafał Miłecki @ 2011-07-25 9:21 UTC (permalink / raw)
To: b43-dev
W dniu 24 lipca 2011 22:56 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> I'm trying to add support for 6xx firmware (like 644.1001). I've
> slightly updated TX header (4 more unused u16 fields) and I got rid of
> TX transmission errors thanks to that.
>
> Unfortunately every RX header I receive seems to be malformed
> (stipped?) and b43 drops packets.
>
> With 508.1103:
> [38518.414658] frame_len: 0x008F
> [38518.414662] phy_status0: 0x2000
> [38518.414664] phy_status2: 0x003D
> [38518.414666] phy_status3: 0x0000
> [38518.414668] mac_status: 0x01060000
> [38518.414670] mac_time: 0x58CC
> [3851328.414673] channel: 0x0024 [phy:4; chanid:4]
>
> [38518.415901] frame_len: 0x0089
> [38518.415903] phy_status0: 0x2000
> [38518.415905] phy_status2: 0x0033
> [38518.415907] phy_status3: 0x0000
> [38518.415909] mac_status: 0x01060002
> [38518.415911] mac_time: 0x5DE8
> [38518.415914] channel: 0x0024 [phy:4; chanid:4]
>
> [38518.417940] frame_len: 0x0089
> [38518.417943] phy_status0: 0x2000
> [38518.417945] phy_status2: 0x0037
> [38518.417947] phy_status3: 0x0000
> [38518.417949] mac_status: 0x01060002
> [38518.417951] mac_time: 0x65DF
> [38518.417954] channel: 0x0024 [phy:4; chanid:4]
>
> With 644.1001:
> [38421.950019] frame_len: 0x008F
> [38421.950024] phy_status0: 0x2000
> [38421.950026] phy_status2: 0x002C
> [38421.950028] phy_status3: 0x0000
> [38421.950030] mac_status: 0x00000000
> [38421.950032] mac_time: 0x0000
> [38421.950035] channel: 0x0106 [phy:6; chanid:32]
>
> [38421.955783] frame_len: 0x0089
> [38421.955787] phy_status0: 0x2000
> [38421.955789] phy_status2: 0x003A
> [38421.955792] phy_status3: 0x0000
> [38421.955794] mac_status: 0x00000000
> [38421.955796] mac_time: 0x0002
> [38421.955800] channel: 0x0106 [phy:6; chanid:32]
>
> So when using 604.1001 firmware I don't get mac_status, mac_time is
> sth random, and chanstat is always 0x106.
I decided to dump 4 more bytes. At the end of struct b43_rxhdr_fw4 I've added:
__le16 hack1;
__le16 hack2;
[ 953.587835] frame_len: 0x008F
[ 953.587837] phy_status0: 0x2000
[ 953.587839] phy_status2: 0x0028
[ 953.587841] phy_status3: 0x0000
[ 953.587843] mac_status: 0x00000000
[ 953.587845] mac_time: 0x0000
[ 953.587847] channel: 0x0106
[ 953.587849] hack1: 0x8C88
[ 953.587850] hack2: 0x0024
My hack2 looks like the real "channel" field.
0x0024 & B43_RX_CHAN_PHYTYPE ? PHY type 4
0x0024 & B43_RX_CHAN_ID >> 3 ? Channel id 4
To make sure, I've set up new AP on channel 6 and performed scanning.
[ 1479.679678] frame_len: 0x00CF
[ 1479.679680] phy_status0: 0x2004
[ 1479.679682] phy_status2: 0x0045
[ 1479.679684] phy_status3: 0x0000
[ 1479.679686] mac_status: 0x00000000
[ 1479.679688] mac_time: 0x0002
[ 1479.679690] channel: 0x0106
[ 1479.679691] hack1: 0xDD3E
[ 1479.679693] hack2: 0x0034
[ 1479.682615] frame_len: 0x00D5
[ 1479.682617] phy_status0: 0x2004
[ 1479.682619] phy_status2: 0x003F
[ 1479.682621] phy_status3: 0x0000
[ 1479.682623] mac_status: 0x00000000
[ 1479.682625] mac_time: 0x0000
[ 1479.682627] channel: 0x0106
[ 1479.682629] hack1: 0xE892
[ 1479.682631] hack2: 0x0034
Field hack2 looks sane again
0x0034 & B43_RX_CHAN_PHYTYPE ? PHY type 4
0x0034 & B43_RX_CHAN_ID >> 3 ? Channel id 6
--
Rafa?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Malformed RX header on new (rev 6xx) firmware
2011-07-24 20:56 Malformed RX header on new (rev 6xx) firmware Rafał Miłecki
2011-07-25 9:21 ` Rafał Miłecki
@ 2011-07-25 10:00 ` Rafał Miłecki
2011-07-25 15:07 ` Michael Büsch
1 sibling, 1 reply; 4+ messages in thread
From: Rafał Miłecki @ 2011-07-25 10:00 UTC (permalink / raw)
To: b43-dev
W dniu 24 lipca 2011 22:56 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> I'm trying to add support for 6xx firmware (like 644.1001). I've
> slightly updated TX header (4 more unused u16 fields) and I got rid of
> TX transmission errors thanks to that.
>
> Unfortunately every RX header I receive seems to be malformed
> (stipped?) and b43 drops packets.
>
> With 508.1103:
> [38518.414658] frame_len: 0x008F
> [38518.414662] phy_status0: 0x2000
> [38518.414664] phy_status2: 0x003D
> [38518.414666] phy_status3: 0x0000
> [38518.414668] mac_status: 0x01060000
> [38518.414670] mac_time: 0x58CC
> [3851328.414673] channel: 0x0024 [phy:4; chanid:4]
>
> [38518.415901] frame_len: 0x0089
> [38518.415903] phy_status0: 0x2000
> [38518.415905] phy_status2: 0x0033
> [38518.415907] phy_status3: 0x0000
> [38518.415909] mac_status: 0x01060002
> [38518.415911] mac_time: 0x5DE8
> [38518.415914] channel: 0x0024 [phy:4; chanid:4]
>
> [38518.417940] frame_len: 0x0089
> [38518.417943] phy_status0: 0x2000
> [38518.417945] phy_status2: 0x0037
> [38518.417947] phy_status3: 0x0000
> [38518.417949] mac_status: 0x01060002
> [38518.417951] mac_time: 0x65DF
> [38518.417954] channel: 0x0024 [phy:4; chanid:4]
>
> With 644.1001:
> [38421.950019] frame_len: 0x008F
> [38421.950024] phy_status0: 0x2000
> [38421.950026] phy_status2: 0x002C
> [38421.950028] phy_status3: 0x0000
> [38421.950030] mac_status: 0x00000000
> [38421.950032] mac_time: 0x0000
> [38421.950035] channel: 0x0106 [phy:6; chanid:32]
>
> [38421.955783] frame_len: 0x0089
> [38421.955787] phy_status0: 0x2000
> [38421.955789] phy_status2: 0x003A
> [38421.955792] phy_status3: 0x0000
> [38421.955794] mac_status: 0x00000000
> [38421.955796] mac_time: 0x0002
> [38421.955800] channel: 0x0106 [phy:6; chanid:32]
>
> So when using 604.1001 firmware I don't get mac_status, mac_time is
> sth random, and chanstat is always 0x106.
>
> Interesting is that RX data seem to be usable (didn't check if 100%
> valid). If I comment out dropping package, I get scanning results.
>
> Do you have idea what can be causing it?
>
> 1) I've tried changing B43_DMA0_RX_FRAMEOFFSET to 38 (to match wl) but
> this didn't help.
> +#define B43_DMA0_RX_FRAMEOFFSET ? ? ? ? ? ? ? ?38
>
> 2) Dumping RXSTATUS and RXERRRO doesn't show anything interesting, the
> result is the same for older and newer firmware
> pr_info("RXSTATUS: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXSTATUS));
> pr_info("RXERROR: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXERROR));
>
> 3) In the TX header we have two differences:
> a) Cookie is quite different, but I'm not sure if it's processed by
> ucode at all. I think it's just copied by firmware when giving us
> feedback about TX we submitted to the hardware.
> b) Field mac_ctl differs. We (b43) set B43_TXH_MAC_HWSEQ |
> B43_TXH_MAC_STMSDU | B43_TXH_MAC_LONGFRAME. brcm80211 sets
> B43_TXH_MAC_STMSDU
>
> 4) dwmw2 noticed that wl (in ndiswrapper) does use full address
> instead of index for "Descriptor Stop". According to brcm80211
> comments it's for allowing sending unaligned packets to the hardware.
>
> --
> Rafa?
>
How it happened, I didn't notice relation between:
> mac_status: 0x01060000
and:
> mac_time: 0x0000
> channel: 0x0106
Now that's obvious, 4 more bytes between phy_status3 and mac_status :)
The ugly part is that Broadcom changes that at some random firmware
updates. For example: take a look at brcm80211. It uses 610 firmware.
brcm80211 uses new TX header, but old rx header. Well, few more "if"s
to implement.
--
Rafa?
^ permalink raw reply [flat|nested] 4+ messages in thread* Malformed RX header on new (rev 6xx) firmware
2011-07-25 10:00 ` Rafał Miłecki
@ 2011-07-25 15:07 ` Michael Büsch
0 siblings, 0 replies; 4+ messages in thread
From: Michael Büsch @ 2011-07-25 15:07 UTC (permalink / raw)
To: b43-dev
On Mon, 25 Jul 2011 12:00:35 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> W dniu 24 lipca 2011 22:56 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> > I'm trying to add support for 6xx firmware (like 644.1001). I've
> > slightly updated TX header (4 more unused u16 fields) and I got rid of
> > TX transmission errors thanks to that.
> >
> > Unfortunately every RX header I receive seems to be malformed
> > (stipped?) and b43 drops packets.
> >
> > With 508.1103:
> > [38518.414658] frame_len: 0x008F
> > [38518.414662] phy_status0: 0x2000
> > [38518.414664] phy_status2: 0x003D
> > [38518.414666] phy_status3: 0x0000
> > [38518.414668] mac_status: 0x01060000
> > [38518.414670] mac_time: 0x58CC
> > [3851328.414673] channel: 0x0024 [phy:4; chanid:4]
> >
> > [38518.415901] frame_len: 0x0089
> > [38518.415903] phy_status0: 0x2000
> > [38518.415905] phy_status2: 0x0033
> > [38518.415907] phy_status3: 0x0000
> > [38518.415909] mac_status: 0x01060002
> > [38518.415911] mac_time: 0x5DE8
> > [38518.415914] channel: 0x0024 [phy:4; chanid:4]
> >
> > [38518.417940] frame_len: 0x0089
> > [38518.417943] phy_status0: 0x2000
> > [38518.417945] phy_status2: 0x0037
> > [38518.417947] phy_status3: 0x0000
> > [38518.417949] mac_status: 0x01060002
> > [38518.417951] mac_time: 0x65DF
> > [38518.417954] channel: 0x0024 [phy:4; chanid:4]
> >
> > With 644.1001:
> > [38421.950019] frame_len: 0x008F
> > [38421.950024] phy_status0: 0x2000
> > [38421.950026] phy_status2: 0x002C
> > [38421.950028] phy_status3: 0x0000
> > [38421.950030] mac_status: 0x00000000
> > [38421.950032] mac_time: 0x0000
> > [38421.950035] channel: 0x0106 [phy:6; chanid:32]
> >
> > [38421.955783] frame_len: 0x0089
> > [38421.955787] phy_status0: 0x2000
> > [38421.955789] phy_status2: 0x003A
> > [38421.955792] phy_status3: 0x0000
> > [38421.955794] mac_status: 0x00000000
> > [38421.955796] mac_time: 0x0002
> > [38421.955800] channel: 0x0106 [phy:6; chanid:32]
> >
> > So when using 604.1001 firmware I don't get mac_status, mac_time is
> > sth random, and chanstat is always 0x106.
> >
> > Interesting is that RX data seem to be usable (didn't check if 100%
> > valid). If I comment out dropping package, I get scanning results.
> >
> > Do you have idea what can be causing it?
> >
> > 1) I've tried changing B43_DMA0_RX_FRAMEOFFSET to 38 (to match wl) but
> > this didn't help.
> > +#define B43_DMA0_RX_FRAMEOFFSET ? ? ? ? ? ? ? ?38
> >
> > 2) Dumping RXSTATUS and RXERRRO doesn't show anything interesting, the
> > result is the same for older and newer firmware
> > pr_info("RXSTATUS: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXSTATUS));
> > pr_info("RXERROR: 0x%X\n", b43_dma_read(ring, B43_DMA64_RXERROR));
> >
> > 3) In the TX header we have two differences:
> > a) Cookie is quite different, but I'm not sure if it's processed by
> > ucode at all. I think it's just copied by firmware when giving us
> > feedback about TX we submitted to the hardware.
> > b) Field mac_ctl differs. We (b43) set B43_TXH_MAC_HWSEQ |
> > B43_TXH_MAC_STMSDU | B43_TXH_MAC_LONGFRAME. brcm80211 sets
> > B43_TXH_MAC_STMSDU
> >
> > 4) dwmw2 noticed that wl (in ndiswrapper) does use full address
> > instead of index for "Descriptor Stop". According to brcm80211
> > comments it's for allowing sending unaligned packets to the hardware.
> >
> > --
> > Rafa?
> >
>
> How it happened, I didn't notice relation between:
> > mac_status: 0x01060000
> and:
> > mac_time: 0x0000
> > channel: 0x0106
>
> Now that's obvious, 4 more bytes between phy_status3 and mac_status :)
>
> The ugly part is that Broadcom changes that at some random firmware
> updates. For example: take a look at brcm80211. It uses 610 firmware.
> brcm80211 uses new TX header, but old rx header. Well, few more "if"s
> to implement.
There's still the option to remove support for deprecated firmware ABIs.
The deadline has long passed, so you may drop em immediately, if it's
too much of a headache.
Documentation/feature-removal-schedule.txt:
What: b43 support for firmware revision < 410
When: The schedule was July 2008, but it was decided that we are going to keep the
code as long as there are no major maintanance headaches.
So it _could_ be removed _any_ time now, if it conflicts with something new.
Why: The support code for the old firmware hurts code readability/maintainability
and slightly hurts runtime performance. Bugfixes for the old firmware
are not provided by Broadcom anymore.
Who: Michael Buesch <mb@bu3sch.de>
--
Greetings, Michael.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-07-25 15:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-24 20:56 Malformed RX header on new (rev 6xx) firmware Rafał Miłecki
2011-07-25 9:21 ` Rafał Miłecki
2011-07-25 10:00 ` Rafał Miłecki
2011-07-25 15:07 ` Michael Büsch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).