Re: Rebuilding brcmfmac Wi-Fi driver with the help of AI

Hey-hey,

>> Given the workflow, prompts, AI models to use, etc. are in place AND you
have
>> a physical Raspberry Pi 4, how long would it take to vibe-port
brcmfmac43455-sdio
>> wifi driver? The complication it is attached via SDIO interface, not PCI!
>
> That'd be fun thing to try. I've forgotten that RPi4 comes with a
broadcom chip.
> Will find some time to spin up a testing stand, and will see how that
goes.

This's been keeping me busy, and it hasn't been a smooth ride so far. But I
finally
saw some exciting progress today.

Currently, the codebase is a mess [1]. But we (mainly agents, of course) got
Raspberry Pi 4b to connect to my home Wi-Fi AP (5GHz, WPA2), and sent
traffic
to the Internet.

One problem was that the stock kernel, that came with the RPI image
(FreeBSD-15.0-RELEASE-arm64-aarch64-RPI.img) needed patching and a fixed
device
tree overlay. The RPI4-HOWTO.md [2] in the driver's repo has more details.

*Again, to be 100% clear and hones: these are experimental "vibes" to see
how far
the AI tooling can push. I'm welcoming productive feedback about the
results.*

The repo's docs/00-progress.md [3] has a list of next steps to fix, before
I'll ask the agents
to do a deep code-review and refactoring.

Details of the tests:

freebsd@rpi4-freebsd-1:~ % uname -v
FreeBSD 15.0-STABLE #2 9c49c393a81b-dirty: Fri Mar 27 22:59:19 CET 2026
v@freebsd-test-0:/usr/obj/usr/src/arm64.aarch64/sys/SDIO

% dmesg | grep -i 'raspberry pi'
gpio1: <Raspberry Pi Firmware GPIO controller> on bcm2835_firmware0

% sysctl hw.model
hw.model: ARM Cortex-A72 r0p3

% ls /boot/firmware/ | grep brcm
brcmfmac43455-sdio.bin
brcmfmac43455-sdio.clm_blob
brcmfmac43455-sdio.txt

% kldstat
Id Refs Address                Size Name
 1    8 0xffff000000000000  1446958 kernel
 2    1 0xffff0000b2c00000    33000 if_brcmfmac.ko

% ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=0
ether dc:a6:32:29:7b:1b
inet 192.168.188.182 netmask 0xffffff00 broadcast 192.168.188.255
groups: wlan
ssid ██████ channel 116 (5580 MHz 11a ht/20) bssid 1c██████:3c
country 511 authmode WPA2/802.11i privacy ON deftxkey UNDEF
AES-CCM 2:128-bit AES-CCM 3:128-bit AES-CCM ucast:128-bit txpower 0
bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 -ht -htcompat -ampdu
ampdulimit 8k -amsdu -stbc -ldpc -uapsd wme roaming MANUAL
parent interface: brcmfmac0
media: IEEE 802.11 Wireless Ethernet MCS mode 11na
status: associated
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

% traceroute -i wlan0 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
 1  192.168.188.114 (192.168.188.114)  185.541 ms  34.019 ms  53.549 ms
 2  192.168.188.1 (192.168.188.1)  49.716 ms  47.651 ms  49.251 ms
 3  10.103.18.1 (10.103.18.1)  55.914 ms  44.769 ms  57.156 ms
 4  89.246.252.169 (89.246.252.169)  46.803 ms  13.387 ms  48.198 ms
 5  i689729BA.versanet.de (104.151.41.186)  52.102 ms  51.937 ms  50.030 ms
 6  62.214.73.216 (62.214.73.216)  53.640 ms  43.454 ms  58.782 ms
 7  62.214.73.217 (62.214.73.217)  49.132 ms  49.143 ms  46.480 ms
 8  one.one.one.one (1.1.1.1)  51.158 ms  49.501 ms  56.651 ms

P.S. Zig has gone from the driver's codebase. Making it work in a kernel
driver
on aarch64 turned out even more challenging today. I'll park the idea into
a backlog
of future playground projects.

[1]: https://github.com/narqo/freebsd-brcmfmac
[2]:
https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/RPI4-HOWTO.md
[3]:
https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/docs/00-progress.md

Cheers,
V.


On Thu, 12 Mar 2026 at 09:56, Vladimir Varankin <vladimir@varank.in> wrote:

> > Given the workflow, prompts, AI models to use, etc. are in place AND you
> have
> > a physical Raspberry Pi 4, how long would it take to vibe-port
> brcmfmac43455-sdio
> > wifi driver? The complication it is attached via SDIO interface, not PCI!
>
> That'd be fun thing to try. I've forgotten that RPi4 comes with
> a broadcom chip.
> Will find some time to spin up a testing stand, and will see how that goes.
>
> >  C/Zig split rationale - at the end 94.7% of code is in C, 4.7% in Zig.
> Would you still
> > go for anything in Zig again?
>
> Initially I was sold by Zig's promise of interoperability with C [1].
>
> Given that I'm more comfortable with Zig compiler's promises, the thinking
> was that
> understanding the details will be simpler for me, when the majority of
> code is generated
> by AIs. In practice this didn't work out: the interoperability has number
> of corner cases,
> that, as an example, doesn't "just work" with kernel's linker.
>
> So it's not Zig the language was the issue. But the extra supporting
> layers needed
> to make it work required more involvement than I (naively) hoped it will
> be.
>
> Although, it works, I'm willing to rewrite Zig's chunk back to C, just to
> avoid it to be an easy
> target to latch on in the critics of the approach.
>
> [1]:
> https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings
>
> On Wed, 11 Mar 2026 at 16:16, Bugs Beastie <bugsbeastie@gmail.com> wrote:
>
>> Mar 10, 2026 20:33:53 Vladimir Varankin <vladimir@varank.in>:
>>
>> > I recently wrote a blog post [1] sharing my experience of rebuilding
>> > a Wi-Fi driver for BCM4350 for FreeBSD with the help of agenting AI
>> > tooling.
>> >
>> Omitting any comments about AI usege,...cool and impressive! :)
>>
>> Very practical question:
>> Given the workflow, prompts, AI models to use, etc. are in place AND you
>> have a physical Raspberry Pi 4, how long would it take to vibe-port
>> brcmfmac43455-sdio wifi driver? The complication it is attached via SDIO
>> interface, not PCI!
>>
>> Question out of curiosity:
>> C/Zig split rationale - at the end 94.7% of code is in C, 4.7% in Zig.
>> Would you still go for anything in Zig again?
>>
>> > I'm aware that different groups of people have different opinions about
>> > the topic of using AI in software development. Still I think this was
>> > a fairly interesting experiment, and I'm curious to hear the opinion
>> > on the approach and the results, from people close to in-tree drivers
>> > development.
>> >
>> > The GitHub repository [2] includes documentation about the testing
>> > approach, recorded decisions and know issues (which I'm — still with
>> > the help of AI agents — addressing in my spare time).
>> >
>> > P.S. Just to be absolute clear: I'm not proposing or suggesting to
>> > upstream the code of this driver. Neither do I think that in the current
>> > state the AIs can vibe-code something reliable in one go. But I do
>> think,
>> > the tooling can be a huge multiplier for building, testing, explaining,
>> > reviewing, etc large bodies of complex code.
>> >
>> > Cheers,
>> > V.
>> >
>> > [1]: https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/
>> > [2]: https://github.com/narqo/freebsd-brcmfmac
>> >
>> > --
>> > Vladimir Varankin
>> > vladimir@varank.in
>>
>>
>>
>
> --
> Vladimir Varankin
> vladimir@varank.in
>


-- 
Vladimir Varankin
vladimir@varank.in