b43: ac rev1 captured packets with ampdu

b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Hi Andreas,
i captured some tx/rx packets in transit using ampdu with my vd625
(bcm4360 3x3), some packets with 2 HT streams and some with 1 HT stream
at various bandwith, all 5Ghz, if you want to look at them. They are in
my repo under router-data/vd625-agcombo/{rxtx-1s-h20-40-80,
rxtx-2s-ht20-40-80, rxtx-1s-ht-ampdu}.
I still figuring even-length ssid problems and testing ht modes.
Hope to finish soon to then tackle ampdu fully.

Have a nice day
Alessio

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Hi Andreas,
i captured some tx/rx packets in transit using ampdu with my vd625
(bcm4360 3x3), some packets with 2 HT streams and some with 1 HT stream
at various bandwith, all 5Ghz, if you want to look at them. They are in
my repo under router-data/vd625-agcombo/{rxtx-1s-h20-40-80,
rxtx-2s-ht20-40-80, rxtx-1s-ht-ampdu}.
I still figuring even-length ssid problems and testing ht modes.
Hope to finish soon to then tackle ampdu fully.

Have a nice day
Alessio

AW: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

Thanks for the captures. I’ll look at them when I get to 5 GHz, where my RX is still broken.

Your driver no longer hangs my machine. The hang was my own logging, a 30 ms delay on each of about 80000 table calls. Without it, your head (ce2127a) runs the whole init in about 5 s. The radio doesn’t come up on my chip, though: after the first channel I get radio 2069: power-on timeout (0x040b=0x0001), so the RCAL done bit never sets.

Your blocks (mode_init, set_reg_on_reset, coeff_bank_init, init_regs) let me replace my 290-write PHY replay with a 72-write init. 2.4 GHz now runs at about 20 Mbit/s up and 17 down. Do you know where PHY words 0x1739, 0x016b, 0x0175, 0x03c4 and 0x0197/0x0198 come from? I couldn’t find them in your code.

Thanks, Andreas

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

AW: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

Thanks for the captures. I’ll look at them when I get to 5 GHz, where my RX is still broken.

Your driver no longer hangs my machine. The hang was my own logging, a 30 ms delay on each of about 80000 table calls. Without it, your head (ce2127a) runs the whole init in about 5 s. The radio doesn’t come up on my chip, though: after the first channel I get radio 2069: power-on timeout (0x040b=0x0001), so the RCAL done bit never sets.

Your blocks (mode_init, set_reg_on_reset, coeff_bank_init, init_regs) let me replace my 290-write PHY replay with a 72-write init. 2.4 GHz now runs at about 20 Mbit/s up and 17 down. Do you know where PHY words 0x1739, 0x016b, 0x0175, 0x03c4 and 0x0197/0x0198 come from? I couldn’t find them in your code.

Thanks, Andreas

AW: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all thanks to your code and captures:

1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB here. With it my remaining PHY table replay is gone.
2. Second TX chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is what turns on TX on core 1. I had ported the two PHY writes but not that one: core 1 did not radiate and MCS 8–15 failed completely. The bit survives a module reload, so it only shows after a cold boot.
3. A-MPDU TX works, with the microcode building the aggregates as in your notes. What it needed beyond 0x45c0 and the cache info:
   - the frame's seq_ctrl in the header's sequence field;
   - cache info bytes 0–1 zero when encrypting in software. The stock 50 04 makes the microcode encrypt again: the AP acks the frame and drops it;
   - session frames reported to mac80211 with IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
   - the attempt count of a status (word 2, bits 7:0) divided by its MPDU count;
   - a requeue in the driver for MPDUs the microcode reports unacked. It gives up after a few attempts, and without the requeue TCP collapses.

   Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at legacy rates.

One question: my TX gain sits at index 64 of acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96 collapses the link at 1 m from the AP. Have you seen what a healthy board transmits with on 2.4 GHz, or is there more to the PA/FEM setup than fem2_sub1_setup?

Thanks, Andreas

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

AW: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all thanks to your code and captures:

1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB here. With it my remaining PHY table replay is gone.
2. Second TX chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is what turns on TX on core 1. I had ported the two PHY writes but not that one: core 1 did not radiate and MCS 8–15 failed completely. The bit survives a module reload, so it only shows after a cold boot.
3. A-MPDU TX works, with the microcode building the aggregates as in your notes. What it needed beyond 0x45c0 and the cache info:
   - the frame's seq_ctrl in the header's sequence field;
   - cache info bytes 0–1 zero when encrypting in software. The stock 50 04 makes the microcode encrypt again: the AP acks the frame and drops it;
   - session frames reported to mac80211 with IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
   - the attempt count of a status (word 2, bits 7:0) divided by its MPDU count;
   - a requeue in the driver for MPDUs the microcode reports unacked. It gives up after a few attempts, and without the requeue TCP collapses.

   Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at legacy rates.

One question: my TX gain sits at index 64 of acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96 collapses the link at 1 m from the AP. Have you seen what a healthy board transmits with on 2.4 GHz, or is there more to the PA/FEM setup than fem2_sub1_setup?

Thanks, Andreas

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Sat, 10 Oct 2026 12:59:10 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all
> thanks to your code and captures:
> 
> 1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB
> here. With it my remaining PHY table replay is gone. 2. Second TX
> chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is
> what turns on TX on core 1. I had ported the two PHY writes but not
> that one: core 1 did not radiate and MCS 8–15 failed completely. The
> bit survives a module reload, so it only shows after a cold boot. 3.
> A-MPDU TX works, with the microcode building the aggregates as in
> your notes. What it needed beyond 0x45c0 and the cache info:
>    - the frame's seq_ctrl in the header's sequence field;
>    - cache info bytes 0–1 zero when encrypting in software. The stock
> 50 04 makes the microcode encrypt again: the AP acks the frame and
> drops it;
>    - session frames reported to mac80211 with
> IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
>    - the attempt count of a status (word 2, bits 7:0) divided by its
> MPDU count;
>    - a requeue in the driver for MPDUs the microcode reports unacked.
> It gives up after a few attempts, and without the requeue TCP
> collapses.
> 
>    Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at
> legacy rates.
> 
> One question: my TX gain sits at index 64 of
> acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96
> collapses the link at 1 m from the AP. Have you seen what a healthy
> board transmits with on 2.4 GHz, or is there more to the PA/FEM setup
> than fem2_sub1_setup?
> 
> Thanks, Andreas

Increasing bits density per air time cause transmission power to drop,
as the modulation is more sensitive to distortion. By raising the index
you reduce power, so it works better near the device and much worse
from afar.

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Sat, 10 Oct 2026 12:59:10 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all
> thanks to your code and captures:
> 
> 1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB
> here. With it my remaining PHY table replay is gone. 2. Second TX
> chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is
> what turns on TX on core 1. I had ported the two PHY writes but not
> that one: core 1 did not radiate and MCS 8–15 failed completely. The
> bit survives a module reload, so it only shows after a cold boot. 3.
> A-MPDU TX works, with the microcode building the aggregates as in
> your notes. What it needed beyond 0x45c0 and the cache info:
>    - the frame's seq_ctrl in the header's sequence field;
>    - cache info bytes 0–1 zero when encrypting in software. The stock
> 50 04 makes the microcode encrypt again: the AP acks the frame and
> drops it;
>    - session frames reported to mac80211 with
> IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
>    - the attempt count of a status (word 2, bits 7:0) divided by its
> MPDU count;
>    - a requeue in the driver for MPDUs the microcode reports unacked.
> It gives up after a few attempts, and without the requeue TCP
> collapses.
> 
>    Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at
> legacy rates.
> 
> One question: my TX gain sits at index 64 of
> acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96
> collapses the link at 1 m from the AP. Have you seen what a healthy
> board transmits with on 2.4 GHz, or is there more to the PA/FEM setup
> than fem2_sub1_setup?
> 
> Thanks, Andreas

Increasing bits density per air time cause transmission power to drop,
as the modulation is more sensitive to distortion. By raising the index
you reduce power, so it works better near the device and much worse
from afar.

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

AW: Re: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

On the TX gain: that fits. In the basement (-70 dBm) index 64 carries no HT frame at all, index 20 works, index 0 is worse again. The reset value was just far too quiet. I now use index 20, inside the range the stock power loop ran at here (0x14–0x26), until I have power control.

RX aggregation works too. It only needed accepting the session in ampdu_action; the microcode deaggregates and sends the block acks. Both directions aggregated: about 30 Mbit/s up and 20 down at -70 dBm, against 13 and 10 at legacy rates.

On the RCAL timeout: that run was your unmodified head without my logging, so no added delays. I can rerun it and send the full dmesg.

On the PHY words: yes, these are writes of the hybrid 6.30.223 wl on the MacBookAir6,1, from my MMIO trace at 2.4 GHz: 0x1739 = 0, 0x016b = 0, 0x0175 = 0, 0x03c4 = 0x0668, and in channel setup 0x0197 = 0x0014, 0x0198 = 0x0010. Bluetooth is plausible, the board has BTCOEXIST set.

Thanks, Andreas

AW: Re: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

On the TX gain: that fits. In the basement (-70 dBm) index 64 carries no HT frame at all, index 20 works, index 0 is worse again. The reset value was just far too quiet. I now use index 20, inside the range the stock power loop ran at here (0x14–0x26), until I have power control.

RX aggregation works too. It only needed accepting the session in ampdu_action; the microcode deaggregates and sends the block acks. Both directions aggregated: about 30 Mbit/s up and 20 down at -70 dBm, against 13 and 10 at legacy rates.

On the RCAL timeout: that run was your unmodified head without my logging, so no added delays. I can rerun it and send the full dmesg.

On the PHY words: yes, these are writes of the hybrid 6.30.223 wl on the MacBookAir6,1, from my MMIO trace at 2.4 GHz: 0x1739 = 0, 0x016b = 0, 0x0175 = 0, 0x03c4 = 0x0668, and in channel setup 0x0197 = 0x0014, 0x0198 = 0x0010. Bluetooth is plausible, the board has BTCOEXIST set.

Thanks, Andreas

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Sat, 10 Oct 2026 14:15:51 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> On the TX gain: that fits. In the basement (-70 dBm) index 64 carries
> no HT frame at all, index 20 works, index 0 is worse again. The reset
> value was just far too quiet. I now use index 20, inside the range
> the stock power loop ran at here (0x14–0x26), until I have power
> control.
> 
> RX aggregation works too. It only needed accepting the session in
> ampdu_action; the microcode deaggregates and sends the block acks.
> Both directions aggregated: about 30 Mbit/s up and 20 down at -70
> dBm, against 13 and 10 at legacy rates.
> 
> On the RCAL timeout: that run was your unmodified head without my
> logging, so no added delays. I can rerun it and send the full dmesg.
> 
> On the PHY words: yes, these are writes of the hybrid 6.30.223 wl on
> the MacBookAir6,1, from my MMIO trace at 2.4 GHz: 0x1739 = 0, 0x016b
> = 0, 0x0175 = 0, 0x03c4 = 0x0668, and in channel setup 0x0197 =
> 0x0014, 0x0198 = 0x0010. Bluetooth is plausible, the board has
> BTCOEXIST set.
> 
> Thanks, Andreas

Hi Andreas,

I managed to get HT20/HT40 working, i also fixed two bugs that may have
been the cause for the failure of my driver in your hardware: 
- first i had wrongly gated an operation over "only once per boot"
  while in fact it was necessary on any restart, even in hot restarts.
  I never catched it on unit testing. 
- second i was using 9xx ucode layout for initvals, so both my 7xx and
  your 8xx ucode were using invalid values. My just happen to work with
  no-ht mode, but it was pure luck. Once i fixed it and stopped
  polluting a beacon bit it the transmission work fine with 10 mbits up
  and down.

I also added some bits to test BT coexistence.

Next i'll tackle VHT20/VHT40/VHT80 and then ampdu.

I am really excited that the work is finally coming together and i
really want to hope that broadcom ac rev1 generation will be the best
supported by b43.

Alessio

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Sat, 10 Oct 2026 14:15:51 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> On the TX gain: that fits. In the basement (-70 dBm) index 64 carries
> no HT frame at all, index 20 works, index 0 is worse again. The reset
> value was just far too quiet. I now use index 20, inside the range
> the stock power loop ran at here (0x14–0x26), until I have power
> control.
> 
> RX aggregation works too. It only needed accepting the session in
> ampdu_action; the microcode deaggregates and sends the block acks.
> Both directions aggregated: about 30 Mbit/s up and 20 down at -70
> dBm, against 13 and 10 at legacy rates.
> 
> On the RCAL timeout: that run was your unmodified head without my
> logging, so no added delays. I can rerun it and send the full dmesg.
> 
> On the PHY words: yes, these are writes of the hybrid 6.30.223 wl on
> the MacBookAir6,1, from my MMIO trace at 2.4 GHz: 0x1739 = 0, 0x016b
> = 0, 0x0175 = 0, 0x03c4 = 0x0668, and in channel setup 0x0197 =
> 0x0014, 0x0198 = 0x0010. Bluetooth is plausible, the board has
> BTCOEXIST set.
> 
> Thanks, Andreas

Hi Andreas,

I managed to get HT20/HT40 working, i also fixed two bugs that may have
been the cause for the failure of my driver in your hardware: 
- first i had wrongly gated an operation over "only once per boot"
  while in fact it was necessary on any restart, even in hot restarts.
  I never catched it on unit testing. 
- second i was using 9xx ucode layout for initvals, so both my 7xx and
  your 8xx ucode were using invalid values. My just happen to work with
  no-ht mode, but it was pure luck. Once i fixed it and stopped
  polluting a beacon bit it the transmission work fine with 10 mbits up
  and down.

I also added some bits to test BT coexistence.

Next i'll tackle VHT20/VHT40/VHT80 and then ampdu.

I am really excited that the work is finally coming together and i
really want to hope that broadcom ac rev1 generation will be the best
supported by b43.

Alessio

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Fri, 09 Oct 2026 23:16:40 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the captures. I’ll look at them when I get to 5 GHz, where
> my RX is still broken.
> 
> Your driver no longer hangs my machine. The hang was my own logging,
> a 30 ms delay on each of about 80000 table calls. Without it, your
> head (ce2127a) runs the whole init in about 5 s. The radio doesn’t
> come up on my chip, though: after the first channel I get radio 2069:
> power-on timeout (0x040b=0x0001), so the RCAL done bit never sets.
> 

Maybe you have still too many delays around power on?

> Your blocks (mode_init, set_reg_on_reset, coeff_bank_init, init_regs)
> let me replace my 290-write PHY replay with a 72-write init. 2.4 GHz
> now runs at about 20 Mbit/s up and 17 down. Do you know where PHY
> words 0x1739, 0x016b, 0x0175, 0x03c4 and 0x0197/0x0198 come from? I
> couldn’t find them in your code.
> 
> Thanks, Andreas

Do you mean that in version 6.30.x, the driver write 0x1739, 0x016b, 0x0175, 
0x03c4 and 0x0197/0x0198? Maybe they are related to bluetooth? Don't
know, will investigate it.

Thank you for your reporting!
Alessio

_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev

Re: b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Fri, 09 Oct 2026 23:16:40 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the captures. I’ll look at them when I get to 5 GHz, where
> my RX is still broken.
> 
> Your driver no longer hangs my machine. The hang was my own logging,
> a 30 ms delay on each of about 80000 table calls. Without it, your
> head (ce2127a) runs the whole init in about 5 s. The radio doesn’t
> come up on my chip, though: after the first channel I get radio 2069:
> power-on timeout (0x040b=0x0001), so the RCAL done bit never sets.
> 

Maybe you have still too many delays around power on?

> Your blocks (mode_init, set_reg_on_reset, coeff_bank_init, init_regs)
> let me replace my 290-write PHY replay with a 72-write init. 2.4 GHz
> now runs at about 20 Mbit/s up and 17 down. Do you know where PHY
> words 0x1739, 0x016b, 0x0175, 0x03c4 and 0x0197/0x0198 come from? I
> couldn’t find them in your code.
> 
> Thanks, Andreas

Do you mean that in version 6.30.x, the driver write 0x1739, 0x016b, 0x0175, 
0x03c4 and 0x0197/0x0198? Maybe they are related to bluetooth? Don't
know, will investigate it.

Thank you for your reporting!
Alessio