The following instructions build up a cross-compiler toolkit for software construction that targets the Grandstream older phones' TMS320VC5402 chip, as well as for the newer phones' TMS320VC5501 chip.
Texas Instruments provides a build environment for a few hundred dollars or with a limited evaluation period or with code size limitations, none of which are attractive options for an open source project.
GCC has had support for tic4x chips, but this has been deprecated since 4.0.0 due to lack of support, and has been erased from 4.3.0 onwards. More importantly, tic4x is the incompatible predecessor to the chip families used by Grandstream, which are tic54x and tic55x. The latter can run code of the former, but is of course best used with its own toolchain.
There is BINUTILS support for tic54x, so an assembler and related tools do exist for the architecture. For completeness sake, the cross-build instructions for those tools are included below.
This seemed grim for a while... lacking a C compiler, it would be pretty hard to build a portable, open source firmware kit for SIP phones. Luckily, Texas Instruments releases a free and unlimited version of a download link for a reduced c54x toolkit and likewise there is a reduced c55x toolkit. For the GXV_ models of Grandstream, you will probably need the reduced c6000 toolkit For each of these, you won't get the luxoury of the complete toolkit, so you might still want to consider purchasing that one, but at least there is a no-expenses starter kit for everyone who wants to co-operate on this project. With special thanks to Joe at open hardware company Neuros Technology and the people at TI who made this possible. You will have to download the kit for yourself, and jump through a number of legal hoops, but I found nothing opposing an open source style of development.
The tools included in the TI c54x/c55x toolkit are:
For details, please refer to the compiler user guide for details.
The instructions below are for building BINUTILS 2.17, a version from the time that the tic4x architecture was supported in GCC. In retrospect, a newer version should work fine, as GCC is not going to be part of this story anyway. Please update with your experiences if you succeed at building a newer BINUTILS.
Similarly, the gdb debugger (hopefully for remote debugging) of June 21st, 2006 is
Finally, a C library may be required to get rolling. The version of March 6, 2006 should work.
The build of the cross-tools is a lengthy process that takes up a lot of memory. Everything will be installed in its own directory:
mkdir /opt/tic54x-0cpm-rtems/
A down-to-earth reference on cross-compilation (without any special tools) is http://linux.bytesex.org/cross-compiler.html
Note below that I am running the cross-tools on x86_64-debian-linux which or may not coincide with your building environment. Adapt as you see fit.
Unpack binutils, change into its directory. The package thinks it cannot support RTEMS on TIC54X, but it actually can. So first edit bfd/config.bfd and extend the line with c54x-*-*-*coff* | tic54x-*-*coff* with a third option | tic54x-*-rtems* just like for tic4x.
Then configure/build/install as follows:
CFLAGS=-g ./configure --prefix=/opt/tic54x-0cpm-rtems --target=tic54x-0cpm-rtems --host=x86_64-debian-linux make make install
Note: The -O2 option to GCC can cause it to break when buildling bfd. This is why we explicitly set CFLAGS=-g so as to override the default, CFLAGS=-g -O2.
Unpack glibc, change into its directory and copy include files:
cp -ar include /opt/tic54x-0cpm-rtems/include/
Note: Do not add include files for the kernel, as we will not be running a Linux kernel.
Note: Building glibc is not possible yet; it would require a cross-compiler, which we have not built yet. This may end up being a bootstrapping problem!
Note that this failed. Instead, we established that the free TI compiler is a better choice.
Following is the architecture for the application as it runs on a phone.
On Grandstream phones, a bootloader is probably a good idea because it helps to bootstrap the phone in situations where problems block an upgrade halfway -- which is somewhat likely because the RAM is smaller than the Flash. A small bootloader that can download and install upgrades is able to recover the phone in any situation. The bootloader is about 32 kB in size. It is not clear yet if using the Grandstream bootloader is better than using our own. Until we find a distinguishing argument, Grandstream's bootloader should do quite nicely.
The entire application will be programmed in C. Using only one language saves us from translation routines, and C is suitable as it is commmonly used for kernels and general embedded software.
The application will be a single program. It will be cross-compiled and cross-linked outside of the phones, which then has a single binary available for its purposes.
A number of kernels could be considered for operating a phone:
The most probably choice would appear to be RTEMS. The most likely method of using it would be as if it were a library, and link it to the application.
A few stacks exist to handle SIP and/or SDP in, as they say, very little space.
The best choice is probably oSIP. The phone itself can be built from an example application (such as linphonec) that builds on top of oSIP.
The core module of the telephone application will be a fairly cut-and-dry IPv6-based telephone. It should however support hooks for further extensions. Extensions would register with the core module (or another module) by entering statically allocated hookup-structures into a linked list, or having a pointer set to them.