An interesting presentation at NLUUG 2011 may show you some of the fun that it is to reverse engineer an existing device.
The following is a list of partially or fully analysed devices with links to their descriptions:
Grandstream devices appear in two generations, the older of which is now considered end-of-life by Grandstream.
tic54x
The older generation, which is now end-of-life, is built around Texas Instruments' TMS320VC5402 DSP chip. In addition there is static RAM and 70ns NOR flash memories from which programs run. Network connectivity is achieved with 1 or 2 chips RTL8019AS, which are half duplex 10 Mb/s cheap clones of the NE2000 chip.
The construction of these devices is extremely low-power, easily under 2 Watt (or about 17.5 kWh in a year).
TI provides a toolchain for free to open source development projects. The JTAG connector is non-standard, and includes pins for access to a synchronous serial port annex bootloader channel.
tic55x
This is the newer generation, built around Texas Instruments' TMS320VC5501 DSP chip. The working memory has been exchanged for much larger SDRAM chips and programs still run from 70ns NOR flash memories. Network connectivity is said to run at 100 Mb/s but this is achieved with the same old RTL8019AS chip that runs at 10 Mb/s with a 100 Mb/s switch chip RTL8035SC to make it look better on the outside.
These devices run into higher power ratings, around 5 Watt, or about 43.8 kWh a year. The higher power is probably as a result of the different DSP, more RAM of a lesser efficiency, and the ethernet speedup.
These devices have a mode where they can run tic54x code, but TI also provides a toolchain for free to open source development such as this project. The JTAG interface is TI's standard interface; some devices toss in an additional I2C interface.
Note the general description of the GXP architecture that catches most models in this line.
tic6000
This is the video generation, or the GXV series.
Some vital components are covered in paint. This can be removed with a razor blade; these are marketed in small handling tools, intended to scrape paint off of glass surfaces. The working principle is the flatness of a glass surface, and the same principle helps to scrape the paint off of these chips. So, aim to keep it flat; this will help to avoid that you scratch into the chip, which may stop it from functioning. Also, scrape paint rather than polish it off; the latter yields unpleasant fine dust and will take must longer than needed. Of course, any risk of loss of hardware, limbs and so on is yours to take.
The size of the flash and RAM make this device unsuitable for running Linux. That is no problem by itself. We aim to use uIP instead, and make very small core functionality, which would be impossible with a Linux kernel. The use of this small infrastructure is that it may also apply to embedded applications, thus creating a much larger array of phone-enabled gimmicks than is currently common.
The SIP stack size is an important factor in all this. A good stack is needed, and given the aims of this project it should be open source. Two candidates are then pjSIP and oSIP. Since pjSIP appears quite large, consider the second one first:
bash$ ls -l /tmp/libosip*so* -rwxr-xr-x 1 vanrein vanrein 88080 Sep 2 22:38 /tmp/libosip2.so.4.2.0 -rwxr-xr-x 1 vanrein vanrein 204048 Sep 2 22:39 /tmp/libosipparser2.so.4.2.0
Similar results may apply to pjSIP as to oSIP.
This details code size, and given 1 MB flash in even this simple device, it looks like a lot of space is available. The requirements of this stack are also simple, all that is needed is (a simulation of) glibc primitives. The functions needed involve string handling, memory allocation, file access, networking, and threading/locking. It should not be difficult to provide for these simple functions in a simple core.
The resulting architecture then becomes a monolithic application looking like this:
Software layer Estimated code size Actual code size phone application 25 kB Variable oSIP2 300 kB 6 kB (own parser) glibc simulation 50 kB N/A without oSIP2 realtime+network OS 100 kB 17+13 kB device drivers 25 kB 9 kB
The total code size is therefore estimated to be 500 kB, which is easily achieved on even these low-end BT102 phones. For larger models, it also pays to be thrifty with space -- it could be possible to include code to unpack Ogg and either use it for webradio listening, or for listening to one's personal music collection. Or we could add RealTimeText as a default feature. Or... well, in general -- cool things can be done in space left open.