Banana Pi BPI-R4 Wifi 7 router board with MediaTek MT7988A (Filogic 880),4G RAM and 8G eMMC

Anyone understand this?

2x 10Gbe SFP slot (option 1x 10Gbe SFP and 1x SOC embedded 2.5Gbe PHY. NOTE: Need to modify hardware)

there is a hardware-version with 2x10G sfp-slot and one with 1x10G sfp-slot and second is replaced by a fixed 2.5G Phy+POE

See images in first post…

1 Like

Thanks. Sorry about the double posts…

Hi , I’ve bought one to play with, i’ll be more interested if there would be four 2,5gig ports on switch. I have also place for R5 with two 25 gig sfp28 ports .

I have to ask though, what is the envisioned antenna design layout?

My crude imagination gave me this christmas-tree-looking thing. :smiley: image

1 Like

i tried to build GitHub - BPI-SINOVOIP/BPI-R4-OPENWRT-V21.02 but failed because Schwerwiegend: Repository ‘https://git01.mediatek.com/openwrt/feeds/mtkopenwrt-feeds/’ nicht gefunden (->not found) failed. The scripts feeds install -a then failed of course too. Where is the source to build openwrt for the R4?

This is clearly a bug guys, please fix that! The correct repo url should be “git clone https://git01.mediatek.com/openwrt/feeds/mtk-openwrt-feeds” but in your repo you use git clone https://git01.mediatek.com/openwrt/feeds/mtkopenwrt-feeds

Another thing i just noticed: WARNING: Makefile ‘package/feeds/mtk_openwrt_feed/flowtable/Makefile’ has a dependency on ‘kmod-nf-flow-netlink’, which does not exist Why is that? Where is that file? And regarding openwrt version: this is so old, its not even on the openwrt page anymore. Please update at least to the “old stable” version which is 22.03

While trying to build the image, i get this error, which makes me feel now more and more bad about the decision to buy this piece of hardware:

Scanning dependencies of target opkg-cl
make[6]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd'
make[6]: Entering directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd'
[ 98%] Building C object src/CMakeFiles/opkg-cl.dir/opkg-cl.c.o
[100%] Linking C executable opkg-cl
make[6]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd'
[100%] Built target opkg-cl
make[5]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd'
make[4]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd'
touch /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd/.built
install -m0755 /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd/src/opkg-cl /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/host/bin/opkg
mkdir -p /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/hostpkg/stamp
touch /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/opkg-2021-06-13-1bf042dd/.built
touch /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/hostpkg/stamp/.opkg_installed
make[3]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/package/system/opkg'
time: package/system/opkg/host-compile#2.62#0.77#3.67
make[2]: *** No rule to make target 'package/cryptsetup/host/compile', needed by 'package/compile'.  Stop.
make[2]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make[1]: *** [package/Makefile:116: /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make: *** [/home/oli/BPI-R4-OPENWRT-V21.02/include/toplevel.mk:230: world] Fehler 2
  1. the MTK vendor SDK only support OpenWRT-21.02
  2. because we upload the code into github, So we remove all folder’s “.git”, please don’t run any update script.
  3. you clone the BSP from github again, then directly run “make V=s -j2”

thanks, but did you know that: OpenWrt 21.02 has been declared End-of-Support in May 2023 and is no longer maintained or actively supported. ? So there are no security updates etc. anymore, is there any ETA when 22.x or better 23.x is supported? Its like releasing hardware that runs on windows. People would expect windows 10 or above. And when asked, its for Windows XP :wink:

i checked out the source, did nothing else and started a make with 2 threads and debug enabled, thats the output:

make[4]: Entering directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/dtc-1.6.0'
set -e; echo '  CHK version_gen.h'; mkdir -p ./;        (echo "#define DTC_VERSION \"DTC 1.6.0-g8f0689a2\""; ) < Makefile > version_gen.h.tmp; if [ -r version_gen.h ] && cmp -s version_gen.h version_gen.h.tmp; then rm -f version_gen.h.tmp; else echo '   UPD version_gen.h'; mv -f version_gen.h.tmp version_gen.h; fi;
        CHK version_gen.h
cc -I libfdt -I . -DFDT_ASSUME_MASK=0 -DNO_VALGRIND -g -Os -fPIC -Werror -Wall -Wpointer-arith -Wcast-qual -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow  -DNO_YAML -o fdtdump.o -c fdtdump.c
In file included from fdtdump.c:14:
In function 'fdt_set_magic',
    inlined from 'main' at fdtdump.c:220:3:
libfdt/libfdt.h:251:28: error: array subscript 'struct fdt_header[0]' is partly outside array bounds of 'unsigned char[4]' [-Werror=array-bounds=]
  251 |                 fdth->name = cpu_to_fdt32(val); \
      |                 ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
libfdt/libfdt.h:253:1: note: in expansion of macro 'fdt_set_hdr_'
  253 | fdt_set_hdr_(magic);
      | ^~~~~~~~~~~~
fdtdump.c: In function 'main':
fdtdump.c:216:31: note: object 'smagic' of size 4
  216 |                 unsigned char smagic[FDT_MAGIC_SIZE];
      |                               ^~~~~~
cc1: all warnings being treated as errors
make[4]: *** [Makefile:345: fdtdump.o] Error 1
make[4]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/dtc-1.6.0'
make[3]: *** [Makefile:105: /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/hostpkg/dtc-1.6.0/.built] Error 2
make[3]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/package/utils/dtc'
time: package/utils/dtc/host-compile#0.16#0.08#0.19
    ERROR: package/utils/dtc [host] failed to build.
make[2]: *** [package/Makefile:120: package/utils/dtc/host/compile] Error 1
make[2]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make[1]: *** [package/Makefile:116: /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make[1]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make: *** [/home/oli/BPI-R4-OPENWRT-V21.02/include/toplevel.mk:230: world] Fehler 2

unfortunately i cant ask in #openwrt as that release is not supported anymore. i could imagine that another glibc (version) is required to build, which does not produce such warning. and this warning is because of -Werror interpreted as error and then aborts. i use debian trixie.

upgrading dtc from 1.6.0 to 1.7.0 made it possible to nearly create a image. at the end it failed with:

tex-a53_musl/image/fip_sd.bin /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7988/BPI-R4-SD-kernel.bin /home/oli/BPI-R4-OPENWRT-V21.02/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7988/root.squashfs
+ '[' 6 -eq 6 ']'
+ OUTPUT_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/bin/targets/mediatek/mt7988/mtk-bpi-r4-SD.img
+ GPT_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/image/GPT_SD
+ BL2_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/image/bl2_sd.img
+ FIP_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/image/fip_sd.bin
+ KERNEL_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7988/BPI-R4-SD-kernel.bin
+ ROOTFS_FILE=/home/oli/BPI-R4-OPENWRT-V21.02/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7988/root.squashfs
+ BS=512
+ GPT_OFFSET=0
+ BL2_OFFSET=1024
+ FIP_OFFSET=17408
+ KERNEL_OFFSET=21504
+ ROOTFS_OFFSET=87040
+ dd bs=512 if=/home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/image/GPT_SD of=/home/oli/BPI-R4-OPENWRT-V21.02/bin/targets/mediatek/mt7988/mtk-bpi-r4-SD.img seek=0
dd: failed to open '/home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/image/GPT_SD': No such file or directory
make[5]: *** [Makefile:193: install-images] Error 1
make[5]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/target/linux/mediatek/image'
make[4]: *** [Makefile:18: install] Error 2
make[4]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/target/linux/mediatek'
make[3]: *** [Makefile:11: install] Error 2
make[3]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02/target/linux'
time: target/linux/install#562.84#92.83#103.58
    ERROR: target/linux failed to build.
make[2]: *** [target/Makefile:25: target/linux/install] Error 1
make[2]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make[1]: *** [target/Makefile:19: /home/oli/BPI-R4-OPENWRT-V21.02/staging_dir/target-aarch64_cortex-a53_musl/stamp/.target_install] Error 2
make[1]: Leaving directory '/home/oli/BPI-R4-OPENWRT-V21.02'
make: *** [/home/oli/BPI-R4-OPENWRT-V21.02/include/toplevel.mk:230: world] Fehler 2

You will have official support in OpenWrt’s snapshots (and maybe even a backport to 23.05, but I can’t promise) within the next week. Other then Windows which allows hardware companies to develop drivers behind closed door and have them work with the most recent version of the OS is something nearly impossible to achieve in the Free Open Source Software world.

OpenWrt requires changes to be maintainable, and for hardware drivers that means they need to be pushed upstream to the Linux kernel (or at least be in a shape that would allow to send them upstream and start the discussion), as otherwise it will be a lot of work to keep adapting the drivers for newer kernel versions in future (which is what you can see now when trying to build anything newer than Linux 5.4…).

The patchset on top of OpenWrt 21.02 MediaTek provides for the boards is useful as a reference, to build commercial firmware or validate hardware functionality, however, it is certainly not in a shape to be sent upstream as-is – I’ve been working on extracting the necessary changes, cleaning them up and sending them upstream together with others who were provided early versions of the BPI-R4.

MediaTek and BPi have made quite some effort to get support for this new SoC landed in Linux ahead of time (which is better than what everyone else in the market is doing), however, 6 months are still not a a terrible lot of time when it comes to discuss complex driver changes with busy upstream maintainers, hence this process is still ongoing.

4 Likes

that would be great, then i stop my approach now with self compiling. Maybe it would make sense to write that information somewhere, because i thought its now for openwrt 21.x and stays there. If i would have knew that there is some WIP for main/master openwrt, i would never touched anything :slight_smile: Thanks for your effort! And yes, any effort for mainline is very very appreciated. Unfortunately, my experience with MTK is bad bad bad when it comes to mainline/opensource. So i am looking forward for your releases, thanks!

1 Like

I’m confused, are the cages SFP or SFP+, I thought the two were not interoperable?

Will they support these GPON SFP transceivers:

If it can run those optics, I would rather buy an R4 instead of an R3 for Gigabit WAN with SQM. When might enclosures for the R4 start to be available?

R4 is SFP+ and downwards compatible to SFP due to pcs switch (mac can do sgmii to support the lower speeds).

Compatibility should be same as R3 + sfp+

2 Likes

Very interesting board, how stable is the firmware? Is the board finalized in terms of hardware? Many questions, little answers so far.

Can it handle 10gbit with SFP+ transceiver bidirectional?

it supports 2.5Gbps transceivers ??

Yes it does. SFP(+) modules supporting either Cisco SGMII, 1000Base-X, 2500Base-X, 5GBase-R, 10GBase-R or USXGMII will work fine.

2 Likes

What about 10G BASE-T modules???

10GBase-T modules usually use either 10GBase-R (ie. pretending to be a fiber module) or USXGMII (in case the built-in PHY can be discovered by Linux). I’ve tried a bunch of 10G RJ-45 modules and they all worked fine (most with either Marvell or AQR PHY discovered and in USXGMII mode, one 6Com module I got here has broken EEPROM but works in 10GBase-R mode).

2 Likes

Thanks, that makes it clear and wow, I have some Qs:

  1. Can serial DCD be exported to a GPIO pin from one of the UARTs?
  2. How much of a ballpark performance boost might SQM see on the A73 over the A53?
  3. Will it support a 10G SFP in both or max is 10G + 2.5G concurrently? What is US下GMII?
  4. I won’t be using wifi on this, are the bottom two mpcie slots usable for standard mpcie / usb modules?
  1. Sfp slot are connected using i2c (for data communication with sfp eeprom to detect its type phy etc) and some fixed gpio to map states in linux like rx-los moddef0 etc. Afaik it is not possible to expose additional gpio from sfp.

  2. not sure about this…you can look for public benchmarks

  3. it should support 2x10G+1x4g (switch) simultanously if rss+lro implemented correctly and enabled. Usxgmii is a hw mode / transmission protocol used to connect the 2 SFP-cages to SoC

  4. basicly it should work,but take care of sw4 which switches 12v to some pins of pcie connector (may brick some cards). Make sure it is switched off before powering the board with other cards inserted