Malformed RX header on new (rev 6xx) firmware

Malformed RX header on new (rev 6xx) firmware

[Rafał Miłecki]

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?

Malformed RX header on new (rev 6xx) firmware

[Rafał Miłecki]

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?

Malformed RX header on new (rev 6xx) firmware

[Rafał Miłecki]

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?

Malformed RX header on new (rev 6xx) firmware

[Michael Büsch]

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.