Successfully running VyOS on BPI-R4

Canoziia · November 3, 2025, 6:51pm

Update: Please visit GitHub - KawaiiNetworks/vyos-bpi-r4: VyOS for BPI-R4 for more details.

Because 6.12 has some problems with 6Ghz Wifi, I upgrade the kernel to 6.17.

After several days of effort, I finally succeeded in running Vyos on BPI-R4.

Very nice board

sinovoip · November 4, 2025, 12:46am

hope you can show more about this .

Canoziia · November 4, 2025, 1:34am

I’m organizing a document, and it might take a few days. I’ll get it done as soon as possible.

tutugreen · November 4, 2025, 12:15pm

Wow, that’s a nice attempt!

guioday83 · November 5, 2025, 4:27pm

Which vyos image did you used? Can you share?

Canoziia · November 8, 2025, 11:49am

Please visit GitHub - KawaiiNetworks/vyos-bpi-r4: VyOS for BPI-R4

Canoziia · November 8, 2025, 11:50am

Hello,

I create a github repo to share the process and image:

blunden · November 16, 2025, 5:36pm

Awesome work! I will be following this thread.

Does it work properly with hardware flow offloading too? VyOS should support that if the driver support is there in the kernel. I’d be curious to know if you tried it?

If I just want to try your builds, can I just download the iso and use the generate_img.sh script to create the sdcard?

Also, your VyOS update instructions mention tar.gz files that are not available under releases despite what the instructions claim.

Finally, is flashing u-boot to SPI flash necessary to boot from the sdcard or only from the built-in NAND and eMMC storage?

frank-w · November 16, 2025, 5:54pm

Interesting that vyos also uses debian packages. And you build kernel from my source

If you found any patches useful for others i maybe can integrate it in my repo. Have only seen it in the script.but patches applied on my source look not interesting,maybe defconfig changes.

blunden · November 16, 2025, 6:10pm

VyOS is based on Debian (as was Vyatta which it was originally forked from years ago), so that’s not surprising.

It’s indeed nice to see the kernel being pulled from your repo and built from source, so that we get to benefit from the great work you are doing to get these working well on more standard Linux distros than OpenWrt, as well as the mainlining work.

Canoziia · November 16, 2025, 6:25pm

Thank you very much for your kernel/u-boot source! I list them on the readme.

My repository is essentially just a place for building images, and it doesn’t actually contain many modifications to the kernel or the VyOS build scripts. I’m still fairly new to Linux kernel development, but if I find useful patches in the future, I’ll try submitting PRs to your repository.

Canoziia · November 16, 2025, 6:32pm

What you saw before was probably the ISO image I created for x64 devices.

For BPI-R4, please try Release 2025.11.08-1112-rolling-6.17.0-bpi-r4 · KawaiiNetworks/vyos-bpi-r4 · GitHub . You can flash the .img file to SD card.

they are created from different branches.

I haven’t test the hardware flow offloading but I guess If I use the correct kernel source, it should work properly?

blunden · November 16, 2025, 7:00pm

Ah yes, you’re right. I didn’t read properly, as it clearly says amd64 in the file name for the first github release. My bad.

Nice. I’ll try the sdcard image once I have some time to play around with it. I want to try OpenWrt on the BPI-R4 first for a few days to see how it behaves on a “stable” release. I only switched over from my Qotom Intel Atom C3758 based VyOS router a few hours ago.

I guess it should be fairly obvious if the hardware offloading is working with some speed tests once I test it. As long as PPE support has been implemented in the kernel, it should presumably just work, yes.

I assume that I need to use the serial console to access it and configure basic networking as well as enable SSH on it?

Being able to toggle between booting VyOS (on sdcard) and OpenWrt (on eMMC or NAND) using a hardware switch is pretty sweet.

blunden · January 8, 2026, 8:33pm

@Canoziia Are you running these builds on your board as your actual router or would you still consider them a work in progress with known bugs? Just curious.

Thinking of trying them out in that capacity sometime soon.

Canoziia · January 9, 2026, 2:44am

I’m running the latest build on my board with 6GHz wifi and 4 ethernets on. It’s working fine so far, and I haven’t found serious bugs.

blunden · January 9, 2026, 3:02pm

That sounds promising. Thank you!

Hopefully the SFP+ slots work properly now. It seemed like the person who had issues mentioned it worked better now, but the Guthub issue is still open.

frank-w · January 9, 2026, 5:12pm

which issue do you mean? i have no issues with sfp-modules yet…some are not supported due to electrical problem (pull modddef0 after they got power, but r4 needs moddef0 to supply power to the module) as far as i know. my 1G H!Fibre do not work on R4 for example, the 2.5G copper SFP do work (but here the 2500baseX quirk seems broken somehow but now erics phy driver is upstream)

blunden · January 9, 2026, 5:35pm

I was talking about the github issue linked below:

github.com/KawaiiNetworks/vyos-bpi-r4

10G SFP problems

opened 03:27PM - 26 Nov 25 UTC

fbfonex

Hi, I have pulled down the latest image (11.26) and it booted without any proble…ms (thanks). I am trying to use the 10G ports for my uplink and I have a DAC cable, which was working fine using OpenWRT on the same device. When I insert it I get the following output: [ 377.949215] mtk_soc_eth 15100000.ethernet eth3: autoneg setting not compatible with PCS I figured out that eth4 and eth3 are the 2 10G SFP+ cage I have on my unit. I have attempted to set the speed manually to 10G, but I was unsucessful. vyos# set interfaces ethernet eth4 speed 10000 vyos# set interfaces ethernet eth4 duplex full [edit] vyos# commit [ interfaces ethernet eth4 ] Traceback (most recent call last): File "/usr/libexec/vyos/services/vyos-configd", line 157, in run_script script.apply(c) File "/usr/libexec/vyos/conf_mode/interfaces_ethernet.py", line 435, in apply e.update(ethernet) File "/usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py", line 539, in update self.set_speed_duplex(speed, duplex) File "/usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py", line 244, in set_speed_duplex return self._cmd(cmd) ^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/ifconfig/control.py", line 66, in _cmd return cmd(command, self.debug, env=env) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/utils/process.py", line 189, in cmd raise OSError(code, feedback) OSError: [Errno 75] failed to run command: None ethtool --change eth4 speed 10000 duplex full autoneg off returned: exit code: 75 [[interfaces ethernet eth4]] failed Commit failed [edit] Any suggestions?

It looks like the issue was resolved by moving to a build with your 6.18 kernel, but I the issue hasn’t been closed. I figure that’s because it was forgotten (I forget to do that myself from time to time ) or because the developer is keeping it open for a while in case further related issues are discovered.

blunden · January 9, 2026, 8:08pm

@Canoziia If VyOS requires the MAC addresses of the network interfaces to be persistent, wouldn’t I also have to set MAC addresses for the two SFP+ slots? Your patch here doesn’t seem to do that:

github.com

KawaiiNetworks/vyos-bpi-r4/blob/6.18-bpi-r4/patches/BPI-Router-Linux/0001-bpi-r4-eth-name.patch

diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
index 91d39b84f3ea..54658d99f0d4 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -187,7 +187,8 @@ &gsw_phy0_led0 {
 };
 
 &gsw_port0 {
-	label = "wan";
+	label = "eth3";
+	local-mac-address = [02 00 00 b3 14 43];
 };
 
 &gsw_phy1 {
@@ -202,7 +203,8 @@ &gsw_phy1_led0 {
 };
 
 &gsw_port1 {
-	label = "lan1";
+	label = "eth4";

This file has been truncated. show original

I assume you simply aren’t using the SFP+ slots?

@frank-w How are you handling this when you run regular Linux on these? Also, as someone who isn’t an expert at reading device tree files, where would I put the MAC addresses if I need to patch the dtsi and dts files? It’s not immediately clear to me since the definitions of the switched RJ45 ports and the SFP+ slots look quite different.

frank-w · January 9, 2026, 8:18pm

Sfp slots on R4 are gmac1+gmac2 nodes…just add this property there. Such setting has to be done at board level (Bpi-r4 dtsi for wan sfp and for lan the dts)