These routers have started out as Flowpoint, gone through a few intermediate hands and ended up with Siemens, but are most affectionately and descriptively known as Inefficient Networks. These routers are the absolute worst of all existing SDSL CPE and therefore of course they used to be the ones most commonly inflicted on users by ISPs. (Nowadays Siemens 5890 and Netopia 4652 seem to be the most common fare.)
Here are just a few of our horrible experiences with a 5851 on a Covad-provisioned SDSL line from Verizon Business:
(in)Efficient Networks routers are not Cisco-like, they fall a few orders of magnitude short of that quality level.
The family of FP/EN routers described on this page consists at the first glance of 3 models: one for SDSL, one for ADSL and one for IDSL. Under the (in)Efficient Networks brand they were called 5851, 5861 and 5871, respectively. (It appears that the names were different under the original Flowpoint brand.) All 3 look the same on the outside as they share the same enclosure and power supply; 3 different PCBs inside thus fit into the same form factor. Here we are concerned with the 5851 for SDSL/2B1Q and the 5871 for IDSL; the 5861 for ADSL is outside the scope of our project.
But here comes another very annoying problem with these routers: although at first it seems that a 5851 is a 5851, in actuality there is a big proliferation of submodels. Different submodels of the 5851 support different SDSL flavors, and these submodels are truly different products and not just different default configurations. A given 5851 submodel supports only one SDSL flavor and cannot be changed to a different flavor just by selecting it in a configuration menu. It appears that all 5851s share the same hardware modulo evolutionary revisions, but have different firmware. This firmware includes the FPGA configuration image (see below). The same appears to be the case with the 5871 for IDSL, although perhaps to a lesser degree.
Of course having a variety of different and incompatible products sharing the same model number is not a very sensible manufacturing business practice. However, given the SDSL CPE business model these routers were designed for, anything goes.
Another unfortunate observation is that there seem to be many more different 5851 submodels for different SDSL flavors than the number of flavors supported by well-known competitors such as the Netopia R-series. The conclusion is that the 5851 abomination may be the only available CPE for some of the lesser SDSL flavors.
It seems that just about the only thing that's actually good in these
horrible routers is the power supply.
These units take AC mains power directly and feature an IEC 320
(kettle plug
) power connector on the rear panel, along with a power
switch.
Inside is an Amperor AOF25-3030
open frame power supply which accepts both American and European AC voltage
on input with automatic switching and produces 3 DC voltage outputs:
+5 V, +12 V and -12 V.
The IEC 320 mains entry connector is located on the main PCB along with the router's main functional circuit. Unswitched mains are fed to an internal header post into which plugs the power switch on the rear panel. The other side of the switch goes to an identical header on the AOF25, which is mounted in the area where the main PCB has a cutout. A short internal cable carries DC power from the AOF25 to the functional section of the main PCB.
The router is a single microprocessor system with an MPC850DE CPU, 4 MB of DRAM and 2 MB of flash. LAN and WAN both attach to it as peripherals. The 10BaseT Ethernet hub is an AM79C984 and is presumed to connect to an SCC on the MPC850DE in Ethernet mode. The DSL WAN interface is a little more complicated as explained below.
The 5851 features an RS8973 bitpump and an Altera FLEX10K FPGA, which is
presumably where the zoo of SDSL flavors is implemented. The FPGA was an
EPF10K30ATC144 (3.3V core) on the unit we've got from Covad/Verizon
in early 2006, but an earlier unit from eBay in which the PCB still says
Flowpoint
on it and sports a few blue wires has an EPF10K10TC144
(5V core) instead.
No separate configuration device is used for the FPGA, so the configuration
image must be stored as part of the main firmware and loaded by the CPU.
Note that the CPU is an MPC850DE, not an MPC850SR or MPC850DSL. The latter have ATM support, the former doesn't. All MPC850xx CPUs share the same BGA footprint, so it's possible that an MPC850SR or MPC850DSL may have been populated in some 5851 submodel, but our Nokia-flavored unit had an MPC850DE on it, so it looks like they have implemented all ATM stuff in the FPGA and interfaced it to the MPC850 in an ad hoc manner. AAL5 SAR must be done in software since the CPM microcode-assisted SAR is also part of the ATM block missing in the MPC850DE.
On the 5871 the IDSL chip is Infineon PEB 2091N and instead of the FPGA there is an EPM3064ATC100 CPLD. The CPLD should be a little too small to implement I.432 ATM cell delineation, so we hope that FP/EN's use of a CLPD instead of an FPGA for IDSL is a confirmation that there is no IDSL/ATM.
EN's marketing literature says that 5851 and 5861 (ADSL) have hardware 3DES, but not 5871. That definitely refers to the FPGA and indicates that the FPGA does more than just the DSL transceiver interface and flavoring.
Since virtually all of their fuberedness comes from software rather than hardware, it becomes a valid question whether one could perhaps breathe a new life into these routers by replacing their shitty firmware with something free and open source. This idea is further reinforced by the observation that the MPC8xx processor family is perfectly supported by Linux and is in fact a perfect platform for Linux-based open source routers.
Such a hack would however run into a few major problems:
(The biggest problem) The processor boot flash (and the only flash chip in the system) is a soldered TSOP (a 28F016 specifically). Desoldering the chip once to read out its contents wouldn't be too terribly difficult, but doing the bringup of our own replacement boot code is a whole different story. Although there do exist prototyping sockets for TSOP, they are very touchy and have serious reliability problems. We could be trying to bring up our code, getting nothing, and wondering whether it's our code or the socket making a bad connection.
The total flash capacity of 2 MB is a little too small for a comfortably hackable Linux system. It can probably be squeezed, but that would sacrifice one of the main strengths of free and open source software: hackability. There is an unpopulated footprint for a second flash chip and one might also be able to populate higher density flash parts, but it's unclear how much room for growth there is.
A project of this magnitude would need to be of benefit to all and not just to us. Although eBay is replete with 5851s, as we have discovered empirically, there are multiple hardware revisions floating around. Just the two units we've had feature different FPGA parts and thus cannot possibly be supported by the same firmware.
The hardware design is not actually all that great. It is straightforward
and cheap, but not great from the perspective of modularity and rather
suboptimal for a modular open source OS like Linux.
The use of ATM-less MPC850DE and ad hoc ATM in the FPGA means more
main CPU load and less opportunity to make use of the existing Linux ATM
stack.
Having the RS8973 bitpump controlled by the router's main CPU without a
dedicated peripheral processor also turns out to be suboptimal:
the BT software could probably be adapted
to Linux by turning _BtMain() into a kernel thread and
turning _BtControl() and _BtStatus() API calls
into ioctls, but it still
does some real time processing which may pose a problem.
(Read this page for more musings on this topic.)
All of these problems could be worked around and some will find them more or less serious than others, but at least for this hacker they are sufficient for the interest in this particular hack to not grow beyond speculation.
Anyone who still wants to hack these routers at the CPU/firmware level should look into PowerPC processor debug probes.
Like most PowerPCs, MPC8xx processors have a special port for hardware-assisted debugging. I don't remember whether it's through JTAG or a separate interface on this particular CPU, but there definitely is a hardware debug port. And sure enough, looking at our EN 5851 boards I see two unpopulated header footprints next to the MPC850DE which look very much like those commonly provided for the debug probes. One can probably populate these headers (easy), connect them to the right processor debug probe and gain the ability to read out the flash contents, trace the firmware, set data breakpoints on the registers of interest, download hack code into RAM and run it without ever desoldering the flash chip.
Those processor debug probes are expensive toys though — it helps to have access to a good company or university lab.