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. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
