The firmware contains a large image file that turns out to be a concatenation of a few gzip-files and a checksum:
LEN=$(wc -c < dsp205-1.0.0988.01.bin) dd if=dsp205-1.0.0988.01.bin of=fcodec.out.gz bs=65536 count=2 dd if=dsp205-1.0.0988.01.bin of=ic.img.gz bs=65536 skip=2 count=1 dd if=dsp205-1.0.0988.01.bin of=voip.img.gz bs=1 skip=$[3*65536] count=$[$LEN-3*65536-8] dd if=dsp205-1.0.0988.01.bin of=trailer.bin bs=1 skip=$[LEN-8] count=8 gunzip fcodec.out.gz gunzip ic.img.gz gunzip voip.img.gz
The 8 bytes trailer in old firmware 1.0.0457.00 for DSP200:
0013d010 43 32 30 31 32 42 | C2012B| 0013d020 32 42 |2B| 0013d022
So it reads C2012B2B and could simply be printed.
The 8 bytes trailer in new firmware 1.0.0.988.01 for DSP200:
0013cff0 45 39 41 42 33 32 46 36 | E9AB32F6| 0013cffc
So this reads E9AB32F6 and could simply be printed.
The 8 bytes trailer in new firmware 1.0.0.988.01 for DSP205:
0013cfc0 36 43 45 30 37 38 45 41 | 6CE078EA| 0013cfcf
So this reads 6CE078EA and could simply be printed.
Clearly,
So, to try the checksum, we reuse $LEN to get everything before it:
LEN=$(wc -c < dsp205-1.0.0988.01.bin) dd if=dsp205-1.0.0988.01.bin of=presum.bin bs=1 skip=0 count=$[$LEN-8]
Then, using the check CRC-32 tool from http://www.gregroelofs.com/greg_software.html
../check-4.3/check presum.bin presum.bin CRC-32 = 6ce078ea, size = 1298375 bytes
Clearly, the trailing 8 bytes represent the CRC-32 of the previous content, printed as uppercase hex digits in ASCII, without trailing newline, so "%08X".
As was to be expected, this contains little of interest. It is probably manually crafted assembler code.
Analyse the strings in voip.img with:
strings voip.img
This reveals a text start of uCos. The uC/OS is an RTOS that is described on http://en.wikipedia.org/wiki/MicroC/OS-II and on http://micrium.com/page/products/rtos/os-ii
The ic.img contains long texts to be displayed as menus during manufacturing and testing. It appears to be the bootloader:
It appears to be showing interactions over SPI and/or UART
It has control over the ethernet and MAC addresses, UART, flash, ...
It supports "User Program Download", and running programs in RAM
It can do firmware upgrades
The LCD is a HD44780, presumably steered from a MPU6800:
http://en.wikipedia.org/wiki/HD44780_Character_LCD http://www.dinceraydin.com/djlcdsim/djlcdsim.html
The system would seem to contain a CM5001, which replaces a PIC16C54/56 and CF745?
Interestingly, the many diagnostic routinges in ic.img will be good sources for scraps of code that would otherwise be lost in much more complicating code.
The following chips are available on the board:
JP2 is an RS-232 interface running at 3V3. Thanks to Jeroen for helping me figure out what it did with his splendid autobaud converter.
Surprise, surprise! Even though the device uses a 70 ns NOR flash, it does not run programs straight from it. Instead, it gunzips a program at a time, loads the result into DRAM and jumps to that form.
That means that this device may actually be able to run fullblown Linux. That would be strange, though, given that a firmware can be directly matched to the hardware. It is much nicer to use the impressive space to have it do more useful things in the telephony area, where it matters in terms of end-user experience.