- A lesson in hardware business
I have an old unmanaged, wired, gigabit switch from my university years, namely an ASUS GigaX 1105B, which now acts mainly as a backup and experimentation switch. I’ve decided to take it apart and examine the device for fun as well as a bare bone component for a potential SBC cluster build.
- Ports: 5 x 10/100/1000Mbps
- MAC Address Table Size: 8k entries
- Compliant Standards: IEEE 802.3 (10Base-T), IEEE 802.3u (100Base-TX), IEEE 802.3ab (1000Base-T)
- Jumbo frames: up to 9.6KB
- Communication Mode: full-duplex, half-duplex
- Power supply voltage: 12V DC
- Power consumption: 12W
To disassemble the switch all is needed are one small Philips and one slot screwdriver. There are four screws holding the case together on the bottom of the device, two of which are hidden under the rubber feet (№1. & №4).
I started by carefully peeling away the rubber feet with the slot screwdriver for the two hidden screws.
Once done, I unscrewed all four screws to release the top from the PCB and the bottom cover.
After setting the rubber feet and the screws aside, and flipping the device proper side up the top side plastic cover could be simply lifted off.
The PCB is simply held in place by the top and bottom halves of the cover, so it can be simply taken out from the bottom part of the case. To do that I had to slightly bend the rear of the bottom half of the case and then lift the rear end of the PCB first (where the ports are) as the LED prisms glued in place at the front are in the way otherwise.
Removing the heat sink can be done by carefully pinching together the two plastic nail ends at the bottom of the PCB and pushing them through the hole.
Finally once the heat sink is removed the integrated gigabit Ethernet switch chip becomes exposed.
We can immediately observe that the inner side of the top cover has some black burn marks, which clearly show the heat convection pattern from the heat sink beneath it. This is due to the slim design of the switch, as there is only a 2.66mm clearance between the aluminium heatsink and the top cover. No wonder there is a big yellow discoloration on the outside of the plastic (ABS) case, which now we know is due to exposure to high temperatures, resulting in an accelerated aging of the polymer in that location.
Although this is mainly an aesthetic problem, the design could be improved to avoid this by choosing a dark (e.g. black) color for the casing, installing a thinner heat sink with a bigger area, thus distributing the heat over a larger surface, or finally having some grilles directly above the heat sink itself, allowing for the heat to escape via better ventilation.
The PCB seems to be a simple double sided board (i.e. no inner layer), as far as I can tell, using mostly SMD parts on both sides with a few through hole parts.
The design is divided into three clear areas: a DC/DC power circuit, the switch logic, and the Ethernet ports. The bottom of the PCB contains only resistors and capacitors related to the SoC and isolating transformers.
The power connector is a standard 5.5mm/2mm barrel plug, where the barrel is the ground and the pin is the positive voltage. The circuit converts the 12V DC input into 2.5V and 1.2V power rails for the switch to use, which is achieved with two separate DC/DC converters.
The top part of the circuit has an AP1510 step-down switching regulator to produce the 2.5V (measures as 2.557V) used by the SoC to interface with the EEPROM as well as to drive the LEDs.
The PWM frequencies and duty cycles can be seen below as measured on an oscilloscope. The chosen frequencies are sufficiently high to avoid audible noise from the converters (yellow: AP1510; blue: AP2008).
The board is powered by a Vitesse VSC7385XVY switch SoC. Unfortunately a detailed datasheet is not available for this IC, though the brochure provides us with some hints.
After examining the board it’s safe to assume that the implementation closely follows the recommended reference design. The SoC is clocked by a NSK DDH 25MHz crystal and the firmware for the built in 8051 CPU is stored in a Atmel 25640AN 64Kbit SPI interfaced serial EEPROM.
It’s interesting that they have chosen the automotive variant of the EEPROM for this product, perhaps they were using some surplus of this chip, as I believe it became obsolete around the time this switch was manufactured.
There are two header spaces on the board, which I assume were used for programming, and potentially diagnostics, of the device during manufacturing.
The first one marked as J1 is to the right of the SoC, under the EEPROM for a 2x5 pin header. The second one marked as J2 is to the left of the SoC simply, which has GND and 2.5V on it’s pins. After poking around with a multimeter the following pinout was deduced:
On J1 header pins 3 and 7 are probably some serial (RS232) or some other debugging pins connected to the CPU, though I was not able to identify them with full certainty. The remaining pins are connected to the SPI bus that can be used to access the EEPROM.
J2 header seems to reset the CPU when shorted, though it does not keep it in reset state.
By attaching a logic analyzer (after soldering in a header) I could observe the CPU loading the firmware from the EEPROM after a reset. There is no traffic between the EEPROM and the CPU post startup, so it’s safe to assume the program runs entirely from RAM during the device’s operation. This assertion is further solidified when looking at the signal trace, as the code loaded from the EEPROM is 7832 bytes in size, which is just a few hundred bytes short of the chip’s 8kB capacity.
Dumping this code to a file would allow for additional analysis via disassembly, but without further goals it seemed pointless to me.
A lesson in hardware business
Before opening the case for the first time I expected to see something more complex and exciting, but the more I looked at the board the more it dawned on me: the product is nothing more than a reference implementation for the switch SoC with some standard DC/DC converter circuits powering it on a simple two layer PCB. All this housed in a, at the time trendy or modern looking, plastic molded case and shipped with some off the shelf AC/DC switching power supply unit they had around for other products (e.g. routers).
However after giving this a bit more thought, I’ve realized the rationale behind this. ASUS started out as a PC motherboard company in the 90’s. As the company grew and gained recognition it was natural to expand into other consumer equipment like networking gear. Producing devices like this switch likely had many benefits to an upcoming company: it’s low complexity design allowed for fast product cycle, was likely cheap to produce, and provided a low risk way to increase brand recognition in the consumer market while also generating some profit for the company.
As the company grew and became more successful they’ve phased out low added value (and likely low margin) products. I bought my switch around 2006 and it was a prominent offering among their networking gear selection. In contrast today the only networking gear they seem to produce are high end routers, rack servers, and IoT devices. In fact there is barely a placeholder, lacking useful information, for this legacy product on their support page.
In hindsight the lesson is obvious: to build a successful company one does not necessarily need a new and unique idea. Building something existing but with some differentiation (e.g. cheaper, prettier, higher quality) is a good way to enter the market. The product should be sufficiently complex that one has to compete only with limited number of others. This also leaves space for learning other aspects of running a business while providing internal talent with a gradual learning curve. As long as it can be sold in high quantities it will generate enough profit for future growth.
Tools I’ve used during this teardown session to help me better understand the device:
- Mitutoyo 532-120 Vernier Scale Calipers
- Hantek DSO5202BM oscilloscope
- Fluke 87V multimeter
- USB logic analyzer (8CH, 24MHz, Saleae clone)
Pulseview EEPROM decoding bug
Sigrok’s Pulseview has built in EEPROM traffic decoder to better visualize actual commands and bytes sent over the bus. This decoder parses address related commands incorrectly, since Atmel 25640AN uses a 2 byte addressing, while the decoder assumes 3 bytes for address after each read command. This means that all byte positions read from the EEPROM in the analyzer view should be shifted 1 byte right (i.e. the last address byte is actually the first data byte).