I would like to share this project to the OpenWrt community to collect feedback.
Is such a project interesting to the OpenWrt community?
I'm using the RTL8367S switch chip. The rtl8365mb DSA driver has no hardware offloading and VLAN support . But the old rtl8367b swconfig driver supports it. Are they any plans to migrate all rtl8367b features to rtl8365mb? Or did I miss something?
Generally speaking, this is a cool project. Thanks for sharing it.
From a practical perspective, though (and this is my opinion only, I can't speak for others), I feel that the device is not all that useful unless it is considerably cheaper (compete cost) than a basic 5-port L2 managed switch. That's pretty hard to achieve, though -- you can get entry level 5 port managed switches in the range of $25-$30 USD. My thinking is that this won't be able to offer much (if anything) more that a commercially available switch can provide, except maybe the fact that you developed it with OpenWrt in mind.
I have no idea how hard it would be, but if you were able to do 2.5G rather than gigabyte speed, that could make it a lore more interesting with regards to what @psherman was saying
IMO this project would be much more interesting if it had more than 4 ports. If I only needed 4 ports, I could already use almost any router with OpenWrt support and configure it as a switch. If you can follow up with an 8 or 10 port switch, or even an 8xRJ-45 + 2xSFP switch, it would certainly get my attention.
I realize you're using a Pi Zero for cost reasons, but this kind of thing is begging for a Compute Module 4 or Compute Module 5. Both of these are designed to be integrated into custom boards like yourself, and have native 1 GB Ethernet so you can dispense with the ENC28J60 and get much better packet transfer speeds.
If you go that route, you might as well attach something like a RTL8111 to the CM4/5's PCIe and get an additional 1 GB Ethernet port for a total of 5 ports. Now you have a very competent OpenWrt router board that comes with an on-board managed switch. This would already be a very significant upgrade over DFRobot's router board, which only has 2 ports.
@psherman Speaking only cost vise you are right. I tried to keep the costs as low as possible, but $25-$30 is only possible with mass production in huge quantities > 100k p.a.
Here is my cost breakdown for two units (PCBA):
Article
Cost/unit
Parts
$13.44
PCB
$1.40
Production
$14.82
Shipping & customs
$13.88
Raspberry Pi Zero
$10.00
Total
$53.54
But besides the costs, commercial switches don't have an open source firmware because they are usually built with a switch chip vendor SDKs. I personally could not find commercial managed switches with an open source firmware. I course I know the Realtek based RTL83xx/RTL93xx switches (I have two GS1900-8) but the integrated flash (16MB/32MB) is too low for the future. Futuremore there is no official vendor support.
@axx To have 2.5G would be really nice but we have to find a switch chip with 1. Linux DSA support, 2. public available datasheets (for an open source project it is not acceptable to sign NDAs) and 3. on stock at JLCPCB. Definitely, such a switch would be much more expensive than the presented 4-port switch. Here the main chip is a RTL8367S which costs only ~$2.5. During my market research about switch chips, I didn't see a low port 2.5G switch chip with integrated PHYs. To use external PHYs increases the costs a lot.
@elbertmai You are absolutely correct. The current design itself has no unique selling point (besides the HW is open source). But it is a starting point to learn how to build an open source managed switch. I used a 5 port switch chip to keep the costs low because I'm using my private money. After I got the first boards, I was really surprised that the initial layout and PCBA is working basically. I expected to do a few iterations until the switch is working. Increasing the port count is possible but we need to find a switch chip with DSA support (incl. hardware offloading and VLAN support). See also my answer to @axx above.
In my mind is also a model with CM module usage. But again, I wanted to have a working switch first. If you know that a hardware design is working, it is not a difficult task to build model variations, like replacing the Zero by a CM. Currently, I realized that RTL8367S DSA support is not usable for managed switches (no HW offloading and VLAN support), currently.
Thanks also for your idea with the RTL8111 PCIe to Ethernet chip. Actually, I did some experiments with the MCUZONE MPRG4 board. It has a RTL8111 PCIe Ethernet interface which connects to a RTL8367N switch chip. I modified the board to control the RTL8367N via SMI from the Raspberry Pi 5. Basically it was working but not with the RTL8111. I had to use the Raspberry Pi 5 on-board Ethernet port. The DSA configuration is done via the device tree and I could not find how to configure the RTL8111 via the device tree because the chips uses PCIe. If somebody has a device tree example I would love to try it again.
This chip also has 2x SGMII interfaces which can be used for SFP transceivers. But I personally don't have experience with SFPs, so I would need a schematic for reference. And it needs to be checked if the rtl8365mb driver supports SFP the SGMII ports.
Because of the DSA device tree configuration, we have to use the internal Ethernet interface to connect to the switch chip. As far as I see it is not possible to use a Ethernet interface connected via USB or PCIe.
The additional RTL8111H-CG can be used as WAN interface because all traffic has to be routed through the CPU. So you will have a switch-router .
Cost vise this hardware would increase the PCBA costs around $30 (guessing) compared to the 4-port switch without the Raspberry Pi.
But before we will create such a hardware it has to be clarified how to enable hardware offloading and VLAN support which is not supported by the rtl8365mb driver currently. Without hardware offloading and VLAN this switch would be not really usable. Also, rapid spanning tree (STP) support would be really nice.
Theoretically possible is also to use the RTL8380M-VB-CG chip. This chip is supported by OpenWrt but only via the internal MIPS processor with the 32 MB flash limit. Because 32 MB is too low for the future (my personal opinion) this chips needs to be connected to the Raspberry Pi. The RTL8380M has an I2C interface for that, but I don't know this interface is already supported by the drivers. Maybe @svanheule has more details on that?
Up front, I want to say that I encourage and applaud the effort you are putting into this -- I think it's great to make open source hardware and I love that it is being built with OpenWrt as the firmware environment to run the device. So, my comments are really intended to serve as combination of a reality-check and an opportunity to think more about what you can do that would be a unique value proposition...
The latest architecture you have suggested still seems like something I could get off the shelf (or nearly so)... specifically, at 4 + 1 ports, we can use generally any OpenWrt compatible router. If we use the 6 + 1 port model as described, that does narrow the field quite a bit, but the GL-MT6000 isn't far off (it has 6 total ports, 2x 2.5G, 4x 1G). Likewise, if I'm really just looking for a managed switch, I can get an 8-port gigabit model starting from ~$25 USD and ranging up to $75 USD.
Yes, very few of the off the shelf gigabit managed switches offer an open source firmware experience (many of them kinda suck with respect to the firmware/UI), but they do work. While there are certainly some critical features that switches need to perform, it's generally much more straightforward and/or 'passive'/hands-off relative to the router. It's often a set-and-forget device, and doesn't really require the extensibility that can be achieved with OpenWrt.
Coming back to the of where you can add value relative to existing options...
A L3 switch would be quite interesting. Of course, once you're getting into L3 territory, you are functionally talking about a router in many situations. That said, L3 switches are a thing, but are typically quite expensive. A less expensive and open source L3 switch would be something very unique and attractive.
Or... a good 2.5G or better yet 10G switch that is cheap and flexibile... that would also be a nice option.
I'm coming from the industrial Ethernet world where 100 MBit/s is still the standard and slowly moving to 1G and to 10MBit/s (10Base-T1L, 10Base-T1S). Most of the switches inside industrial machines are unmanaged or L2 managed switches.
Ok, you are asking for 2.5G or 10G L3 switches - cool! I expect you mean copper only, right?
Let me think a bit ... Maybe something could be possible with Microchips LAN969x family. But such a switch is definitely much more expensive compared the Realtek based gigabit switch. The smallest LAN9694 cost around $40 and you need to add the PHYs externally. Honestly, I'm not really optimistic that it is possible for me to build such a hardware without Microchips help and only with public available information in my free time. On the other hand, the LAN969x Linux support is quite good because Microchips maintains their own buildroot based Linux, and they are upstreaming the driver into the mainline kernel. When we are not using the internal CPU cores and connecting the LAN969x via PCIe to the Raspberry Pi hardware and software are a little bit easier, at least for the first steps. But the downsides are that the reference schematic, board design files and datasheets are only available when signing a NDA. And with a signed NDA you cannot build an open source hardware, I think.
But even when we have some kind of working open source 2.5G or 10G hardware, who is doing all the L3 software development in OpenWrt (HW offloading, TSN, M/RSTP, QoS (TOS,COS), VLAN, HSR/PRP, MRP, netconf/yang)?
The RTL8380M has a SPI port that can be used to communicate with the chip, but I don't know of anyone who's ever used that. I only know of a RTL9301-based switch where two switch chips are used, but I have no idea about the format of the control protocol.
Not necessarily, it depends on the terms of the NDA. And in all honesty, Microchip is really weird about them. For example, you can easily find the complete datasheet for ATECC508A online with your favorite search engine. But not for its successor ATECC608A, because that one is under NDA. Except the NDA is completely pointless because ATECC608A is almost identical to ATECC508A and Microchip themselves publish a whole C library for interfacing with both of them!
Going back to my first post. For a hobby project, usage of one of the chips that are supported by the rtl8365mb driver (RTL8367S or RTL8370MB for example) is really great because those chips are cheap, available easily and the datasheets can be found.
But the big cumber stone is the missing VLAN and hardware offloading support.
The OpenWrt rtl8367b driver is having these capabilities but is using not DSA, it uses the old swconfig.
I saw that @hauke patched the rtl8365mb driver. So my question is how complicated it is to add VLAN and hardware offloading to the driver?
Unfortunately, my knowledge is not sufficient to do this job :-(. But I can offer testing.
Just for reference, somebody leaked the original Realtek SDK source code and I think I could be used to get the register value. There was also a short discussion at the LKML about the rtl8365mb driver.
. But the old 
.