I discovered OpenWRT only last year, but then I wasted no time switching my ER-X over to sane, modern firmware.
After that, I was curious about how difficult it might be to add OpenWRT support for some simple piece of gear. So I picked up a Netgear GS380E, which is an 8-port managed GbE switch. This switch implements QOS at some level, so I figure there has to be a reasonable chipset in it with decent processing power and memory.
I opened up the box to look for a console port, and I found what looked like a promising 3-pin connector on the back edge of the PCB. Alas, some spelunking determined that this connector only breaks out the 3.3V supply. I de-soldered a 0Ohm resistor connecting two of the pins on the connector, which disconnected the power from the switch proper, so I figure the connector is there to allow measuring the current and voltage of the power supply.
So, alas, no serial console that I can find.
The firmware file is readily downloadable, but binwalk and strings don't yield anything interesting, so I don't think the stock firmware is Linux.
I wonder where, if anywhere, I can go from here? There is an 8-pin Winbond chip right next to the big switch ASIC - would that be for configuration only, or will it contain the firmware for the switch?
I have a fairly decent electronics workshop, so I can hookup a logic analyzer, solder and desolder, whatever.
I'm doing this for recreational purposes so I don't mind sinking some time into it, but I wonder if there are reasonably direct ways to figure out what makes this switch tick?
NETGEAR is a vendor that appears to make an attempt at GPL compliance, so if the device was already running Linux you would be able to find firmware source at NETGEAR Open Source Code for Programmers (GPL). Based on the fact that no firmware source for this device appears there, it is safe to assume that porting OpenWrt to this device is not possible.
Ah, I did see those strings, didn't realize the significance. Looks like BCM53128 is an exact match for the capabilities of this switch, and if so it's "driven" by an 8051 :(.
I've wondered in the past if it's appropriate to put devices like this in the ToH? Save people some time by simply documenting "this won't work, here's why...", but I suppose the forum threads are pretty discoverable already.
I also have a D-Link DGS-1100-08V2 lying around. Presumably this contains similar hardware, as according to the tech specs this device has 48KB of RAM and 2MB flash.
Amazing how cost-optimized these devices have become.
The switch fabric is implemented in hardware, it works almost on its own. The only use for that flash/ RAM is to bootstrap it correctly on boot, setting up the VLAN configuration (or hard-strap it to unmanaged, in larger unmanaged routers).
A real CPU, with sufficient amounts of flash/ RAM and a proper operating system (linux) is only needed for the webinterface (and with really spartanic/ static webpages, you might even get along with that, just with a slightly beefier MCU and some assembler based µIP stack and routines (e.g. I do have a 24 port switch with webinterface using an 8051 derived MCU)) and maybe some advanced monitoring features (SNMP and friends).
Gotcha. As a n00b, I was surprised to see how much functionality has been pushed into the ASIC. I thought e.g. QoS would have to be handled through a CPU, but the data sheet for the BCM53128 describes how the ASIC implements a simple priority-based QoS.