AW: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

AW: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi,
I've been working on adding 802.11ac AC-PHY support to b43 for the BCM4360 (MacBookAir6,1), since b43's existing phy_ac.c has only ever been a skeleton (allocate/free plumbing, no real init or tuning) and Broadcom's own wl driver is the only thing that's ever actually worked on this chip.

I want to be upfront about how I got there, since it directly affects what (if anything) is submittable: I reverse-engineered wl.ko — decompiling it and capturing its live register/SHM writes on real hardware — and used that to write a working driver. That driver is not clean-room and I'm not proposing to submit it as-is; having the proprietary driver's decompiled logic in view while writing it is a real provenance problem, not just a style one.

What I am hoping is more useful: I've since written up a functional specification — chip bring-up, channel tuning, TX/RX header formats, and the specific pitfalls that cost real debugging time (a frame-lifetime register that silently stalls connections if left unset, an RX status bit that looks like "decrypt error" but fires on unencrypted frames too) — describing the hardware's required behavior in my own words, with the intent that someone who's never seen wl.ko or my driver could implement a working driver from just that document and the 802.11 spec. It's honest about what it doesn't include (the actual calibration/tuning table numbers, firmware, b43's existing generic infrastructure) and upfront that I'm not qualified to judge its legal soundness alone.

The driver itself works: verified WPA2 association, DHCP, and sustained stable traffic on 2.4 GHz, on both the kernel this project started on and, as of today, kernel 7.2.7 with no code changes needed. 5 GHz, hardware crypto, and full RF calibration are out of scope so far.
Given b43 is listed Orphan, I don't have a specific person to ask, so: has this kind of provenance situation — a reverse-engineered spec intended to enable an independent clean-room implementation — come up before for a wireless driver here? Is that a viable path at all, and if so, what would you want to see before it's worth anyone's time to attempt the clean-room side?

Thanks for reading this far.

Andreas

AW: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi,
I've been working on adding 802.11ac AC-PHY support to b43 for the BCM4360 (MacBookAir6,1), since b43's existing phy_ac.c has only ever been a skeleton (allocate/free plumbing, no real init or tuning) and Broadcom's own wl driver is the only thing that's ever actually worked on this chip.

I want to be upfront about how I got there, since it directly affects what (if anything) is submittable: I reverse-engineered wl.ko — decompiling it and capturing its live register/SHM writes on real hardware — and used that to write a working driver. That driver is not clean-room and I'm not proposing to submit it as-is; having the proprietary driver's decompiled logic in view while writing it is a real provenance problem, not just a style one.

What I am hoping is more useful: I've since written up a functional specification — chip bring-up, channel tuning, TX/RX header formats, and the specific pitfalls that cost real debugging time (a frame-lifetime register that silently stalls connections if left unset, an RX status bit that looks like "decrypt error" but fires on unencrypted frames too) — describing the hardware's required behavior in my own words, with the intent that someone who's never seen wl.ko or my driver could implement a working driver from just that document and the 802.11 spec. It's honest about what it doesn't include (the actual calibration/tuning table numbers, firmware, b43's existing generic infrastructure) and upfront that I'm not qualified to judge its legal soundness alone.

The driver itself works: verified WPA2 association, DHCP, and sustained stable traffic on 2.4 GHz, on both the kernel this project started on and, as of today, kernel 7.2.7 with no code changes needed. 5 GHz, hardware crypto, and full RF calibration are out of scope so far.
Given b43 is listed Orphan, I don't have a specific person to ask, so: has this kind of provenance situation — a reverse-engineered spec intended to enable an independent clean-room implementation — come up before for a wireless driver here? Is that a viable path at all, and if so, what would you want to see before it's worth anyone's time to attempt the clean-room side?

Thanks for reading this far.

Andreas

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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

Hi Andreas,

I'm the former maintainer of b43, so I think I can give at least a few hints.

The driver has largely been developed with a clean-room approach and with
a register-dump-then-implement approach. There were no lawyers involved.
Only common sense.
So I think if you use one of these approaches, you are fine.

It's also fine in my opinion to use AI assistance up to a point.
What I think is very risky is to use AI for the whole process. I think there
must be a human involved to review the specification for copyrighted material.
But also for quality control.

If the whole thing is based solely on register dumping, my personal lay opinion
is that there cannot be much copyrighted material in there.

So, yeah. Feel free to post both your specification and your implementation if you like.
Please also fully disclose how the intermediate steps were developed and
what role AI assistance played.
Then we can decide how to continue.

I hope that not too many changes to the existing common parts and other PHYs are
needed, to keep the regression risk low.

-- 
Michael Büsch
https://bues.ch/

On Mon, 28 Sep 2026 13:42:42 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> I've been working on adding 802.11ac AC-PHY support to b43 for the BCM4360 (MacBookAir6,1), since b43's existing phy_ac.c has only ever been a skeleton (allocate/free
> plumbing, no real init or tuning) and Broadcom's own wl driver is the only thing that's ever actually worked on this chip.
> 
> I want to be upfront about how I got there, since it directly affects what (if anything) is submittable: I reverse-engineered wl.ko — decompiling it and capturing its
> live register/SHM writes on real hardware — and used that to write a working driver. That driver is not clean-room and I'm not proposing to submit it as-is; having the
> proprietary driver's decompiled logic in view while writing it is a real provenance problem, not just a style one.
> 
> What I am hoping is more useful: I've since written up a functional specification — chip bring-up, channel tuning, TX/RX header formats, and the specific pitfalls that
> cost real debugging time (a frame-lifetime register that silently stalls connections if left unset, an RX status bit that looks like "decrypt error" but fires on
> unencrypted frames too) — describing the hardware's required behavior in my own words, with the intent that someone who's never seen wl.ko or my driver could implement a
> working driver from just that document and the 802.11 spec. It's honest about what it doesn't include (the actual calibration/tuning table numbers, firmware, b43's
> existing generic infrastructure) and upfront that I'm not qualified to judge its legal soundness alone.
> 
> The driver itself works: verified WPA2 association, DHCP, and sustained stable traffic on 2.4 GHz, on both the kernel this project started on and, as of today, kernel
> 7.2.7 with no code changes needed. 5 GHz, hardware crypto, and full RF calibration are out of scope so far. Given b43 is listed Orphan, I don't have a specific person to
> ask, so: has this kind of provenance situation — a reverse-engineered spec intended to enable an independent clean-room implementation — come up before for a wireless
> driver here? Is that a viable path at all, and if so, what would you want to see before it's worth anyone's time to attempt the clean-room side?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Michael Büsch]

[-- Attachment #1.1: Type: text/plain, Size: 3454 bytes --]

Hi Andreas,

I'm the former maintainer of b43, so I think I can give at least a few hints.

The driver has largely been developed with a clean-room approach and with
a register-dump-then-implement approach. There were no lawyers involved.
Only common sense.
So I think if you use one of these approaches, you are fine.

It's also fine in my opinion to use AI assistance up to a point.
What I think is very risky is to use AI for the whole process. I think there
must be a human involved to review the specification for copyrighted material.
But also for quality control.

If the whole thing is based solely on register dumping, my personal lay opinion
is that there cannot be much copyrighted material in there.

So, yeah. Feel free to post both your specification and your implementation if you like.
Please also fully disclose how the intermediate steps were developed and
what role AI assistance played.
Then we can decide how to continue.

I hope that not too many changes to the existing common parts and other PHYs are
needed, to keep the regression risk low.

-- 
Michael Büsch
https://bues.ch/

On Mon, 28 Sep 2026 13:42:42 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> I've been working on adding 802.11ac AC-PHY support to b43 for the BCM4360 (MacBookAir6,1), since b43's existing phy_ac.c has only ever been a skeleton (allocate/free
> plumbing, no real init or tuning) and Broadcom's own wl driver is the only thing that's ever actually worked on this chip.
> 
> I want to be upfront about how I got there, since it directly affects what (if anything) is submittable: I reverse-engineered wl.ko — decompiling it and capturing its
> live register/SHM writes on real hardware — and used that to write a working driver. That driver is not clean-room and I'm not proposing to submit it as-is; having the
> proprietary driver's decompiled logic in view while writing it is a real provenance problem, not just a style one.
> 
> What I am hoping is more useful: I've since written up a functional specification — chip bring-up, channel tuning, TX/RX header formats, and the specific pitfalls that
> cost real debugging time (a frame-lifetime register that silently stalls connections if left unset, an RX status bit that looks like "decrypt error" but fires on
> unencrypted frames too) — describing the hardware's required behavior in my own words, with the intent that someone who's never seen wl.ko or my driver could implement a
> working driver from just that document and the 802.11 spec. It's honest about what it doesn't include (the actual calibration/tuning table numbers, firmware, b43's
> existing generic infrastructure) and upfront that I'm not qualified to judge its legal soundness alone.
> 
> The driver itself works: verified WPA2 association, DHCP, and sustained stable traffic on 2.4 GHz, on both the kernel this project started on and, as of today, kernel
> 7.2.7 with no code changes needed. 5 GHz, hardware crypto, and full RF calibration are out of scope so far. Given b43 is listed Orphan, I don't have a specific person to
> ask, so: has this kind of provenance situation — a reverse-engineered spec intended to enable an independent clean-room implementation — come up before for a wireless
> driver here? Is that a viable path at all, and if so, what would you want to see before it's worth anyone's time to attempt the clean-room side?


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi Michael,

> So I think if you use one of these approaches, you are fine.

Definitely not. :o Apart from register dumps Ghidra was used to decompile and analyze the original driver and all steps were heavily AI assisted. Also, the driver is still kind of rough.

> I think there
> must be a human involved to review the specification for copyrighted material.
> But also for quality control.

I can have a look at every piece I give out.

> So, yeah. Feel free to post both your specification and your implementation if you like.
> Please also fully disclose how the intermediate steps were developed and
> what role AI assistance played.
> Then we can decide how to continue.

I'm keeping the repo private for now, I'm happy to review the spec or give it out piecewise, just to be safe, if someone is interested in implementing it.

> I hope that not too many changes to the existing common parts and other PHYs are
> needed, to keep the regression risk low.

It's about 11.000 lines but I think the common parts weren't changed too much.

I`m looking forward to hearing your opinion.

Best regards,
Andreas

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi Michael,

> So I think if you use one of these approaches, you are fine.

Definitely not. :o Apart from register dumps Ghidra was used to decompile and analyze the original driver and all steps were heavily AI assisted. Also, the driver is still kind of rough.

> I think there
> must be a human involved to review the specification for copyrighted material.
> But also for quality control.

I can have a look at every piece I give out.

> So, yeah. Feel free to post both your specification and your implementation if you like.
> Please also fully disclose how the intermediate steps were developed and
> what role AI assistance played.
> Then we can decide how to continue.

I'm keeping the repo private for now, I'm happy to review the spec or give it out piecewise, just to be safe, if someone is interested in implementing it.

> I hope that not too many changes to the existing common parts and other PHYs are
> needed, to keep the regression risk low.

It's about 11.000 lines but I think the common parts weren't changed too much.

I`m looking forward to hearing your opinion.

Best regards,
Andreas


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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Mon, 28 Sep 2026 21:49:23 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> if someone is interested in implementing it.

I think the number of people interested in working on this is probably
approaching zero these days.

Maybe we can find somebody doing an AI implementation from specs.
But then, why not publish yours instead?

-- 
Michael Büsch
https://bues.ch/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Michael Büsch]

[-- Attachment #1.1: Type: text/plain, Size: 400 bytes --]

On Mon, 28 Sep 2026 21:49:23 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> if someone is interested in implementing it.

I think the number of people interested in working on this is probably
approaching zero these days.

Maybe we can find somebody doing an AI implementation from specs.
But then, why not publish yours instead?

-- 
Michael Büsch
https://bues.ch/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> I think the number of people interested in working on this is probably approaching zero these days.

Probably.

> Maybe we can find somebody doing an AI implementation from specs.

Yes that should be fairly easy: Let AI write it and modprobe/rmmod it.

Maybe I can also start a new clean AI session with just the spec. Would that count?

> But then, why not publish yours instead?

I thought it would be easier if I don't do that, but of course I can make it public.

Best regards,
Andreas

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> I think the number of people interested in working on this is probably approaching zero these days.

Probably.

> Maybe we can find somebody doing an AI implementation from specs.

Yes that should be fairly easy: Let AI write it and modprobe/rmmod it.

Maybe I can also start a new clean AI session with just the spec. Would that count?

> But then, why not publish yours instead?

I thought it would be easier if I don't do that, but of course I can make it public.

Best regards,
Andreas


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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 08:14:03 +0200
Michael Büsch <m@bues.ch> wrote:

> On Mon, 28 Sep 2026 21:49:23 +0000
> "andreas.wendleder" <andreas.wendleder@proton.me> wrote:
> 
> > if someone is interested in implementing it.  
> 
> I think the number of people interested in working on this is probably
> approaching zero these days.
> 
> Maybe we can find somebody doing an AI implementation from specs.
> But then, why not publish yours instead?
> 

I'm still working on my driver for 4352/4360, so two of us actually.

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 08:14:03 +0200
Michael Büsch <m@bues.ch> wrote:

> On Mon, 28 Sep 2026 21:49:23 +0000
> "andreas.wendleder" <andreas.wendleder@proton.me> wrote:
> 
> > if someone is interested in implementing it.  
> 
> I think the number of people interested in working on this is probably
> approaching zero these days.
> 
> Maybe we can find somebody doing an AI implementation from specs.
> But then, why not publish yours instead?
> 

I'm still working on my driver for 4352/4360, so two of us actually.

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> > Maybe we can find somebody doing an AI implementation from specs.
> > But then, why not publish yours instead?
> >
> 
> I'm still working on my driver for 4352/4360, so two of us actually.

Cool. Does it work? What does work?

So how do we proceed from here? I'm in the dirty room. :)

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> > Maybe we can find somebody doing an AI implementation from specs.
> > But then, why not publish yours instead?
> >
> 
> I'm still working on my driver for 4352/4360, so two of us actually.

Cool. Does it work? What does work?

So how do we proceed from here? I'm in the dirty room. :)
 

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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 07:49:35 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> > > Maybe we can find somebody doing an AI implementation from specs.
> > > But then, why not publish yours instead?
> > >  
> > 
> > I'm still working on my driver for 4352/4360, so two of us
> > actually.  
> 
> Cool. Does it work? What does work?
> 
> So how do we proceed from here? I'm in the dirty room. :)
>  

At the moment i have to retry it on hardware, last time it crashed
because mac writes were incomplete, it is 5Ghz only because i have only
routers with no 2.4GHz antennas for the 4352/4360. It is based on the
7.14.89 broadcom driver and ucode rev42 ver 928. Also, all my routers
have femctrl = 6 from the srom, so i don't know what to do when the
value is different. Least, but not last, the wl order of macro operation
and b43 order are different in multiple places, how did you reconcile
the two?

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 07:49:35 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> > > Maybe we can find somebody doing an AI implementation from specs.
> > > But then, why not publish yours instead?
> > >  
> > 
> > I'm still working on my driver for 4352/4360, so two of us
> > actually.  
> 
> Cool. Does it work? What does work?
> 
> So how do we proceed from here? I'm in the dirty room. :)
>  

At the moment i have to retry it on hardware, last time it crashed
because mac writes were incomplete, it is 5Ghz only because i have only
routers with no 2.4GHz antennas for the 4352/4360. It is based on the
7.14.89 broadcom driver and ucode rev42 ver 928. Also, all my routers
have femctrl = 6 from the srom, so i don't know what to do when the
value is different. Least, but not last, the wl order of macro operation
and b43 order are different in multiple places, how did you reconcile
the two?

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> Least, but not last, the wl order of macro operation and b43 order are different in multiple places, how did you reconcile the two?

Good sign: we're core_rev 42 too, so our disassembly and yours should be
directly comparable.

femctrl/srom: not touched, no handling anywhere in our port. One fixed
test board, so we've never hit a different value. No data point to
offer - if you find out what it gates, let me know.

wl order vs b43 order: we captured wl's real register-access sequence live (bpftrace kprobes on its own osl_readl/writel/delay, wl left loaded and bound throughout - never touch its binding while probes attach) and diffed it against our call order, case by case. 

Sharpest example:
b43's generic switch_channel calls the per-channel tune, then
unconditionally re-applies a captured POR snapshot afterward - captured during wl's first association, on channel 1. So channel 6 got tuned correctly, then immediately overwritten back to channel 1's values.
wl's real order runs the POR replay once at attach, not after every
switch. Cost us a real mistune bug before the trace diff caught it.
Smaller example, same category: our TX-cal port was missing one PHY
register write wl issues between the gain-table override and starting the test tone - doesn't crash, just makes the measurement never differentiate.

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> Least, but not last, the wl order of macro operation and b43 order are different in multiple places, how did you reconcile the two?

Good sign: we're core_rev 42 too, so our disassembly and yours should be
directly comparable.

femctrl/srom: not touched, no handling anywhere in our port. One fixed
test board, so we've never hit a different value. No data point to
offer - if you find out what it gates, let me know.

wl order vs b43 order: we captured wl's real register-access sequence live (bpftrace kprobes on its own osl_readl/writel/delay, wl left loaded and bound throughout - never touch its binding while probes attach) and diffed it against our call order, case by case. 

Sharpest example:
b43's generic switch_channel calls the per-channel tune, then
unconditionally re-applies a captured POR snapshot afterward - captured during wl's first association, on channel 1. So channel 6 got tuned correctly, then immediately overwritten back to channel 1's values.
wl's real order runs the POR replay once at attach, not after every
switch. Cost us a real mistune bug before the trace diff caught it.
Smaller example, same category: our TX-cal port was missing one PHY
register write wl issues between the gain-table override and starting the test tone - doesn't crash, just makes the measurement never differentiate.


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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 08:27:53 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> > Least, but not last, the wl order of macro operation and b43 order
> > are different in multiple places, how did you reconcile the two?  
> 
> Good sign: we're core_rev 42 too, so our disassembly and yours should
> be directly comparable.
> 

I didn't mass disassemble, i just hooked the io accessors, both because
it is faster to learn what the driver is doing and less problematic if
someone ask. Also the trace can be shared, the disassembly does not.

> femctrl/srom: not touched, no handling anywhere in our port. One fixed
> test board, so we've never hit a different value. No data point to
> offer - if you find out what it gates, let me know.

So you harcoded your srom?

> 
> wl order vs b43 order: we captured wl's real register-access sequence
> live (bpftrace kprobes on its own osl_readl/writel/delay, wl left
> loaded and bound throughout - never touch its binding while probes
> attach) and diffed it against our call order, case by case. 
> 
> Sharpest example:
> b43's generic switch_channel calls the per-channel tune, then
> unconditionally re-applies a captured POR snapshot afterward -
> captured during wl's first association, on channel 1. So channel 6
> got tuned correctly, then immediately overwritten back to channel 1's
> values. wl's real order runs the POR replay once at attach, not after
> every switch. Cost us a real mistune bug before the trace diff caught
> it. Smaller example, same category: our TX-cal port was missing one
> PHY register write wl issues between the gain-table override and
> starting the test tone - doesn't crash, just makes the measurement
> never differentiate.
>

But which driver version did you look at? The 6.30 hybrid?

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

On Tue, 29 Sep 2026 08:27:53 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> > Least, but not last, the wl order of macro operation and b43 order
> > are different in multiple places, how did you reconcile the two?  
> 
> Good sign: we're core_rev 42 too, so our disassembly and yours should
> be directly comparable.
> 

I didn't mass disassemble, i just hooked the io accessors, both because
it is faster to learn what the driver is doing and less problematic if
someone ask. Also the trace can be shared, the disassembly does not.

> femctrl/srom: not touched, no handling anywhere in our port. One fixed
> test board, so we've never hit a different value. No data point to
> offer - if you find out what it gates, let me know.

So you harcoded your srom?

> 
> wl order vs b43 order: we captured wl's real register-access sequence
> live (bpftrace kprobes on its own osl_readl/writel/delay, wl left
> loaded and bound throughout - never touch its binding while probes
> attach) and diffed it against our call order, case by case. 
> 
> Sharpest example:
> b43's generic switch_channel calls the per-channel tune, then
> unconditionally re-applies a captured POR snapshot afterward -
> captured during wl's first association, on channel 1. So channel 6
> got tuned correctly, then immediately overwritten back to channel 1's
> values. wl's real order runs the POR replay once at attach, not after
> every switch. Cost us a real mistune bug before the trace diff caught
> it. Smaller example, same category: our TX-cal port was missing one
> PHY register write wl issues between the gain-table override and
> starting the test tone - doesn't crash, just makes the measurement
> never differentiate.
>

But which driver version did you look at? The 6.30 hybrid?

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> If you are using an older ucode, probably my driver don't work on your
> device because it interact with newer ucode, can you look for mac
> behaviour diff from yours? Maybe we can merge the handling with some
> ifs, repo here: https://github.com/aleferri/b43-ac-wip

 I'm on ucode42.fw (D11 core rev 42), firmware 832.127 (2014-09-19); my driver checks SHM UCODEREV against ≤0x128. I don't have a captured rev number to compare against yours off-hand — what ucode rev/date does your driver target? I've mapped a decent chunk of the real MAC event loop (dispatcher + wait points) and the watchdog tick (SHM 0x158, ~1.024s) by decompiling wl, so a diff is doable if I know what to diff against. Game for merging with #ifdefs if the divergence is small.

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

> If you are using an older ucode, probably my driver don't work on your
> device because it interact with newer ucode, can you look for mac
> behaviour diff from yours? Maybe we can merge the handling with some
> ifs, repo here: https://github.com/aleferri/b43-ac-wip

 I'm on ucode42.fw (D11 core rev 42), firmware 832.127 (2014-09-19); my driver checks SHM UCODEREV against ≤0x128. I don't have a captured rev number to compare against yours off-hand — what ucode rev/date does your driver target? I've mapped a decent chunk of the real MAC event loop (dispatcher + wait points) and the watchdog tick (SHM 0x158, ~1.024s) by decompiling wl, so a diff is doable if I know what to diff against. Game for merging with #ifdefs if the divergence is small.

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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Tue, 29 Sep 2026 14:45:41 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> > If you are using an older ucode, probably my driver don't work on
> > your device because it interact with newer ucode, can you look for
> > mac behaviour diff from yours? Maybe we can merge the handling with
> > some ifs, repo here: https://github.com/aleferri/b43-ac-wip  
> 
>  I'm on ucode42.fw (D11 core rev 42), firmware 832.127 (2014-09-19);
> my driver checks SHM UCODEREV against ≤0x128. I don't have a captured
> rev number to compare against yours off-hand — what ucode rev/date
> does your driver target? I've mapped a decent chunk of the real MAC
> event loop (dispatcher + wait points) and the watchdog tick (SHM
> 0x158, ~1.024s) by decompiling wl, so a diff is doable if I know what
> to diff against. Game for merging with #ifdefs if the divergence is
> small.


i have firmware 938.1502, October 2017, as the "target", but i ran a
similarity scan between 938.1502 ucode and 938.10005 and there are no
changes except for the version. The 938.1201 likewise is also very
similar, as far as the similarity tool is concerned. While they are all
very different from the 784.2 from my D Link dsl 3580L router.
So at this point there are 3 version of ucode for AC:
- 784.2 is the original one, dated 2012
- 832.127 is the broadcom sta for linux one
- 938.1xxx is the most recent one

You seems to have decoded fairly well the rx/tx path, i have instead
understood quite a lot of the phy/radio level, you could try to
incorporate my work for the phy and test if you it can improve your own
results. I will take your decoding of the mac handling to test 784.2
and 938.1xxx ucodes. 

If you send me your raw bits of srom and opt with a full trace from wl
unloaded to wl loaded, bss up and running, i can tell you if there are
still blindspots in my phy code or if you should be good to go.

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Tue, 29 Sep 2026 14:45:41 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> > If you are using an older ucode, probably my driver don't work on
> > your device because it interact with newer ucode, can you look for
> > mac behaviour diff from yours? Maybe we can merge the handling with
> > some ifs, repo here: https://github.com/aleferri/b43-ac-wip  
> 
>  I'm on ucode42.fw (D11 core rev 42), firmware 832.127 (2014-09-19);
> my driver checks SHM UCODEREV against ≤0x128. I don't have a captured
> rev number to compare against yours off-hand — what ucode rev/date
> does your driver target? I've mapped a decent chunk of the real MAC
> event loop (dispatcher + wait points) and the watchdog tick (SHM
> 0x158, ~1.024s) by decompiling wl, so a diff is doable if I know what
> to diff against. Game for merging with #ifdefs if the divergence is
> small.


i have firmware 938.1502, October 2017, as the "target", but i ran a
similarity scan between 938.1502 ucode and 938.10005 and there are no
changes except for the version. The 938.1201 likewise is also very
similar, as far as the similarity tool is concerned. While they are all
very different from the 784.2 from my D Link dsl 3580L router.
So at this point there are 3 version of ucode for AC:
- 784.2 is the original one, dated 2012
- 832.127 is the broadcom sta for linux one
- 938.1xxx is the most recent one

You seems to have decoded fairly well the rx/tx path, i have instead
understood quite a lot of the phy/radio level, you could try to
incorporate my work for the phy and test if you it can improve your own
results. I will take your decoding of the mac handling to test 784.2
and 938.1xxx ucodes. 

If you send me your raw bits of srom and opt with a full trace from wl
unloaded to wl loaded, bss up and running, i can tell you if there are
still blindspots in my phy code or if you should be good to go.

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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

Hi Alessio,

Thanks again, and sorry for the delay. I've gone through your repo and am working with it. Attached are the SROM dump and the wl traces you asked for, then one concrete question.

Attached (see README.txt inside for formats and conditions):
 - the raw SROM words of this MacBookAir6,1 (BCM4360, core rev 42, radio 2069 rev 4), a rev 11 image, plus the ChipCommon/PMU state with our port loaded;
 - four wl 6.30.223.271 traces, from "unloaded" to BSS up on 2.4 GHz and on 5 GHz, plus one with traffic, and an ifdown/ifup;
 - MAC register snapshots under wl and under our port.

I have no OTP dump. Our port never reads it and I can't reload wl here without a reboot. If you can tell me the ChipCommon OTP read sequence for this chip, I'll dump it.

State. Our port associates and passes traffic on 2.4 GHz (ch11), but only about 20-30% of fresh inits come up clean. In the other cases the PHY holds carrier sense (phydebug 0x5 = CRS|TXF) with a TX frame posted, MAC suspend failed follows, and the ucode sits in NAP (PSM PC 0x000f, the end of its scheduler loop). It wakes only about every 1-2.5 s. A clean init stays clean for a long time.

Already tried from your repo, all with no effect on that rate: TX FIFO geometry (we already match 0019), object-address read-back (0020), MAC setup before PHY plus TSF fraction 0x6614b, the PSM_PHY_HDR/FGC pairing, PMU (PLL words already 0x0c31/0x100e, max_res_mask forced to 0x7ff), and the CRS threshold forced to 68 and 120. A post-init register snapshot of 50 inits shows no static PHY or radio difference between good and bad ones, so it looks like a runtime wake problem, not an init-state one.

Question. In your bus captures, what does the stock driver do to keep or wake the ucode when it posts TX frames, beyond the single DMA pointer write? In our wl trace that write is the only MMIO at a TX post, and MACCTL goes 0x44020403 during suspend/enable windows and back to 0x40020403 between them. Do you see anything similar, or another register (IHR event mask at 0x40, an AWAKE/HWPS rule, a periodic wake) that we don't?

Also, if you can share it, the MacBookAir6,1 bus capture of wl 6.30 from your README would be very useful, since it's our exact hardware. Your PHY code is 5 GHz only so far. Is 2.4 GHz planned?

Thanks,
Andreas

[-- Attachment #2: for-alessio.tar --]
[-- Type: application/x-tar, Size: 12994560 bytes --]

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 01:31:24 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks again, and sorry for the delay. I've gone through your repo
> and am working with it. Attached are the SROM dump and the wl traces
> you asked for, then one concrete question.
> 
> Attached (see README.txt inside for formats and conditions):
>  - the raw SROM words of this MacBookAir6,1 (BCM4360, core rev 42,
> radio 2069 rev 4), a rev 11 image, plus the ChipCommon/PMU state with
> our port loaded;
>  - four wl 6.30.223.271 traces, from "unloaded" to BSS up on 2.4 GHz
> and on 5 GHz, plus one with traffic, and an ifdown/ifup;
>  - MAC register snapshots under wl and under our port.
> 
> I have no OTP dump. Our port never reads it and I can't reload wl
> here without a reboot. If you can tell me the ChipCommon OTP read
> sequence for this chip, I'll dump it.

Thank you!

> 
> State. Our port associates and passes traffic on 2.4 GHz (ch11), but
> only about 20-30% of fresh inits come up clean. In the other cases
> the PHY holds carrier sense (phydebug 0x5 = CRS|TXF) with a TX frame
> posted, MAC suspend failed follows, and the ucode sits in NAP (PSM PC
> 0x000f, the end of its scheduler loop). It wakes only about every
> 1-2.5 s. A clean init stays clean for a long time.
> 
> Already tried from your repo, all with no effect on that rate: TX
> FIFO geometry (we already match 0019), object-address read-back
> (0020), MAC setup before PHY plus TSF fraction 0x6614b, the
> PSM_PHY_HDR/FGC pairing, PMU (PLL words already 0x0c31/0x100e,
> max_res_mask forced to 0x7ff), and the CRS threshold forced to 68 and
> 120. A post-init register snapshot of 50 inits shows no static PHY or
> radio difference between good and bad ones, so it looks like a
> runtime wake problem, not an init-state one.
> 
> Question. In your bus captures, what does the stock driver do to keep
> or wake the ucode when it posts TX frames, beyond the single DMA
> pointer write? In our wl trace that write is the only MMIO at a TX
> post, and MACCTL goes 0x44020403 during suspend/enable windows and
> back to 0x40020403 between them. Do you see anything similar, or
> another register (IHR event mask at 0x40, an AWAKE/HWPS rule, a
> periodic wake) that we don't?

WL program the awake bit during every mac suspension to prevent the
ucode from entering sleep. B43 don't do it by default, you have to
patch it.

> 
> Also, if you can share it, the MacBookAir6,1 bus capture of wl 6.30
> from your README would be very useful, since it's our exact hardware.

That is one of your early trace, in fact, i picked up when you wrote to
b43. If you want to see something new, you are better off with T5E
trace, it is the same 6.30 driver on different hardware

> Your PHY code is 5 GHz only so far. Is 2.4 GHz planned?

Yes, since you are giving me a complete 2.4Ghz trace, now i can look on
it. Most logic should be already there, but some fixes maybe be
needed.

> 
> Thanks,
> Andreas

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 01:31:24 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks again, and sorry for the delay. I've gone through your repo
> and am working with it. Attached are the SROM dump and the wl traces
> you asked for, then one concrete question.
> 
> Attached (see README.txt inside for formats and conditions):
>  - the raw SROM words of this MacBookAir6,1 (BCM4360, core rev 42,
> radio 2069 rev 4), a rev 11 image, plus the ChipCommon/PMU state with
> our port loaded;
>  - four wl 6.30.223.271 traces, from "unloaded" to BSS up on 2.4 GHz
> and on 5 GHz, plus one with traffic, and an ifdown/ifup;
>  - MAC register snapshots under wl and under our port.
> 
> I have no OTP dump. Our port never reads it and I can't reload wl
> here without a reboot. If you can tell me the ChipCommon OTP read
> sequence for this chip, I'll dump it.

Thank you!

> 
> State. Our port associates and passes traffic on 2.4 GHz (ch11), but
> only about 20-30% of fresh inits come up clean. In the other cases
> the PHY holds carrier sense (phydebug 0x5 = CRS|TXF) with a TX frame
> posted, MAC suspend failed follows, and the ucode sits in NAP (PSM PC
> 0x000f, the end of its scheduler loop). It wakes only about every
> 1-2.5 s. A clean init stays clean for a long time.
> 
> Already tried from your repo, all with no effect on that rate: TX
> FIFO geometry (we already match 0019), object-address read-back
> (0020), MAC setup before PHY plus TSF fraction 0x6614b, the
> PSM_PHY_HDR/FGC pairing, PMU (PLL words already 0x0c31/0x100e,
> max_res_mask forced to 0x7ff), and the CRS threshold forced to 68 and
> 120. A post-init register snapshot of 50 inits shows no static PHY or
> radio difference between good and bad ones, so it looks like a
> runtime wake problem, not an init-state one.
> 
> Question. In your bus captures, what does the stock driver do to keep
> or wake the ucode when it posts TX frames, beyond the single DMA
> pointer write? In our wl trace that write is the only MMIO at a TX
> post, and MACCTL goes 0x44020403 during suspend/enable windows and
> back to 0x40020403 between them. Do you see anything similar, or
> another register (IHR event mask at 0x40, an AWAKE/HWPS rule, a
> periodic wake) that we don't?

WL program the awake bit during every mac suspension to prevent the
ucode from entering sleep. B43 don't do it by default, you have to
patch it.

> 
> Also, if you can share it, the MacBookAir6,1 bus capture of wl 6.30
> from your README would be very useful, since it's our exact hardware.

That is one of your early trace, in fact, i picked up when you wrote to
b43. If you want to see something new, you are better off with T5E
trace, it is the same 6.30 driver on different hardware

> Your PHY code is 5 GHz only so far. Is 2.4 GHz planned?

Yes, since you are giving me a complete 2.4Ghz trace, now i can look on
it. Most logic should be already there, but some fixes maybe be
needed.

> 
> Thanks,
> Andreas


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

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi Alessio,

Thanks for the 2.4 GHz trace work. Short status, then the questions.

Status: b43 now runs as the daily connection on my MacBookAir6,1 (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works with legacy rates and a TX status fix. Upload is about 18 Mbit/s and download about 10.

The open problem: only about 21% of fresh inits can transmit. The state is fixed at init. In a bad init the PHY holds CRS|TXF and every TX ends in a PHY transmission error, so auth frames are never ACKed. A reload wrapper retries until an init connects, which takes 2-5 tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX core mask, TX power control, the CRS threshold and the MAC setup order.

I've updated the clean-room spec (§10 covers this) and can send it if it's useful.

Questions:

Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init and first transmit on a BCM4360 (agcombo or TG789vac), including the calibration phase? I'd diff it against mine at register level.
Can your harness score our driver's register-write sequence against your captures? That would show where we diverge without hardware tests.
Does stock wl ever give you a "bad init" on any of your boards (the PHY cannot transmit until the next reset)? That would tell us whether the cause is in our init or in the chip.

If your 2.4 GHz support lands, I'll test it on this laptop right away.

Thanks,
Andreas

AW: Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi Alessio,

Thanks for the 2.4 GHz trace work. Short status, then the questions.

Status: b43 now runs as the daily connection on my MacBookAir6,1 (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works with legacy rates and a TX status fix. Upload is about 18 Mbit/s and download about 10.

The open problem: only about 21% of fresh inits can transmit. The state is fixed at init. In a bad init the PHY holds CRS|TXF and every TX ends in a PHY transmission error, so auth frames are never ACKed. A reload wrapper retries until an init connects, which takes 2-5 tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX core mask, TX power control, the CRS threshold and the MAC setup order.

I've updated the clean-room spec (§10 covers this) and can send it if it's useful.

Questions:

Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init and first transmit on a BCM4360 (agcombo or TG789vac), including the calibration phase? I'd diff it against mine at register level.
Can your harness score our driver's register-write sequence against your captures? That would show where we diverge without hardware tests.
Does stock wl ever give you a "bad init" on any of your boards (the PHY cannot transmit until the next reset)? That would tell us whether the cause is in our init or in the chip.

If your 2.4 GHz support lands, I'll test it on this laptop right away.

Thanks,
Andreas

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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 12:06:05 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the 2.4 GHz trace work. Short status, then the questions.
> 
> Status: b43 now runs as the daily connection on my MacBookAir6,1
> (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works
> with legacy rates and a TX status fix. Upload is about 18 Mbit/s and
> download about 10.
> 
> The open problem: only about 21% of fresh inits can transmit. The
> state is fixed at init. In a bad init the PHY holds CRS|TXF and every
> TX ends in a PHY transmission error, so auth frames are never ACKed.
> A reload wrapper retries until an init connects, which takes 2-5
> tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX
> core mask, TX power control, the CRS threshold and the MAC setup
> order.

Your phy initialization is still the verbatim copy taken from a run of
wl or you reconstructed the phy ops? Also, are you reading the srom
correctly as rev11? I have the bcma code to read it properly in my repo.

> 
> I've updated the clean-room spec (§10 covers this) and can send it if
> it's useful.
> 
> Questions:
> 
> Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init
> and first transmit on a BCM4360 (agcombo or TG789vac), including the
> calibration phase? I'd diff it against mine at register level. Can
> your harness score our driver's register-write sequence against your
> captures? That would show where we diverge without hardware tests.
> Does stock wl ever give you a "bad init" on any of your boards (the
> PHY cannot transmit until the next reset)? That would tell us whether
> the cause is in our init or in the chip.

Only 5ghz for the 4360 with agcombo, one of the trace is configured
with wep auth, note that the 5Ghz only 4360 is a 3x3.

> 
> If your 2.4 GHz support lands, I'll test it on this laptop right away.

Thank you, i am trying to reconstruct the phy init for 2.4Ghz from your
trace

> 
> Thanks,
> Andreas

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 12:06:05 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the 2.4 GHz trace work. Short status, then the questions.
> 
> Status: b43 now runs as the daily connection on my MacBookAir6,1
> (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works
> with legacy rates and a TX status fix. Upload is about 18 Mbit/s and
> download about 10.
> 
> The open problem: only about 21% of fresh inits can transmit. The
> state is fixed at init. In a bad init the PHY holds CRS|TXF and every
> TX ends in a PHY transmission error, so auth frames are never ACKed.
> A reload wrapper retries until an init connects, which takes 2-5
> tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX
> core mask, TX power control, the CRS threshold and the MAC setup
> order.

Your phy initialization is still the verbatim copy taken from a run of
wl or you reconstructed the phy ops? Also, are you reading the srom
correctly as rev11? I have the bcma code to read it properly in my repo.

> 
> I've updated the clean-room spec (§10 covers this) and can send it if
> it's useful.
> 
> Questions:
> 
> Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init
> and first transmit on a BCM4360 (agcombo or TG789vac), including the
> calibration phase? I'd diff it against mine at register level. Can
> your harness score our driver's register-write sequence against your
> captures? That would show where we diverge without hardware tests.
> Does stock wl ever give you a "bad init" on any of your boards (the
> PHY cannot transmit until the next reset)? That would tell us whether
> the cause is in our init or in the chip.

Only 5ghz for the 4360 with agcombo, one of the trace is configured
with wep auth, note that the 5Ghz only 4360 is a 3x3.

> 
> If your 2.4 GHz support lands, I'll test it on this laptop right away.

Thank you, i am trying to reconstruct the phy init for 2.4Ghz from your
trace

> 
> Thanks,
> Andreas


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

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 12:06:05 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the 2.4 GHz trace work. Short status, then the questions.
> 
> Status: b43 now runs as the daily connection on my MacBookAir6,1
> (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works
> with legacy rates and a TX status fix. Upload is about 18 Mbit/s and
> download about 10.
> 
> The open problem: only about 21% of fresh inits can transmit. The
> state is fixed at init. In a bad init the PHY holds CRS|TXF and every
> TX ends in a PHY transmission error, so auth frames are never ACKed.
> A reload wrapper retries until an init connects, which takes 2-5
> tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX
> core mask, TX power control, the CRS threshold and the MAC setup
> order.
> 
> I've updated the clean-room spec (§10 covers this) and can send it if
> it's useful.
> 
> Questions:
> 
> Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init
> and first transmit on a BCM4360 (agcombo or TG789vac), including the
> calibration phase? I'd diff it against mine at register level. Can
> your harness score our driver's register-write sequence against your
> captures? That would show where we diverge without hardware tests.
> Does stock wl ever give you a "bad init" on any of your boards (the
> PHY cannot transmit until the next reset)? That would tell us whether
> the cause is in our init or in the chip.
> 
> If your 2.4 GHz support lands, I'll test it on this laptop right away.
> 

Oh, i forgot, you have femctrl = 2, all of my boards have femctrl = 6,
so probably the calibration is wrong for your card, but now i try to
fix it. Thank again!

> Thanks,
> Andreas

Re: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[Alessio Ferri]

Il giorno Thu, 01 Oct 2026 12:06:05 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks for the 2.4 GHz trace work. Short status, then the questions.
> 
> Status: b43 now runs as the daily connection on my MacBookAir6,1
> (BCM4360, core rev 42, radio 2069 rev 4). The 2.4 GHz station works
> with legacy rates and a TX status fix. Upload is about 18 Mbit/s and
> download about 10.
> 
> The open problem: only about 21% of fresh inits can transmit. The
> state is fixed at init. In a bad init the PHY holds CRS|TXF and every
> TX ends in a PHY transmission error, so auth frames are never ACKed.
> A reload wrapper retries until an init connects, which takes 2-5
> tries. I've ruled out temperature, DMA, ASPM, PLL lock, clocks, TX
> core mask, TX power control, the CRS threshold and the MAC setup
> order.
> 
> I've updated the clean-room spec (§10 covers this) and can send it if
> it's useful.
> 
> Questions:
> 
> Do you have a bus-level trace (wl-mmio-trap) of a 2.4 GHz cold init
> and first transmit on a BCM4360 (agcombo or TG789vac), including the
> calibration phase? I'd diff it against mine at register level. Can
> your harness score our driver's register-write sequence against your
> captures? That would show where we diverge without hardware tests.
> Does stock wl ever give you a "bad init" on any of your boards (the
> PHY cannot transmit until the next reset)? That would tell us whether
> the cause is in our init or in the chip.
> 
> If your 2.4 GHz support lands, I'll test it on this laptop right away.
> 

Oh, i forgot, you have femctrl = 2, all of my boards have femctrl = 6,
so probably the calibration is wrong for your card, but now i try to
fix it. Thank again!

> Thanks,
> Andreas


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