FreeBSD · Embedded · Prague
Hundreds of boards run Linux. Only a handful run FreeBSD.
We are a Czech/Slovak group doing the unglamorous half of that problem: SoC board bring-up, kernel drivers, boot firmware and ports. Clocks, pinctrl, ethernet and switch drivers written against real hardware — then handed upstream to FreeBSD.
Boards
Every claim below is backed by code in a branch and a boot log from hardware on someone's desk. Where nothing has been done, the card says so.
Banana Pi R2 Pro
FreeBSD on the Rockchip RK3568 router board — switch works, the board routes
Banana Pi BPI-R64
FreeBSD on MediaTek MT7622 — ethernet, switch and WiFi drivers written from scratch
Banana Pi BPI-R2
FreeBSD on MediaTek MT7623 — the whole clock and pinctrl foundation, built from nothing
Banana Pi BPI-R3
MediaTek MT7986 (Filogic 830) — the next router board, not started yet
What we do
Driver development
Ethernet, switch, WiFi, clocks, pinctrl and GPIO for SoCs FreeBSD has never run on. Written from datasheets, tested on the board, not ported blind.
Boot firmware
U-Boot and ARM Trusted Firmware ports, plus recovery tooling. A kernel is useless if the board cannot boot it or you cannot unbrick it.
Ports maintenance
82 ports so the software people actually want is there when the board comes up — including the ARM machine learning stack on aarch64.
Upstreaming
The point is not a private fork. Work stabilizes, gets verified by someone else who owns the board, and goes to FreeBSD with every name on the patchset.
Why a group and not a fork per person
Solo bring-up is why FreeBSD is missing from so much hardware. One person carries a board for months, it half-works in their repo, and it never reaches the tree. SoCBSD exists to collapse that: partial work lands immediately, other owners of the same board fill in the rest, and every claim is verified against real hardware before it counts.