Re: Rebuilding brcmfmac Wi-Fi driver with the help of AI
Date: Sun, 29 Mar 2026 15:38:37 UTC
Hello, It seems that OpenBSD and NetBSD have drivers for BCM43455. Could those drivers be imported fo FreeBSD? Thanks, Vladimir Varankin <vladimir@varank.in> escreveu (sábado, 28/03/2026 à(s) 00:26): > 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 > -- Nuno Teixeira FreeBSD UNIX: <eduardo@FreeBSD.org> Web: https://FreeBSD.org