Target bananapi_bpi-r4-common

Daniel Golle daniel at makrotopia.org
Fri Jun 13 16:01:26 PDT 2025


On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via openwrt-devel wrote:
> 
> Should the BPi-R4 be more richly provisioned?  It's got 4 or 8GB of DRAM so it's hardly a "skinny" platform.

I would leave that to the user and keep the default image with just what
is necessary. Diverging and creating "rich" images for specific devices
imho opens a can of worms which will require continous maintainance.
How would we decide which packages to include? How would we draw the line
for each and every board whether in our opinion the amount of flash and
ram is enough for any particular feature, and why some features are
present while others aren't?

Of course, the community is free to create and share such images, and for
many devices (incl. the R4) there are community-made images, some built
from source, some made with the ImageBuilder or using online tools like
the OpenWrt Firmware Selector and asu.

However, we would not be able to maintain support for 2k devices if we
would also have to maintain an individual package selection for all
those devices which goes beyond offering minimal hardware support.

> 
> Also, why are two different targets required for the same hardware?  I get that the "10G SFP WAN" and "2.5G/10G WAN" ports are combo so that only one PHY can be in use at a time, but why can't a single target support both and just detect which is connected?

There are two different boards variants:
- 2x SFP+ cages and 4x 1GE RJ-45
- 1x SFP+ cage, 1x 2.5GE RJ-45 and 4x 1GE RJ-45

The 2.5GE PHY is built-into the SoC and apart from being populated
differently the boards are identical, there is no way to detect in
software which variant we are dealing with. SinoVoip equips the R4 with
some I2C EEPROMs which would be perfectly suitable to be used to indicate
the board variant or even contain a factory-assigned MAC address. Sadly
they come all empty.

Hence, as they are two distinct board variants and there is no way to
detect the variant in software, we need two images.

That's different from a "combo port" on devices where both, SFP cage and
RJ-45 MDI are physically present but only one of them can be used at a
time. On such boards the presence indicator (MODDEF0) of the SFP cage can
be used to switch between the SFP cage and the RJ-45 port (which also
isn't supported yet by vanilla Linux or OpenWrt, but it's still a
different story and will be supported in future)

> 
> Do we want to auto-select more packages like (say) mwan3 for instance?  I think we have enough memory that we could include it and if it's not used it's not the end of the world.

Apart from the argument above, it also simply isn't possible to include
packages from the packages feed in images created by the phase1
buildbot...

> 
> I'd include:
> 
> lldpd
> curl
> 6in4 (or 6to4 or both?)
> avahi
> collectd
> firewall3 (or firewall4)
> hwclock
> iftop
> ip-full
> iptasn & iptgeoip
> ntp*
> snmp
> *swan
> xfrm
> zoneinfo
> 
> But that's me.  I'd rather have it and not need it than need it and not have it.
> 
> Are there other BPi-R4 users that want to start a thread?

There are some threads on the forum you may want to join.
> 
> Oh, one other question... I see there's a FPC connector for an extra LAN port (not clear if it's switched or not). Has anyone used that and what's the cable to make that work? Is there a knock-out machined into the case of an extra port?  And the diagram here:
> 
> https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro

That's the R4 Pro, it's again a different board which isn't yet
publicly available.

> 
> Says "PoE Module RT5400" but I can't find any info on that.  There's this:
> 
> https://www.amazon.com/youyeetoo-BPI-RT5400-Isolation-BPI-F2P-BPI-WiFi/dp/B0D61ZKFL6
> 
> But it doesn't include the BPi-R4 in the description.  Is it PD (my guess) or PI (for driving an external device)?

It's PD, and typically SinoVoip/BPi will make boards which include the
PoE module, ie. you can order the board with or without PoE
functionality.




More information about the openwrt-devel mailing list