Date: Sat, 28 Mar 2026 01:25:43 +0100 From: Vladimir Varankin <vladimir@varank.in> To: Bugs Beastie <bugsbeastie@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: Rebuilding brcmfmac Wi-Fi driver with the help of AI Message-ID: <CAGLqCMmgSX7FebjUuRh-Qjbdt9bnq0Rm=As1D_g=45qgrVY8jw@mail.gmail.com> In-Reply-To: <CAGLqCMm8nV1dSnVgKj5jQ6Hie-UY30XpeATsnsK=PV%2BauTaSnw@mail.gmail.com> References: <CAGLqCM=55k2j%2B_-pH7Sdh2SevXyrr6GF3yMaSD_RJMXSfxaz3Q@mail.gmail.com> <75f56507-49e8-4f43-987f-7025d62b0bd9@gmail.com> <CAGLqCMm8nV1dSnVgKj5jQ6Hie-UY30XpeATsnsK=PV%2BauTaSnw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr">Hey-hey,<br><br>>> Given the workflow, prompts, AI models to use, etc. are in place AND you have<br>>> a physical Raspberry Pi 4, how long would it take to vibe-port brcmfmac43455-sdio<br>>> wifi driver? The complication it is attached via SDIO interface, not PCI!<br>><br>> That'd be fun thing to try. I've forgotten that RPi4 comes with a broadcom chip.<br>> Will find some time to spin up a testing stand, and will see how that goes.<br><br>This's been keeping me busy, and it hasn't been a smooth ride so far. But I finally<br>saw some exciting progress today.<br><br>Currently, the codebase is a mess [1]. But we (mainly agents, of course) got<br>Raspberry Pi 4b to connect to my home Wi-Fi AP (5GHz, WPA2), and sent traffic<br>to the Internet.<br><br>One problem was that the stock kernel, that came with the RPI image<br>(FreeBSD-15.0-RELEASE-arm64-aarch64-RPI.img) needed patching and a fixed device<br>tree overlay. The RPI4-HOWTO.md [2] in the driver's repo has more details.<br><br>*Again, to be 100% clear and hones: these are experimental "vibes" to see how far<br>the AI tooling can push. I'm welcoming productive feedback about the results.*<br><br><div>The repo's docs/00-progress.md [3] has a list of next steps to fix, before I'll ask the agents</div><div>to do a deep code-review and refactoring.</div><br>Details of the tests:<br><br>freebsd@rpi4-freebsd-1:~ % uname -v<br>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<br><br>% dmesg | grep -i 'raspberry pi'<br>gpio1: <Raspberry Pi Firmware GPIO controller> on bcm2835_firmware0<br><br>% sysctl hw.model<br>hw.model: ARM Cortex-A72 r0p3<br><br>% ls /boot/firmware/ | grep brcm<br>brcmfmac43455-sdio.bin<br>brcmfmac43455-sdio.clm_blob<br>brcmfmac43455-sdio.txt<br><br>% kldstat<br>Id Refs Address Size Name<br> 1 8 0xffff000000000000 1446958 kernel<br> 2 1 0xffff0000b2c00000 33000 if_brcmfmac.ko<br><br>% ifconfig wlan0<br>wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500<br> options=0<br> ether dc:a6:32:29:7b:1b<br> inet 192.168.188.182 netmask 0xffffff00 broadcast 192.168.188.255<br> groups: wlan<br> ssid ██████ channel 116 (5580 MHz 11a ht/20) bssid 1c██████:3c<br> country 511 authmode WPA2/802.11i privacy ON deftxkey UNDEF<br> AES-CCM 2:128-bit AES-CCM 3:128-bit AES-CCM ucast:128-bit txpower 0<br> bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 -ht -htcompat -ampdu<br> ampdulimit 8k -amsdu -stbc -ldpc -uapsd wme roaming MANUAL<br> parent interface: brcmfmac0<br> media: IEEE 802.11 Wireless Ethernet MCS mode 11na<br> status: associated<br> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL><br> <br>% traceroute -i wlan0 1.1.1.1<br>traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets<br> 1 192.168.188.114 (192.168.188.114) 185.541 ms 34.019 ms 53.549 ms<br> 2 192.168.188.1 (192.168.188.1) 49.716 ms 47.651 ms 49.251 ms<br> 3 10.103.18.1 (10.103.18.1) 55.914 ms 44.769 ms 57.156 ms<br> 4 89.246.252.169 (89.246.252.169) 46.803 ms 13.387 ms 48.198 ms<br> 5 <a href="http://i689729BA.versanet.de">i689729BA.versanet.de</a>; (104.151.41.186) 52.102 ms 51.937 ms 50.030 ms<br> 6 62.214.73.216 (62.214.73.216) 53.640 ms 43.454 ms 58.782 ms<br> 7 62.214.73.217 (62.214.73.217) 49.132 ms 49.143 ms 46.480 ms<br> 8 one.one.one.one (1.1.1.1) 51.158 ms 49.501 ms 56.651 ms<br><br>P.S. Zig has gone from the driver's codebase. Making it work in a kernel driver<br>on aarch64 turned out even more challenging today. I'll park the idea into a backlog<br><div>of future playground projects.</div><br>[1]: <a href="https://github.com/narqo/freebsd-brcmfmac">https://github.com/narqo/freebsd-brcmfmac</a><br>[2]: <a href="https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/RPI4-HOWTO.md">https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/RPI4-HOWTO.md</a><br>[3]: <a href="https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/docs/00-progress.md">https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/docs/00-progress.md</a><br><div><br></div><div><div>Cheers,</div><div>V.</div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 12 Mar 2026 at 09:56, Vladimir Varankin <<a href="mailto:vladimir@varank.in">vladimir@varank.in</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">> Given the workflow, prompts, AI models to use, etc. are in place AND you have</div><div dir="ltr">> a physical Raspberry Pi 4, how long would it take to vibe-port brcmfmac43455-sdio</div><div dir="ltr">> wifi driver? The complication it is attached via SDIO interface, not PCI!</div><div dir="ltr"><br></div><div>That'd be fun thing to try. I've forgotten that RPi4 comes with a broadcom chip.</div><div>Will find some time to spin up a testing stand, and will see how that goes.</div><div dir="ltr"><br></div><div dir="ltr">> C/Zig split rationale - at the end 94.7% of code is in C, 4.7% in Zig. Would you still</div><div dir="ltr">> go for anything in Zig again?</div><div dir="ltr"><br></div><div>Initially I was sold by Zig's promise of interoperability with C [1].</div><div><br></div><div>Given that I'm more comfortable with Zig compiler's promises, the thinking was that</div><div>understanding the details will be simpler for me, when the majority of code is generated</div><div>by AIs. In practice this didn't work out: the interoperability has number of corner cases,</div><div>that, as an example, doesn't "just work" with kernel's linker.</div><div><br></div><div>So it's not Zig the language was the issue. But the extra supporting layers needed</div><div>to make it work required more involvement than I (naively) hoped it will be.</div><div><br></div><div>Although, it works, I'm willing to rewrite Zig's chunk back to C, just to avoid it to be an easy</div><div>target to latch on in the critics of the approach.</div><div><br></div><div>[1]: <a href="https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings" target="_blank">https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 11 Mar 2026 at 16:16, Bugs Beastie <<a href="mailto:bugsbeastie@gmail.com" target="_blank">bugsbeastie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mar 10, 2026 20:33:53 Vladimir Varankin <<a href="mailto:vladimir@varank.in" target="_blank">vladimir@varank.in</a>>:<br> <br> > I recently wrote a blog post [1] sharing my experience of rebuilding<br> > a Wi-Fi driver for BCM4350 for FreeBSD with the help of agenting AI<br> > tooling.<br> ><br> Omitting any comments about AI usege,...cool and impressive! :)<br> <br> Very practical question:<br> 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!<br> <br> Question out of curiosity:<br> 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?<br> <br> > I'm aware that different groups of people have different opinions about<br> > the topic of using AI in software development. Still I think this was<br> > a fairly interesting experiment, and I'm curious to hear the opinion<br> > on the approach and the results, from people close to in-tree drivers<br> > development.<br> ><br> > The GitHub repository [2] includes documentation about the testing<br> > approach, recorded decisions and know issues (which I'm — still with<br> > the help of AI agents — addressing in my spare time).<br> ><br> > P.S. Just to be absolute clear: I'm not proposing or suggesting to<br> > upstream the code of this driver. Neither do I think that in the current<br> > state the AIs can vibe-code something reliable in one go. But I do think,<br> > the tooling can be a huge multiplier for building, testing, explaining,<br> > reviewing, etc large bodies of complex code.<br> ><br> > Cheers,<br> > V.<br> ><br> > [1]: <a href="https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/" rel="noreferrer" target="_blank">https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/</a><br>; > [2]: <a href="https://github.com/narqo/freebsd-brcmfmac" rel="noreferrer" target="_blank">https://github.com/narqo/freebsd-brcmfmac</a><br>; ><br> > --<br> > Vladimir Varankin<br> > <a href="mailto:vladimir@varank.in" target="_blank">vladimir@varank.in</a><br> <br> <br> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-size:12.8px">Vladimir Varankin</div><div style="font-size:12.8px"><a href="mailto:vladimir@varank.in" target="_blank">vladimir@varank.in</a></div></div></div></div> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-size:12.8px">Vladimir Varankin</div><div style="font-size:12.8px"><a href="mailto:vladimir@varank.in" target="_blank">vladimir@varank.in</a></div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGLqCMmgSX7FebjUuRh-Qjbdt9bnq0Rm=As1D_g=45qgrVY8jw>