Of course, and it's what we are doing. Downstream patches to upstream drivers no longer get accepted without X-Patchwork-Id header which proofs that they have at least been submitted upstream. (Waiting for them to trickle down is not an option. The hardware would be years old by the time the patches would be part of a linux-stable release. We've discussed this already.). However, trying to force volunteer contributors of standalone niche-drivers to do lots of extra work which benefits neither them nor the project they actually want to contribute to (OpenWrt) directly is difficult. In many cases you'd lose them as contributors if you'd try to force them.
And OpenWrt users care about having fast IPSec on MT7621. They don't care about comments in the code, Linux code style, YAML dt-bindings, documentation, ...
Plus, in that case, the burden of having the driver downstream is maintainable (that's what I meant by "little value for OpenWrt of having this upstream" -- it's not like we have to work lots on that EIP-93 driver for each kernel version bump -- worst case parts of the patch affecting Makefile or Kconfig have to be fixed, but usually hardly more than that).
Apart from all that, looking at our overall record as OpenWrt project I think we have contributed much more to the Linux Kernel than any other downstream embedded Linux distribution, most of them being developed and distributed entirely behind closed doors. OE/Yocto, for example, seems to be tailored to conveniently "layer" (as they call it) ugly, downstream, semi-proprietary components with (usually outdated) vanilla Linux kernels. Hence there is little to no incentive to work with upstream at all. A Linux Foundation project...
as I see, you pointed the Mediatek feed, may I ask if you recommend to use it? I mean, I saw the procedure on Frank site and I'm wondering if is it mainly for advanced users?
In other words, is it safe to use that feed or should avoid, due it requires more knowledge.
EDIT: The feed is for version 21.02 so it will be not applied on current main branch (IIUC). Forget about the question
I just saw a couple of new patch sets posted by MediaTek developers to this 21.02 feed, as mentioned by someone on the R4 big thread on BPI forum.
So I would speculate the process works like this:
For the time being all development on R4 done by MediaTek will be on version 21.02. They probably will rebase to a new version in 3 to 5 yrs if FiLogic 880 sells really well e.g. like MT7621
OpenWrt developers will pick up patches from the feed, and port them to latest OpenWrt version. While doing so, upstream most of all changes to the mainline Linux.
So if someone is interested in testing, possessing development skills, it doesn't hurt you to pick up some new changes from the feed and test. Then perhaps submit a pull request to OpenWrt git (?). Sort of becoming like a OpenWrt developer too.
--
BTW, I also saw on the BPI forum someone seems to get the PWM fan working
I don't plan to install a NVMe SSD in the near future. For ppl intended to do so, the good news is that boot from NVMe SSD (in the m.2 slot on R4) was recently enabled as per this post in BPI forum.
In case, people worry pcie2 slot has to be disabled for this new feat to work. As I understand it, pcie2 is only briefly disabled for a few seconds during u-boot in control. I believe things go back to normal as the kernel takes over.
Let's not forget there is always the MediaTek's OpenWrt V21.02 with full support of R4 hardware features.
It's an excellent alternative for ppl waiting stock OpenWrt full support which may take many more months if not years. The drivers for TOPS / EIP-197 / QDMA (HW QoS) could be hard to have open source versions in case MediaTek doesn't proactively contribute.
It seems ppl commonly despise proprietary firmware. I agree because vendors usually abandon their firmware shortly after hardware launch. However, as a short/medium term alternative, it's fine. That's also my Plan B.
My plan was to run stock OpenWrt on R4. And one LXC container to isolate 'server applications' from OpenWrt. Lately I've been looking at OpenWrt packages. I conclude that I probably would be better off by not running OpenWrt's application packages inside the container. Instead, I'm pondering to install and run ArchLinux user space so that I could stay at the cutting edge on applications and minimise dependency on stock OpenWrt's release schedule.
Just some thought for potential R4 owners. And nothing concrete for myself yet too.
2x10G SFP + 4x2.5G would be great/ideal.
I haven't found a router for OpenWrt with 6x 2.5G port yet. The GL-MT6000 with 6x 2.5G ports would be great, sadly it only has 2x (1xWAN + 1x LAN).
Not possible with any MediaTek hardware as of today. You only got 2x 10G interfaces of the SoC and either another 2500Base-X/SGMII or the built-in 4x 1GE switch on MT7988 and that's the best you can buy for now. It will have to be another SoC then, Marvell OcteonTX or NXP Layerscape, for example.
Sure, as switch. Layer-2 web-managed at best, sure.
But not something which could serve 4x 2.5G client at full speed, have another 10G port for NAS and a 10G port for Internet uplink, doing NAT-routing and taking of WiFi at the same time...
With the R4 you have most of that, but not all. You could either use one of the 10G interface to connect a downstream managed switch (using a DAC cable) for several 2.5G clients -- or use that port to connect a NAS or server. But not both, given that you'd want the other 10G port for your Internet uplink...
You mentioned about router with 6x2.5Gbit, now you also want to have 10g ports there and wifi and all kind of magic. Can be hard;) In this case you can take n100 with 6 ports and with 2x m2 slots- still not sure if you will be able to have everything you want- wifi will be the biggest challenge.
[Aliexpress N100 2x10g 4x2.5]
Luckily for me I do not have such requirements and Banana PI R4 together with 5g modem is perfect for me- anyway for wifi I have APs and for LTE/5G I really do not need anything faster than 1g... Maybe in future.
Those AliExpress N100 dual 10G + quad 2.5G are not possible to run all ports at full speed (the PCI-E slot is x4 however the bundled Intel 10G dual port chipset is exactly same as X520-DA2 which needs x8 slot)
Meeh... Why do all people look for Swisstool-army-knifes?
You will always get the best performance/lowest power consumption +most often decent pricing, if you look for specialists instead of all-rounders..
For this 2,5GBE-thing: get a decent layer-2-webmanaged switch with enough ports and SFP+ uplink to this nice router and you are fine. Build yourself an all-in-one virtualized x86-machine with 2-4 NICs (-> 4 to 8xSFP+ + 4 to 8x2,5/5/10GBE) and you will create a monster. I've had it and only can advice to have a modular setup infrastructure. That way I can (as soon as BPI-R4 is fully working) upgrade seamlessly from 2,5GBE access points (Turris Omnia 2016 generation) as I installed an SFP+ infrastructure right from the start.
Plus this discussion is off topic, so please concentrate on the R4
I just got an R4 and tried to boot Snapshot release but on the serial console nothing happens when I power it on. Booting the builtin version of Sinnovoips OpenWrt compatible release works though.
I even tried to build an image myself using the imagebuilder but with the same result. The wiki page states that a snapshot after https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f16dc4b42fb265affb2298e815a7ce0a13d60da6 would work.
Edit: It looks like it has something to do with the power supply. The requirements are huge.
Good news on the official galvanised aluminium case.
According to the pre-order info from a single 3rd party aliexpress seller, the case will be released on Apr 30. So two more weeks to go.
Official pricing unknown at the moment. The 3rd party's pre-order price is on the high-side. I suspect it's used to test the market for setting the final price.
)