I have released the source files for the second revision of this switch now on codeberg.org/MartijnBraam/Gigabit-Switch Hopefully there will be many more weird switches in the future :D
I've been eyeing up those switch chips with the external interfaces for quite a while now - Thank you for going for it and making it happen! I hope this goes places for low cost high quality managed switches in the future! The manufacturers these days cripple their managed switches intentionally so much to make you buy the more expensive ones when the chips in the cheap ones are perfectly capable of many more features.
Maybe some day embedded developers will start making decent control interfaces for their devices, probably a few decades in the future though... Would be interesting to create a proper managed switch firmware for the 8051 core in this but it's sadly completely undocumented how that core is supposed to work.
When I read your article, I had to think about IPv6 over BLE, 6LoWPAN and all those shenanigans. Might be interesting to build a router that can also just route all these IoT radio protocols.
I love this so much! I've always wanted to make an alternative to the unifi wall access point and this is exactly the lead i was looking for, i can now just figure out how to to add some wifi enabled soc connected to one of the extra ports (an allwinner perhaps?) and this could become a super cool project. Thanks so much for sharing! I'd love to see more...
Would the switch chip also do the switching, if i do the bridge with openvswitch? And if yes, would the switch chip also handle the switching when i configure openflow on the openvswitch bridge?
It seems like there's some integration to make Open vSwitch work with switchdev for hardware in Linux but I have no idea if it will work for this setup. In the examples I can find for it the interfaces with switchdev support added as seperate interfaces in openvswitch, I don't know if the bridge device created by openvswitch is a dsa compatible one but I guess it will be through all this.
@@MartijnBraam could you maybe test it? Because that would be then the first cheap openflow switch in years since the zodiac one, which only did 100 mbit
The switch chip being used in unmanaged and managed models made me think of TP-Link and Netgear 5/8/16 port network switches that have both unmanaged and managed variants. 🤯 It's probably that the managed variants have an EEPROM chip (+ licence for the firmware) and reset button, while the unmanaged ones don't.
Yeah it seems like the main difference is the storage, the unmanaged ones have a tiny i2c eeprom for hardcoding a few registers and the managed ones have a 4Mb nor flash chip on the SPI bus with 8051 firmware and templates for the webpages. Apparently it's possible to grab the Netgear GS105E firmware from the website, load it in a nor flash and then boot it on this device but I have not tried it yet.
@@MartijnBraam Interesting. I was thinking it'd also be possible with the TP-Link TL-SG105E firmware, but for the hardware revisions I have (though of the 108E and 116E because I don't have any 105Es), no firmware updates were released. I also forgot about 8051 microcontrollers having existed, probably because when I think of a microcontroller chip, I usually think of an RP2040. I saw your video on my TH-cam homepage and didn't think it was possible for Linux to directly address a managed network switch chip until I watched it. I was surprised.
8051 cores are absolutely everywhere. If something has the slightest chance of running firmware at all it most likely has an 8051 core in it. As far as I know the SG105E and GS105E are practically the same device. The 108 devices are basically the same topology but it uses the RTL8370MB instead probably. That's an 8 port switch chip with 2 internal CPU ports available. This one is also supported by Linux.
If you tcpdump on one of the lan ports you'll just get the traffic destined for your mac or ip on that interface, if it's in a bridge you still only see the packets for your own interface since the rest is handled in hardware. The issues with exposing more interfaces like the MII bus is that most pins are shared for other functions so you can't make one design that fits all.
That's true, since my final design won't have an ARM board but an x86 board it will simply be managed over USB with a raspberry pi pico. The code to get that working is relatively simple. I've seen some people also use an ESP32 to manage this.
@@MartijnBraam where? i am also doing something similar ut 100Mb + esp32 on the same pcb , found some code in 1 place but i dont have that much information regarding the switch registers , i can only guess atm
I also can't find it quickly anymore, at some point I came across some github repositories with chinese readmes that had a bunch of docs and a picture of a PCB with an ESP32 on it and a reference that it was running lua code, sadly there were not more details.
@@MartijnBraam Thank you! I have a project laying around here, that uses a Realtek 8367N chip with SMI and your video fascinates me. I have never seen this anywhere before. So I would like to try this, even if it makes no sense in my project. Unfortunately the part how to configure this in Linux is very short in your video. Would you mind sharing a few more details, like which dtoverlay you're loading, which parameters you're using? I tried grepping through the entire filesystem of my Raspberry Pi, but doesn't contain "realtek-smi" anywhere.
You probably will have to build all the DSA and switchdev related modules, no distro seem to ship it out of the box. I have written down more details here: blog.brixit.nl/making-a-linux-managed-network-switch/
@@MartijnBraam Do you absolutely need the reset pin to be wired up to a GPIO or is that the interrupt pin you're talking about in the video? On my PCB reset is hard wired high, unfortunately. 😕
I'm wondering if this can be controlled from a x86 system using a usb to gpio like FT232H. Not sure if Linux can be convinced to use that for the realtek-smi
It's not really possible to get a phandle for the gpios on an USB gpio chip so it can't be done in the same way at least. In theory it would be possible to add a glue driver in Linux but that would be pretty difficult.
This is one of the wild ideas for improving the hardware for streaming the FOSDEM conference. The main thing this is trying to solve is having a switch inside a 1U rack case that takes up as little space as possible and having one port on the inside of the case for plugging into a SBC. The alternative is having a cable looping around on the front which is ugly, or having neutrik ethercon jacks on the frontpanel and a bunch of small ethernet cables inside the case which is not space efficient. The switch doesn't even need to be managed in this usecase but having monitoring would improve everything.
I'm working on the final touchups of the design. I didn't want to release the version yet that has electrical issues that required cutting traces and snipping off pins to get a connection up and running. It will be OSHW and can be fully assembled by LCSC.
Yeah one of the Banana Pi boards is one of the few boards I found with schematic that had an RTL8367 on it, but only on preproduction models so very hard to get info on.
You are using ipv6 Internet. Is it really possible to ping any other device on ipv6 Internet if I know its ipv6 address? I mean, all devices are not hidden behind NAT, so they all are accessible directly by IP without need of intermediate node somewhere on the Internet.
That's not at all how IPv6 works. On IPv6 you have the same hiding mechanics as IPv4 but instead of with NAT it happens by the firewall, if you use any normal IPv6-capable router that's what happens in the background. IPv6 is also still routed like regular network traffic so it goes through all your intermediate nodes, you just stop changing IP addresses at random places.
Nice work. I know a commercial unmanaged switch where you can access SMI without voiding warranty and there is an 8051 just waiting for your code to execute. SDCC goes brrrr. Too bad these infos are obscured / NDA'd.
Yeah if only I could get any of those docs. That would add a lot of interesting possibilities to this platform since you can access quite a bunch of gpios and busses with it and there's the internal network interface. Which existing switch allows SMI access?
I have released the source files for the second revision of this switch now on codeberg.org/MartijnBraam/Gigabit-Switch
Hopefully there will be many more weird switches in the future :D
I've been eyeing up those switch chips with the external interfaces for quite a while now - Thank you for going for it and making it happen! I hope this goes places for low cost high quality managed switches in the future! The manufacturers these days cripple their managed switches intentionally so much to make you buy the more expensive ones when the chips in the cheap ones are perfectly capable of many more features.
Maybe some day embedded developers will start making decent control interfaces for their devices, probably a few decades in the future though...
Would be interesting to create a proper managed switch firmware for the 8051 core in this but it's sadly completely undocumented how that core is supposed to work.
When I read your article, I had to think about IPv6 over BLE, 6LoWPAN and all those shenanigans.
Might be interesting to build a router that can also just route all these IoT radio protocols.
That should be easily doable by adding the radios for that to the SBC connected to the switch :)
@@MartijnBraam Don't motivate me. I need to get one thing done first.
@@MartijnBraam That's also what I thought. I flash a RTOS like RIOT on them and they just bridge the radio to LAN.
that would make a very neat home automation hub, add a few 433mhz radios, some zigbee maybe. Actual WiFi is also useful :D
I love this so much! I've always wanted to make an alternative to the unifi wall access point and this is exactly the lead i was looking for, i can now just figure out how to to add some wifi enabled soc connected to one of the extra ports (an allwinner perhaps?) and this could become a super cool project. Thanks so much for sharing! I'd love to see more...
Those accesspoints generally have hilariously underpowered SoCs in them so a random allwinner will probably work fine.
Would the switch chip also do the switching, if i do the bridge with openvswitch? And if yes, would the switch chip also handle the switching when i configure openflow on the openvswitch bridge?
It seems like there's some integration to make Open vSwitch work with switchdev for hardware in Linux but I have no idea if it will work for this setup. In the examples I can find for it the interfaces with switchdev support added as seperate interfaces in openvswitch, I don't know if the bridge device created by openvswitch is a dsa compatible one but I guess it will be through all this.
@@MartijnBraam could you maybe test it? Because that would be then the first cheap openflow switch in years since the zodiac one, which only did 100 mbit
The switch chip being used in unmanaged and managed models made me think of TP-Link and Netgear 5/8/16 port network switches that have both unmanaged and managed variants. 🤯
It's probably that the managed variants have an EEPROM chip (+ licence for the firmware) and reset button, while the unmanaged ones don't.
Yeah it seems like the main difference is the storage, the unmanaged ones have a tiny i2c eeprom for hardcoding a few registers and the managed ones have a 4Mb nor flash chip on the SPI bus with 8051 firmware and templates for the webpages. Apparently it's possible to grab the Netgear GS105E firmware from the website, load it in a nor flash and then boot it on this device but I have not tried it yet.
@@MartijnBraam
Interesting. I was thinking it'd also be possible with the TP-Link TL-SG105E firmware, but for the hardware revisions I have (though of the 108E and 116E because I don't have any 105Es), no firmware updates were released.
I also forgot about 8051 microcontrollers having existed, probably because when I think of a microcontroller chip, I usually think of an RP2040.
I saw your video on my TH-cam homepage and didn't think it was possible for Linux to directly address a managed network switch chip until I watched it. I was surprised.
8051 cores are absolutely everywhere. If something has the slightest chance of running firmware at all it most likely has an 8051 core in it.
As far as I know the SG105E and GS105E are practically the same device. The 108 devices are basically the same topology but it uses the RTL8370MB instead probably. That's an 8 port switch chip with 2 internal CPU ports available. This one is also supported by Linux.
STUNNING work!
Wow very cool
Thank you Kanye, very cool
What happens if you run tcpdump on one of those lanX ports? Does it work?
Can you include *MII interface in the next revision?
If you tcpdump on one of the lan ports you'll just get the traffic destined for your mac or ip on that interface, if it's in a bridge you still only see the packets for your own interface since the rest is handled in hardware.
The issues with exposing more interfaces like the MII bus is that most pins are shared for other functions so you can't make one design that fits all.
Do it support AVB (audio video bridge)
@MartijnBraam, can I do un-managed standalone switch with this chip ?
Yeah that works fine. It's a regular 'ol 5 port gigabit switch when not controlled.
@MartijnBraam , thank you. In your github KiCAD schematic, is the chip configured in such way?
i think that any MCU can do the management via MDIO/SMI but i had a hard time finding good libraries/drivers
That's true, since my final design won't have an ARM board but an x86 board it will simply be managed over USB with a raspberry pi pico. The code to get that working is relatively simple. I've seen some people also use an ESP32 to manage this.
@@MartijnBraam where? i am also doing something similar ut 100Mb + esp32 on the same pcb , found some code in 1 place but i dont have that much information regarding the switch registers , i can only guess atm
I also can't find it quickly anymore, at some point I came across some github repositories with chinese readmes that had a bunch of docs and a picture of a PCB with an ESP32 on it and a reference that it was running lua code, sadly there were not more details.
Can you share how you need to set the solder bridges to make this work? Do you just need SMI_SEL high or does it require anything else?
I have SMI_SEL high, EN_SPIF low, DIS_8051 high and DISAUTOLOAD low
@@MartijnBraam Thank you! I have a project laying around here, that uses a Realtek 8367N chip with SMI and your video fascinates me. I have never seen this anywhere before. So I would like to try this, even if it makes no sense in my project. Unfortunately the part how to configure this in Linux is very short in your video.
Would you mind sharing a few more details, like which dtoverlay you're loading, which parameters you're using? I tried grepping through the entire filesystem of my Raspberry Pi, but doesn't contain "realtek-smi" anywhere.
You probably will have to build all the DSA and switchdev related modules, no distro seem to ship it out of the box. I have written down more details here: blog.brixit.nl/making-a-linux-managed-network-switch/
@@MartijnBraam Very cool. I'll work my way through it and hope that my Pi will still boot in the end. 🤓
@@MartijnBraam Do you absolutely need the reset pin to be wired up to a GPIO or is that the interrupt pin you're talking about in the video? On my PCB reset is hard wired high, unfortunately. 😕
I'm wondering if this can be controlled from a x86 system using a usb to gpio like FT232H. Not sure if Linux can be convinced to use that for the realtek-smi
It's not really possible to get a phandle for the gpios on an USB gpio chip so it can't be done in the same way at least. In theory it would be possible to add a glue driver in Linux but that would be pretty difficult.
This is super cool! :)
What project were you working on that inspired you to do this?
This is one of the wild ideas for improving the hardware for streaming the FOSDEM conference. The main thing this is trying to solve is having a switch inside a 1U rack case that takes up as little space as possible and having one port on the inside of the case for plugging into a SBC. The alternative is having a cable looping around on the front which is ugly, or having neutrik ethercon jacks on the frontpanel and a bunch of small ethernet cables inside the case which is not space efficient.
The switch doesn't even need to be managed in this usecase but having monitoring would improve everything.
Embedded electronics for the win! It looks good.
When will you release more 3D printing videos?
Could you share the PCB, or do we need to purchase it?
I'm working on the final touchups of the design. I didn't want to release the version yet that has electrical issues that required cutting traces and snipping off pins to get a connection up and running. It will be OSHW and can be fully assembled by LCSC.
I assume this is similar to how the Banana Pi-R* boards work, they just have an ARM SoC on the same board
Yeah one of the Banana Pi boards is one of the few boards I found with schematic that had an RTL8367 on it, but only on preproduction models so very hard to get info on.
You are using ipv6 Internet. Is it really possible to ping any other device on ipv6 Internet if I know its ipv6 address? I mean, all devices are not hidden behind NAT, so they all are accessible directly by IP without need of intermediate node somewhere on the Internet.
That's not at all how IPv6 works. On IPv6 you have the same hiding mechanics as IPv4 but instead of with NAT it happens by the firewall, if you use any normal IPv6-capable router that's what happens in the background. IPv6 is also still routed like regular network traffic so it goes through all your intermediate nodes, you just stop changing IP addresses at random places.
Nice work. I know a commercial unmanaged switch where you can access SMI without voiding warranty and there is an 8051 just waiting for your code to execute. SDCC goes brrrr. Too bad these infos are obscured / NDA'd.
Yeah if only I could get any of those docs. That would add a lot of interesting possibilities to this platform since you can access quite a bunch of gpios and busses with it and there's the internal network interface.
Which existing switch allows SMI access?
Asus XG-U2008 has SMI pins under the serial# label. Oh, and it's a Z80 not a 8051.
Can it do tagged vlan?
Yes it has support for letting the switch handle the tagging and trunking of the traffic although I haven't actually tried to set that up.
several parts where🤣
mooi man :-)
translation Hindi
Translation Hindi