Brume 3 cannot be merged into the mainline because the switch driver is not open source
Will Flint 4 face this issue?
Losing mainline support means fewer out of the box packages.
Thanks
2 Likes
It will mostly be open like the Flint series always has.
That is the problem, they never introduced a shared port design for a Flint model, hence why this realtek driver is considered different and not very common.
So far the models Marble, Brume3 and now Flint 4 are the ones where two ports are basically soldered as a single port rather than invidual.
I wish to see some transparancy about this too, because it can feel misleading, if it is the case, and you also don't know about the more ports if they are also soldered like this because it is the first time I see a Flint model with so many ports.
I don't want to spread FUD, that is not my intention only asking for reassurance if it would be a good pick.
1 Like
When you say soldered I’m not following what you mean?
The SoC will always only have a limited number of ‘ports’ that can be broken out, so when more physical ports are needed you need a switch. This can either be an external one you supply yourself and a router only has two or 3 ports, or it’s a switch chip integrated into the router to give more LAN ports. The latter being how the vast majority of router LAN ports function across most vendors this is not uncommon.
Some devices out there only even have a single ‘port’ to the SoC and all of the physical ports you plug into on the device are on a switch chip, and VLANs internally used to create LAN/WAN physical ports on the device.
Neither of these is related to a choice how the port on the SoC is soldered, without the switch chips the routers just wouldn’t be able to have as many ports.
Nothing inherently different about what the Brume 3 or Flint 4 is doing, but if they use brand new Realtek parts for this, like the Bruce 3 does, then it is not especially uncommon for support to take a long time to make it upstream into the Linux kernel and vanilla OpenWRT.
I mean that the two traces become one trace on the board, which cut costs instead of having invidual ports with each their own trace to the switch, the switch does not see two ports but one.
Like on the brume3 you can see that the DSA device is eth0 and the second port eth0.1.
It will be such design for wan how the back illustrated it on the flint 4 between sfp wan and the 10gbe ethernet wan.
It is different, if the two ports are used concurently, they cannot reach the max advertised speeds because they are shared as a single port, but if only one of them is used you get the advertised speed.
Therefor also complicates things more with DSA and vlans in general, but it can be done just like how people used raspberry pis which mean wan gets a vlan and lan gets a vlan on the same dsa device and this way the ports are invidualised.
However I also readed the Brume 3 PR and it got dropped silenty after the driver was requested, I don't know the true reason why that driver is not given and got halted other than assume it may be something not common in routers or even something SDK only as some exclusivity, or it did not reach linux kernel yet.
These are just assumptions not facts.
But the sudden silence is something to worry about also how it goes with that PR, and I think it is a very legitimate question OP has, if you as consumer is interested in running vanilla openwrt and nothing else, it would really important to know if those drivers can be in OpenWrt.
1 Like
I don’t see the issue for majority of uses.
The switch has 3x 2.5G ports, two present out as physical RJ45 and can get full line rate between them, the third is connected on the PCB upstream to a 2.5G port on the SoC which only has 2.5G WAN.
Traffic between the LAN ports doesn’t touch the SoC in normal usage, it only passes on that port to reach the WAN port which has a PHY on the SoC directly. This is the primary design as its markets as 2x LAN ports.
Scenario 2 where you use one of the LAN ports as WAN, then you share the uplink to the SoC, but a single 2.5G LAN client can not pull 5Gbps from two WAN ports anyway, so this limitation isn’t really a limitation if this is a true 2nd internet link as the LAN port only needs max 2.5Gbps.
Where the uplink speed might be a problem, is trying to do WAN1 - WAN2 traffic for some reason, e.g. trying to firewall between ports WAN, LAN, DMZ etc then this could be congested, but in this scenario then this probably was not the correct device for that user as its not marketed as having 2x true WAN ports, it has 2x LAN ports on a switch, which will always share a single uplink to the SoC ‘router’.
Flint 4 we know has 10G combo WAN which is likely from the SoC, and then we can speculate the LAN ports could use a second 10G ‘port’ on the SoC perhaps towards the switch, so may not have the same limitation. Seems unlikely the uplink to the LAN switch chip would be less than 10Gbps here as that would cripple the 10G WAN port, so this shared uplink is likely not a problem for Flint 4 even with multiple 2.5G additional ‘WAN’ / routed ports
My point was purely aimed with this wan design that this very well contribute to the same problem Brume 3 PR has, that it requires some kind of special driver to deal with offloading with such design choice between these two ports, this design is not common on routers.
Also there is a chance people don't have to agree, you can technically just turn the 10gb ethernet wan to lan for NAS use, there are already two issues here I tried to point out which really deserve to get more clarity 
1 Like
It’s not special, it just uses a new Realtek switch chip thats not supported in upstream Linux yet. This is not related to offloading. It's a variant of the existing family of switch chips and will get support eventually. The design to incorporate switch chips is common, this chip just isn’t supported yet so it doesn’t work.
For 99% off routers on the shelf this isn’t a problem, as generally vendors will use the MTK SDK, like GL.inet do, so they can get official support with issues and get bug fixes directly from MTK. Open source support will come from the community eventually, it just takes longer and isn’t likely a priority for MTK/Realtek themselves.
1 Like
I agree, but hopefully it will not be delayed for Flint 4.
Rightly said, openwrt mainstream support should arrive but will take longer than usual.