Firmware for reverse engineering b43?

Firmware for reverse engineering b43?

[Joshua Peisach]

Hi all,

As I've been getting into kernel development, I found the b43 driver
as a suitable place for me to work in, given its status as orphan and
my access to it having an old iMac.

When it comes to figuring out what code to write and how to implement
functions, I see that there has been a mix of answers across the driver.

Lots of functions refer to specs RE'd from the 4.x firmware[1], but
my own install uses 5.x firmware. Additionally, the 6.x firmware is
available.

For my reverse engineering process, I opened the firmware in Ghidra
and basically try to map the functionality to the driver, which appears
to be what was done with the 4.x specs?

But, as I compare to the newer firmware, some functions have been moved
or replaced. And sometimes, the newer firmware functions contradict the
RE'd 4.x specs, or have extra steps in its process.

Take b43_nphy_perical, or as known in the v4 firmware,
wlc_phy_perical_nphy. I got to this function because wlc_nphy_init calls
it. But actually, the RE'd version says init calls
wlc_phy_perical_nphy_run, which the firmware says is not the case
(it goes through wlc_phy_perical_nphy first, which has its own
conditions).

So, which is the best source of truth(s) for this driver? The v4.x
specs, the v5 firmware, or the v6 firmware? Which one should be used,
and which has a higher priority level over the other?

Keep in mind the v4 specs came before the release of Ghidra; now that
it exists, we can refer to it instead of manually probing functionality.
I've even seen Ghidra show different instructions than the 4.x spec.

Thanks,
-Josh

[1]: https://bcm-v4.sipsolutions.net

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

Re: Firmware for reverse engineering b43?

[Johannes Berg]

Hi,

> As I've been getting into kernel development, 

Welcome :)

> When it comes to figuring out what code to write and how to implement
> functions, I see that there has been a mix of answers across the driver.
> 
> Lots of functions refer to specs RE'd from the 4.x firmware[1], but
> my own install uses 5.x firmware. Additionally, the 6.x firmware is
> available.
> 
> For my reverse engineering process, I opened the firmware in Ghidra
> and basically try to map the functionality to the driver, which appears
> to be what was done with the 4.x specs?

Pretty much, though no Ghidra or AI assist or anything back then, we had
to hand-roll our own tools ;-)
The concern then was that we should have two teams so nobody can claim
copyright violations, but I obviously don't know what Broadcom's stance
on this is (now or then.) I do know they were impressed by the level of
reverse engineering, especially down into the device firmware itself :)

> But, as I compare to the newer firmware, some functions have been moved
> or replaced. And sometimes, the newer firmware functions contradict the
> RE'd 4.x specs, or have extra steps in its process.

No surprise I guess, things could even just shift by compiling them
differently.

> Take b43_nphy_perical, or as known in the v4 firmware,
> wlc_phy_perical_nphy. I got to this function because wlc_nphy_init calls
> it. But actually, the RE'd version says init calls
> wlc_phy_perical_nphy_run, which the firmware says is not the case
> (it goes through wlc_phy_perical_nphy first, which has its own
> conditions).
> 
> So, which is the best source of truth(s) for this driver? The v4.x
> specs, the v5 firmware, or the v6 firmware? Which one should be used,
> and which has a higher priority level over the other?

I think there's no easy answer - what are you even trying to achieve?
Does b43 not work sufficiently well? Do you even know if some specific
calibration have a tendency to go out of whack? Is there later firmware
that has some advantage (given how little actually happens in firmware
in these devices, I'd be surprised by that) but isn't compatible with
the driver now, and you want to change that?

I'd be tempted to say that if there's no problem there don't try to fix
anything, the hardware is ancient anyway, likely has few users, and
those users would probably be fine with just leaving it?

johannes

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

Re: Firmware for reverse engineering b43?

[Joshua Peisach]

On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
> I think there's no easy answer - what are you even trying to achieve?
> Does b43 not work sufficiently well? Do you even know if some specific
> calibration have a tendency to go out of whack? Is there later firmware
> that has some advantage (given how little actually happens in firmware
> in these devices, I'd be surprised by that) but isn't compatible with
> the driver now, and you want to change that?
>
> I'd be tempted to say that if there's no problem there don't try to fix
> anything, the hardware is ancient anyway, likely has few users, and
> those users would probably be fine with just leaving it?
>
> johannes

The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
by filling in TODOs and FIXME's, I could eventually get something
working.

Other than that, I was thinking of making improvements for the sake of
improving the driver.

-Josh

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

Re: Firmware for reverse engineering b43?

[Jonas Gorski]

Hi,

On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>
> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
> > I think there's no easy answer - what are you even trying to achieve?
> > Does b43 not work sufficiently well? Do you even know if some specific
> > calibration have a tendency to go out of whack? Is there later firmware
> > that has some advantage (given how little actually happens in firmware
> > in these devices, I'd be surprised by that) but isn't compatible with
> > the driver now, and you want to change that?
> >
> > I'd be tempted to say that if there's no problem there don't try to fix
> > anything, the hardware is ancient anyway, likely has few users, and
> > those users would probably be fine with just leaving it?
> >
> > johannes
>
> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
> by filling in TODOs and FIXME's, I could eventually get something
> working.
>
> Other than that, I was thinking of making improvements for the sake of
> improving the driver.

The initial version of the brcm80211 softmac driver [1] should also
help in making sense of some of the code (flag names etc). While it
officially only supports BCM43224 and newer on BCMA, it still had
remnants of support for older N-PHY revisions, so may help in finding
differences or explaining what code does.

I once considered trying to clean up b43 based on brcmsmac, but never
got around to it.

Best regards,
Jonas

[1] https://github.com/torvalds/linux/tree/a9533e7ea3c410fed2f4cd8b3e1e213e48529b75/drivers/staging/brcm80211

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

Re: Firmware for reverse engineering b43?

[Joshua Peisach]

On Tue Apr 14, 2026 at 8:24 AM EDT, Jonas Gorski wrote:
> On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>>
>> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
>> > I think there's no easy answer - what are you even trying to achieve?
>> > Does b43 not work sufficiently well? Do you even know if some specific
>> > calibration have a tendency to go out of whack? Is there later firmware
>> > that has some advantage (given how little actually happens in firmware
>> > in these devices, I'd be surprised by that) but isn't compatible with
>> > the driver now, and you want to change that?
>> >
>> > I'd be tempted to say that if there's no problem there don't try to fix
>> > anything, the hardware is ancient anyway, likely has few users, and
>> > those users would probably be fine with just leaving it?
>> >
>> > johannes
>>
>> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
>> by filling in TODOs and FIXME's, I could eventually get something
>> working.
>>
>> Other than that, I was thinking of making improvements for the sake of
>> improving the driver.
>
> The initial version of the brcm80211 softmac driver [1] should also
> help in making sense of some of the code (flag names etc). While it
> officially only supports BCM43224 and newer on BCMA, it still had
> remnants of support for older N-PHY revisions, so may help in finding
> differences or explaining what code does.
>
> I once considered trying to clean up b43 based on brcmsmac, but never
> got around to it.

It does appear to be similar - even the current brcm80211. So much so
that I sometimes need to think about whether b43 is actually a
duplicated driver.

Since b43 is in an orphan state, I thought it would be a great place to
start for kernel development. 5G doesn't work on that iMac, some of the
PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.

Because I'm one of those "there's always room for improvement people",
I was going to try to improve the driver, filling out TODOs, fixing
hardcoded register numbers, etc. But if it's best left alone.. then I
guess we can do that.

That is, assuming b43 is actually supposed to be a separate driver,
because if brcmsmac basically has the same code, then maybe we should
focus to centralizing everything? But then there's b43legacy.. hm...

-Josh

>
> Best regards,
> Jonas
>
> [1] https://github.com/torvalds/linux/tree/a9533e7ea3c410fed2f4cd8b3e1e213e48529b75/drivers/staging/brcm80211


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

Re: Firmware for reverse engineering b43?

[Jonas Gorski]

On Wed, Apr 15, 2026 at 1:44 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>
> On Tue Apr 14, 2026 at 8:24 AM EDT, Jonas Gorski wrote:
> > On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
> >>
> >> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
> >> > I think there's no easy answer - what are you even trying to achieve?
> >> > Does b43 not work sufficiently well? Do you even know if some specific
> >> > calibration have a tendency to go out of whack? Is there later firmware
> >> > that has some advantage (given how little actually happens in firmware
> >> > in these devices, I'd be surprised by that) but isn't compatible with
> >> > the driver now, and you want to change that?
> >> >
> >> > I'd be tempted to say that if there's no problem there don't try to fix
> >> > anything, the hardware is ancient anyway, likely has few users, and
> >> > those users would probably be fine with just leaving it?
> >> >
> >> > johannes
> >>
> >> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
> >> by filling in TODOs and FIXME's, I could eventually get something
> >> working.
> >>
> >> Other than that, I was thinking of making improvements for the sake of
> >> improving the driver.
> >
> > The initial version of the brcm80211 softmac driver [1] should also
> > help in making sense of some of the code (flag names etc). While it
> > officially only supports BCM43224 and newer on BCMA, it still had
> > remnants of support for older N-PHY revisions, so may help in finding
> > differences or explaining what code does.
> >
> > I once considered trying to clean up b43 based on brcmsmac, but never
> > got around to it.
>
> It does appear to be similar - even the current brcm80211. So much so
> that I sometimes need to think about whether b43 is actually a
> duplicated driver.
>
> Since b43 is in an orphan state, I thought it would be a great place to
> start for kernel development. 5G doesn't work on that iMac, some of the
> PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.
>
> Because I'm one of those "there's always room for improvement people",
> I was going to try to improve the driver, filling out TODOs, fixing
> hardcoded register numbers, etc. But if it's best left alone.. then I
> guess we can do that.
>
> That is, assuming b43 is actually supposed to be a separate driver,
> because if brcmsmac basically has the same code, then maybe we should
> focus to centralizing everything? But then there's b43legacy.. hm...

It is/was intentionally a separate driver: Broadcom didn't want to
maintain support for obsolete chips (anything SSB, anything older than
BCM43224), so the decision was to have b43 support all the "legacy"
chips, while brcm80211 supports everything never. Since they were both
based on the same driver, they are (more or less) the same
architecture.

But now that Broadcom has essentially abandoned the softmac part of
brcm80211 since several years, I don't think there would be many
objections on unifying it with b43.

Best regards,
Jonas

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

Re: Firmware for reverse engineering b43?

[Michael Büsch]

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

On Wed, 15 Apr 2026 13:54:31 +0200
Jonas Gorski <jonas.gorski@gmail.com> wrote:

> On Wed, Apr 15, 2026 at 1:44 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
> > It does appear to be similar - even the current brcm80211. So much so
> > that I sometimes need to think about whether b43 is actually a
> > duplicated driver.
> >
> > Since b43 is in an orphan state, I thought it would be a great place to
> > start for kernel development. 5G doesn't work on that iMac, some of the
> > PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.
> >
> > Because I'm one of those "there's always room for improvement people",
> > I was going to try to improve the driver, filling out TODOs, fixing
> > hardcoded register numbers, etc. But if it's best left alone.. then I
> > guess we can do that.
> >
> > That is, assuming b43 is actually supposed to be a separate driver,
> > because if brcmsmac basically has the same code, then maybe we should
> > focus to centralizing everything? But then there's b43legacy.. hm...  
> 
> It is/was intentionally a separate driver: Broadcom didn't want to
> maintain support for obsolete chips (anything SSB, anything older than
> BCM43224), so the decision was to have b43 support all the "legacy"
> chips, while brcm80211 supports everything never. Since they were both
> based on the same driver, they are (more or less) the same
> architecture.
> 
> But now that Broadcom has essentially abandoned the softmac part of
> brcm80211 since several years, I don't think there would be many
> objections on unifying it with b43.

The hardest part in the b43 development always was not to break already
working stuff. There are many different types and revisions of the hardware
out there. Probably in the order of many dozens of variants.

Please keep in mind that changing code means mostly testing.
Which is hard, if you don't have the hardware variants and basically no
users exist anymore. Just implementing random TODOs and missing pieces
will break things. (e.g. not doing some HW calibration or workaround might
be better than only partially doing it or doing it wrong).

I would personally not touch this thing anymore, except for security fixes and such.

But if you want to work on the code, long term, I would welcome that.
We could even arrange that I ship you some hardware.
But keep in mind, it's all almost 20 years old legacy stuff.

-- 
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

Re: Firmware for reverse engineering b43?

[Joshua Peisach]

On Wed Apr 15, 2026 at 11:57 AM EDT, Michael Büsch wrote:
> On Wed, 15 Apr 2026 13:54:31 +0200
> Jonas Gorski <jonas.gorski@gmail.com> wrote:
>
>> On Wed, Apr 15, 2026 at 1:44 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>> > It does appear to be similar - even the current brcm80211. So much so
>> > that I sometimes need to think about whether b43 is actually a
>> > duplicated driver.
>> >
>> > Since b43 is in an orphan state, I thought it would be a great place to
>> > start for kernel development. 5G doesn't work on that iMac, some of the
>> > PHYs, like the AC PHYs appear to be incomplete - it felt reasonable.
>> >
>> > Because I'm one of those "there's always room for improvement people",
>> > I was going to try to improve the driver, filling out TODOs, fixing
>> > hardcoded register numbers, etc. But if it's best left alone.. then I
>> > guess we can do that.
>> >
>> > That is, assuming b43 is actually supposed to be a separate driver,
>> > because if brcmsmac basically has the same code, then maybe we should
>> > focus to centralizing everything? But then there's b43legacy.. hm...  
>> 
>> It is/was intentionally a separate driver: Broadcom didn't want to
>> maintain support for obsolete chips (anything SSB, anything older than
>> BCM43224), so the decision was to have b43 support all the "legacy"
>> chips, while brcm80211 supports everything never. Since they were both
>> based on the same driver, they are (more or less) the same
>> architecture.
>> 
>> But now that Broadcom has essentially abandoned the softmac part of
>> brcm80211 since several years, I don't think there would be many
>> objections on unifying it with b43.
>
> The hardest part in the b43 development always was not to break already
> working stuff. There are many different types and revisions of the hardware
> out there. Probably in the order of many dozens of variants.
>
> Please keep in mind that changing code means mostly testing.
> Which is hard, if you don't have the hardware variants and basically no
> users exist anymore. Just implementing random TODOs and missing pieces
> will break things. (e.g. not doing some HW calibration or workaround might
> be better than only partially doing it or doing it wrong).
>

Well, if the regression risk is that high, then I guess I'll let it be.

> I would personally not touch this thing anymore, except for security fixes and such.
>

Sure. I might just make sure everything is using register definitions
instead of hardcoded values, but then leave it there.

> But if you want to work on the code, long term, I would welcome that.
> We could even arrange that I ship you some hardware.
> But keep in mind, it's all almost 20 years old legacy stuff.

The only b43 devices I have are the aforementioned iMac, and also the
Wii. And unless the hardware is unique in some other way, I don't think
its worth sending it to me. Besides, if the code is so risky to touch,
then the only technical change I make should just be to fix my 5G
situation.

I didn't intend to become a b43 maintainer, and given where I currently
am lifewise, I don't think it's worth trying to fulfill that role long
term. Hopefully I'll find areas of work in brcm80211 to work in. It
just so happened that "make sure the kernel works on everything you can
get your hands on" stumbled across b43, which I thought would be a good
starting point.

So I guess this driver just sits here.. not quite pointless to be
removed from the main tree, but not quite worth the effort to bring it
up to speed.

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

Re: Firmware for reverse engineering b43?

[Michael Büsch]

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

On Wed, 15 Apr 2026 13:04:40 -0400
"Joshua Peisach" <jpeisach@ubuntu.com> wrote:
> Well, if the regression risk is that high, then I guess I'll let it be.

> Sure. I might just make sure everything is using register definitions
> instead of hardcoded values, but then leave it there.

I mean, I don't want to discourage you from doing anything,
but I just wanted to point out that this is a lot more work than just implement
a TODO here and there.

For most of the code we don't really know what it does exactly.
That may change a bit, if you pull over some code from the newer drivers.
But I don't think the situation will improve fundamentally.

> So I guess this driver just sits here.. not quite pointless to be
> removed from the main tree, but not quite worth the effort to bring it
> up to speed.

Well, it probably still works well on the (few) devices it worked well on,
because it basically hasn't changed.
There are many devices which were never supported at all or were never supported
properly. It's not that just your device is missing to complete
the perfect picture :-)

There might be better uses of your time than working on this legacy stuff.
For example working on the microcode reverse engineering and tools and
get them updated for the current generation of devices is probably
much more useful. And I think much more fun, too.
Or something else altogether.

-- 
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

Re: Firmware for reverse engineering b43?

[Joshua Peisach]

On Wed Apr 15, 2026 at 1:41 PM EDT, Michael Büsch wrote:
>
> Well, it probably still works well on the (few) devices it worked well on,
> because it basically hasn't changed.
> There are many devices which were never supported at all or were never supported
> properly. It's not that just your device is missing to complete
> the perfect picture :-)
>

Of course - but I don't currently feel like bending over backwards for
this one chip. Keep the working stuff working.

> There might be better uses of your time than working on this legacy stuff.
> For example working on the microcode reverse engineering and tools and
> get them updated for the current generation of devices is probably
> much more useful. And I think much more fun, too.
> Or something else altogether.

I can gladly say that using Ghidra on the firmware, v4, v5, and v6 is
amazing. Export symbols help a lot, and it gives you a good idea of what
is going on; with the exception of the decompiler giving goto statements
that jump all over the place and make things confusing :/

But again, it's legacy.

As for newer gens - I thought they are already provided by Broadcom
devs in the kernel? I may be wrong, I can look later.

Thanks :)
-Josh

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