Raspberry pi 5 status

WiFi seems to be working, but will definitely need some refinements, testing.

github.com

Release v0.02-ALPHA · aphor/FreeBSD15-RPi5-modules

WiFi nominally working, needs testing. Uses polled-IO, and has not been performance tested for network latency or throughput or CPU/power/thermal efficiency. Please read the README.md
github.com github.com

I am sympathetic to people who want this functionality (or I wouldn't be doing this), but I cannot provide commercial/professional level support for people who aren't prepared to provide good bug reports. I DO value the community feedback, and I want this to eventually become high quality software, but please understand this is ALPHA quality (feature set is not stable), and is probably one step better than a rapid prototype implementation at this point. If you use this and you suffer consequences because the software is buggy then YOU are responsible for the consequences.

Please do not use this in any production capacity; please try it out and push it to fail and let me know to the best of your ability what went wrong.

If I can't measure it, I can't improve it. If I can't reproduce a behavior, I can't measure it. Please open a GitHub issue and provide details to enable reproduction of the bad behavior, describe the expectation, and describe the actual results, and I'll try my best to close the gap.
 
mamontez said:
Code: 
root@core:~ # sysctl hw.rp1_eth.mac_drv.stats
hw.rp1_eth.mac_drv.stats.rx_overrun_errs: 0
hw.rp1_eth.mac_drv.stats.rx_frames_fcs_errs: 0
hw.rp1_eth.mac_drv.stats.rx_frames: 2005
hw.rp1_eth.mac_drv.stats.rx_bytes: 206233
hw.rp1_eth.mac_drv.stats.tx_under_runs: 0
hw.rp1_eth.mac_drv.stats.tx_frames: 80
hw.rp1_eth.mac_drv.stats.tx_bytes: 5120

After some time, the values of the counters increase.
Click to expand...
Do you have a different cable and switch port to try?

Also which FreeBSD version are you building against?
 
aphor said:
Do you have a different cable and switch port to try?

Also which FreeBSD version are you building against?
Click to expand...

Yes, of course, I have a cable and a port.
I changed the cable and port, but nothing changed.

I am using: FreeBSD 15.0 - RELEASE - p9 default kernel.
 
Both hw.rp1_eth.mac_drv.stats.rx_frames and hw.rp1_eth.mac_drv.stats.tx_frames are accumulating values from hardware frame counters. They are only periodically updated @1 second interval. Your NIC *thinks* it is transmitting frames and receiving frames, but for some reason, probably the RX path doesn't pass the frames up the stack.

This could be broken hardware or firmware. If you would be willing to open an issue on the github repo, I'd like to try to figure this out in that context. I may need to collect details like hardware part numbers and firmware versions and work with you to provide a reliable reproducer script, and also cross check with others if anyone else has the same or similar hardware.
 
I got FreeBSD 16.0-CURRENT snapshot 2026-10-05 network working using the network port (no USB dongle). I am new to FreeBSD and used ChatGPT (and many hours of trial and error) so apologies if this is not the vibe of this forum.

I also compiled and loaded the fan and temp modules (not included below)

I am using my Pi5 as a headless server.

Below is the md summary file ChatGPT generated for me of our getting-things-working session.

Tested on an **8 GB Raspberry Pi 5**, FreeBSD **16.0-CURRENT snapshot 2026-10-05** (source commit `a52c50b4b7c2`), using **single-SD-card UEFI boot**. This is an experimental out-of-tree driver, **not upstream plug-and-play support**. Rebuild against matching kernel sources after kernel upgrades.

## Prerequisites

- Pi 5 UEFI from [NumberOneGit/rpi5-uefi releases](https://github.com/NumberOneGit/rpi5-uefi/releases) (`RPI_EFI.fd` on FAT boot partition); the original older UEFI v0.3 booted to a panic/freeze in this test, while the newer build booted.
- UEFI **System Table Mode = Both (ACPI + Device Tree)**; confirm `/dev/openfirm` exists.
- Matching FreeBSD kernel sources under `/usr/src/sys` (this test used `a52c50b4b7c2`). With no network, transfer source and driver archives using a FAT32 USB stick.
- Driver: [aphor/FreeBSD15-RPi5-modules](https://github.com/aphor/FreeBSD15-RPi5-modules).

## Two source changes that got packets flowing

In `rp1_eth_cfg.c`, the FDT lookup for `RP1_ETH_COMPAT_PRIMARY` (`raspberrypi,rp1-gem`) failed with `ENODEV` (error 19) despite the device tree containing `ethernet@100000` with `compatible = "cdns,macb"`. Add a **secondary lookup before returning ENODEV**:

C: 
gem_node = rp1_eth_fdt_find_compat(root, RP1_ETH_COMPAT_PRIMARY);
if (gem_node == 0)
    gem_node = rp1_eth_fdt_find_compat(root, RP1_ETH_COMPAT_SECONDARY);
if (gem_node == 0)
    return (ENODEV);

Check `rp1_eth_var.h` defines `RP1_ETH_COMPAT_SECONDARY` as `"cdns,macb"`. Avoid globally replacing the primary identifier: the fallback retains both matches. **Validate the node's register/PHY properties before using on other hardware**, since `cdns,macb` is generic.

In `rp1_eth.c`, the `cgem_gem_poll()` callback existed but wasn't being scheduled after interface initialisation. In `cgem_init_locked()`, after the existing `tick_ch` callout, add:

C: 
callout_reset(&sc->gem_poll, MAX(1, hz / 200), cgem_gem_poll, sc);

Preserve existing callout initialisation/teardown; inspect the source before applying this to a newer revision. Without this, link was active and hardware RX frames increased, but `netstat` `Ipkts` remained unchanged, `tcpdump` captured nothing, ARP was incomplete and DHCP got no offers. With the polling callout running, `Ipkts` increased and IPv4 ping succeeded.

## Build and test

sh: 
cd /root/FreeBSD15-RPi5-modules
make bcm2712_pcie
make rp1_eth
# Copy the built bcm2712_pcie.ko and rp1_eth.ko to /boot/modules/
# Reboot rather than hot-unloading an active experimental polling driver.
kldload /boot/modules/bcm2712_pcie.ko
kldload /boot/modules/rp1_eth.ko
ifconfig rp1eth0 up
ifconfig rp1eth0
ping -c 5 192.168.0.1  # example router; use your own gateway

Verify the network interface is `rp1eth0`, reports `status: active`, and `netstat -I rp1eth0 -b` shows `Ipkts` increasing during traffic. To debug the FDT directly:

sh: 
ofwdump -P compatible -S /axi/pcie@120000/rp1/ethernet@100000
sh tools/rp1_eth_fdt_dump.sh
 
You must log in or register to reply here.
Back
Top