From nobody Sat Mar 28 00:25:43 2026 X-Original-To: freebsd-wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fjJG24pBYz6X74k for ; Sat, 28 Mar 2026 00:26:02 +0000 (UTC) (envelope-from bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in) Received: from e3i456.smtp2go.com (e3i456.smtp2go.com [158.120.85.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4fjJG12Dy6z3JR8 for ; Sat, 28 Mar 2026 00:26:01 +0000 (UTC) (envelope-from bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=varank.in header.s=s653246 header.b=lL9pUjFJ; dmarc=pass (policy=none) header.from=varank.in; spf=pass (mx1.freebsd.org: domain of "bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in" designates 158.120.85.200 as permitted sender) smtp.mailfrom="bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=varank.in; i=@varank.in; q=dns/txt; s=s653246; t=1774657554; h=from : subject : to : message-id : date; bh=/w+Xw1P6rJ4/1YJnAtd0img2HXpt1P94fj4wdSG0Tyw=; b=lL9pUjFJKz+60gEWfUSbOebcYL2h30Uv0FIwYcAI6jpLbnPc4zm3Pozpgxc4abXvsC6t8 nAZm8Fq5kMrzw5gQiwH/B6w07Nd290HAItL9zqtLu6kAiHYtHJfy+BpYGjuHzsSKzGY+LYX 0wvyKcHwkx7j8vwb5+Rt2YD4ypPrCt0RSHq5HUSSl8l0mE38Tge47egUVoaLL5dJe47PBZw mKqkx3e/mL/wzp3ZHLj9/U3Zgmyv6vTT4MPT31e+rkCCYqGCOeDeox38k9mrhPylvY7VUEk ZH62V/C4VvV6n4v3QvOIooZfQdl6LbAnameyQ1fixvCUICreQDCt+MpKAMKw== Received: from [10.66.241.78] (helo=mail-pf1-f169.google.com) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.99.1-S2G) (envelope-from ) id 1w6HUw-4o5NDgrfmvS-fE5o for freebsd-wireless@freebsd.org; Sat, 28 Mar 2026 00:25:54 +0000 Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-82985f42664so1608305b3a.0 for ; Fri, 27 Mar 2026 17:25:54 -0700 (PDT) X-Gm-Message-State: AOJu0YwSKlGGhH7XC6hwzwAxRqfnplNWEG9zPTAzE3bj/TwW+GZAUfXZ BZD6PIQVasCChtUHuNQUrdr+/hkAQibRovpPOUExs1OG5GmwIpJL8PoGSws2BSlP2jgIWt73ibY rD6ZFT6el9bXtmeUGvkXYRnAU5FDT9qI= X-Received: by 2002:a05:6a00:c82:b0:82a:ea3:c16f with SMTP id d2e1a72fcca58-82c960341d1mr4283529b3a.53.1774657554389; Fri, 27 Mar 2026 17:25:54 -0700 (PDT) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-wireless@freebsd.org Sender: owner-freebsd-wireless@FreeBSD.org MIME-Version: 1.0 References: <75f56507-49e8-4f43-987f-7025d62b0bd9@gmail.com> In-Reply-To: From: Vladimir Varankin Date: Sat, 28 Mar 2026 01:25:43 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AQROBzDCw2eApPQRcgjEbXUbASxsiSdgyQvxXfN672EoLb7iqic9F5PmZy4x8yo Message-ID: Subject: Re: Rebuilding brcmfmac Wi-Fi driver with the help of AI To: Bugs Beastie Cc: freebsd-wireless@freebsd.org Content-Type: multipart/alternative; boundary="00000000000020a270064e0aa981" X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 653246m:653246a4bqTde:653246soHGFQkrE5 X-smtpcorp-track: UK6A71r3DYu6.C8IQlIrf86Io.YLh3zQAj5AU X-Spamd-Result: default: False [-4.09 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[varank.in,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[158.120.85.200:from]; FORGED_SENDER(0.30)[vladimir@varank.in,bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in]; R_SPF_ALLOW(-0.20)[+ip4:158.120.80.0/21]; R_DKIM_ALLOW(-0.20)[varank.in:s=s653246]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:23352, ipnet:158.120.84.0/22, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[vladimir@varank.in,bounce.1x22bho7z8ku0d4=jrxa692um2hl=68i0f06mvmp314@em653246.varank.in]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-wireless@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-wireless@freebsd.org]; DKIM_TRACE(0.00)[varank.in:+] X-Rspamd-Queue-Id: 4fjJG12Dy6z3JR8 X-Spamd-Bar: ---- --00000000000020a270064e0aa981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) go= t 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: 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=3D8843 metric 0 mtu 15= 00 options=3D0 ether dc:a6:32:29:7b:1b inet 192.168.188.182 netmask 0xffffff00 broadcast 192.168.188.255 groups: wlan ssid =E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88 channel 116 (55= 80 MHz 11a ht/20) bssid 1c=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2= =96=88: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=3D29 % 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/629b801123966bbbea71d5ff8ccb= 7a789f43e792/RPI4-HOWTO.md [3]: https://github.com/narqo/freebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb= 7a789f43e792/docs/00-progress.md Cheers, V. On Thu, 12 Mar 2026 at 09:56, Vladimir Varankin wrote: > > Given the workflow, prompts, AI models to use, etc. are in place AND yo= u > 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 PC= I! > > 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 goe= s. > > > 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 thinkin= g > 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 wrote: > >> Mar 10, 2026 20:33:53 Vladimir Varankin : >> >> > 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 abou= t >> > 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 =E2=80=94 stil= l with >> > the help of AI agents =E2=80=94 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 curre= nt >> > 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 > --=20 Vladimir Varankin vladimir@varank.in --00000000000020a270064e0aa981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey-hey,

>> Given the workflow, prompts, AI m= odels to use, etc. are in place AND you have
>> a physical Raspber= ry 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>>
> That'd be fun thing to try. I've forgotten that RPi= 4 comes with a broadcom chip.
> Will find some time to spin up a test= ing stand, and will see how that goes.

This's been keeping me bu= sy, 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 prob= lem 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.<= br>
*Again, to be 100% clear and hones: these are experimental "vib= es" to see how far
the AI tooling can push. I'm welcoming produ= ctive feedback about the results.*

The repo's docs/00-progr= ess.md [3] has a list of next steps to fix, before I'll ask the agents<= /div>
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/ob= j/usr/src/arm64.aarch64/sys/SDIO

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

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

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

% kldstat
Id Refs Address = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Size Name
=C2=A01= =C2=A0 =C2=A08 0xffff000000000000 =C2=A01446958 kernel
=C2=A02 =C2=A0 = =C2=A01 0xffff0000b2c00000 =C2=A0 =C2=A033000 if_brcmfmac.ko

% ifcon= fig wlan0
wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&= gt; metric 0 mtu 1500
options=3D0
ether dc:a6:32:29:7b:1b
inet = 192.168.188.182 netmask 0xffffff00 broadcast 192.168.188.255
groups: wl= an
ssid =E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96=88 channel = 116 (5580 MHz 11a ht/20) bssid 1c=E2=96=88=E2=96=88=E2=96=88=E2=96=88=E2=96= =88=E2=96=88:3c
country 511 authmode WPA2/802.11i privacy ON deftxkey U= NDEF
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 inter= face: brcmfmac0
media: IEEE 802.11 Wireless Ethernet MCS mode 11na
= status: associated
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKL= OCAL>

% traceroute -i wlan0 1.1.1.1
traceroute to 1.1.1.1 (1.= 1.1.1), 64 hops max, 40 byte packets
=C2=A01 =C2=A0192.168.188.114 (192.= 168.188.114) =C2=A0185.541 ms =C2=A034.019 ms =C2=A053.549 ms
=C2=A02 = =C2=A0192.168.188.1 (192.168.188.1) =C2=A049.716 ms =C2=A047.651 ms =C2=A04= 9.251 ms
=C2=A03 =C2=A010.103.18.1 (10.103.18.1) =C2=A055.914 ms =C2=A04= 4.769 ms =C2=A057.156 ms
=C2=A04 =C2=A089.246.252.169 (89.246.252.169) = =C2=A046.803 ms =C2=A013.387 ms =C2=A048.198 ms
=C2=A05 =C2=A0i689729BA.versanet.de (104.151.41.186) = =C2=A052.102 ms =C2=A051.937 ms =C2=A050.030 ms
=C2=A06 =C2=A062.214.73.= 216 (62.214.73.216) =C2=A053.640 ms =C2=A043.454 ms =C2=A058.782 ms
=C2= =A07 =C2=A062.214.73.217 (62.214.73.217) =C2=A049.132 ms =C2=A049.143 ms = =C2=A046.480 ms
=C2=A08 =C2=A0one.one.one.one (1.1.1.1) =C2=A051.158 ms = =C2=A049.501 ms =C2=A056.651 ms

P.S. Zig has gone from the driver= 9;s codebase. Making it work in a kernel driver
on aarch64 turned out ev= en 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-br= cmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/RPI4-HOWTO.md
[= 3]: https://github.com/narqo/f= reebsd-brcmfmac/blob/629b801123966bbbea71d5ff8ccb7a789f43e792/docs/00-progr= ess.md

Cheers,
V.

<= /div>

On Thu, 12 Mar 2026 at 09:56, Vladimir Var= ankin <vladimir@varank.in> = wrote:
> Given the workflow, prompts, AI models to us= e, etc. are in place AND you have
> a physical Raspberry Pi 4, how long would = it take to vibe-port=20 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=C2=A0broadcom=C2= =A0chip.
Will find some time to spin up a testing stand, and will= see how that goes.

>= =C2=A0 C/Zig split rationale - at the end 94.7% of code is in C, 4.7% in Zig. Woul= d you still
> go for anything in Zig again?
<= div dir=3D"ltr">
Initially I was sold by Zig's promise of= =C2=A0interoperability with C [1].

Given that I= 9;m more comfortable with Zig compiler's promises, the thinking was tha= t
understanding the details will be simpler for me, when the majo= rity of code is generated
by AIs. In practice this didn't wor= k out: the=C2=A0interoperability 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 m= ore 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.


On Wed, 11 Mar 2026 at 16:16, Bugs Beastie &l= t;bugsbeastie@gm= ail.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 ha= ve a physical Raspberry Pi 4, how long would it take to vibe-port brcmfmac4= 3455-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. Woul= d 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<= br> > a fairly interesting experiment, and I'm curious to hear the opini= on
> on the approach and the results, from people close to in-tree drivers<= br> > development.
>
> The GitHub repository [2] includes documentation about the testing
> approach, recorded decisions and know issues (which I'm =E2=80=94 = still with
> the help of AI agents =E2=80=94 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 curre= nt
> state the AIs can vibe-code something reliable in one go. But I do thi= nk,
> 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@varan= k.in




--
Vladimir Varankin


--
Vladimir Varankin
--00000000000020a270064e0aa981--