Banana Pi official Router UI design

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

we now design a Banana Pi Office Router UI, Base on OpenWrt . any good idea?

#openwrt #router #wifi #router #bananapi #opensource #Mediatek #OEM #ODM

1 Like
2

instead of writing another UI (we already have a bunch of them with openwrt), why not focus the time and effort on things that people really need like the firmware files for the switch, be19 etc.?

4 Likes
3

! standing ovation !

1 Like
4

BE14 without too much noise?

1 Like
5

Any news on the MaxLinear switch chip firmware?

6

I agree. Stick to OpenWRT and extend hardware support via driver development and bug fixes. Open-source any closed binary blobs too, if possible.

One reason I switched from GL-Inet devices to the OpenWRT One made by BPi is that I wanted pure OpenWRT and not GL-Inet’s additions/modifications.

1 Like
7

The BPI‑R4 PRO community does not need another web UI. We already have LuCI and plenty of alternatives. What blocks real-world usage are fundamentals that still aren’t delivered officially in a reproducible way.

  1. Switch/PHY (MaxLinear) firmware + clear distribution terms Without the required firmware and clear documentation (what can be redistributed, what is NDA-restricted, where to obtain it), the switch remains a bottleneck. This should be treated as priority #1, ahead of cosmetic UI work.

  2. Upstream drivers/DSA work + official reproducible builds Right now the platform depends too heavily on community forks and community builds. If this device is meant to be taken seriously:

The important work (drivers/DSA/quirks) should be upstreamed, with a clear status for anything that cannot be upstreamed. There should be an official reproducible build tree and public CI producing regularly updated reference images with verifiable commits/artifacts. 3) Stability/QA focus instead of announcements There are recurring reports of low-level issues (INA2xx I2C errors, MaxLinear MMD write failures, MT7996 probe timeouts). Even if some units are defective, the repeated pattern suggests QA/troubleshooting/mitigations need improvement. Announcing “a new UI” while this persists sends the wrong message.

  1. A real roadmap (dates) “Soon” is not a roadmap. At minimum, publish:

calibration start/end shielding/heatsink finalization first production batch / approximate first sale date This is no longer a cheap experiment: pricing has escalated from ~€150 to ~€325. Without a stable baseline, official CI builds, and at least a minimal schedule, you’re effectively asking users to pay a premium and also act as QA.

  1. If there are NDA constraints, say so clearly But then compensate with:

regularly updated reference images (CI), an explicit list of what is open vs closed, clear instructions for reproducible builds.

2 Likes
8

your ideas are very great. we will follow them and make more better.

1 Like