Cross-platform toolkit

Compiler environment

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.

Choice of compiler tools

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.

Fetching a free TI toolkit

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:

  • cl500/cl55 -- C/C++ compiler, optimising, ANSI-compliant
  • asm500/asm55 -- assembler
  • abs500/abs55 -- extract absolute addresses in assembler form from linked object files
  • hex500/hex55 -- convert object files to standard hex formats (for uploading)
  • ilk500/ilk55 -- IFILE linker
  • lnk500/lnk55 -- ELF linker
  • nm500/nm55 -- symbol name extractor
  • ofd500/ofd55 -- object file dump utility
  • strip500/strip55 -- remove symbols and debuginfo from an object file
  • xref500/xref55 -- extract symbols from final output object file
  • embed500/embed55 -- embed ICODE (?) into an object file
  • cg500/cg55 -- code generator, for internal use by cl500 only
  • opt500/opt55 -- optimiser, for internal use by cl500 only
  • libinfo500/libinfo55 -- library archiver, for internal use by cl500 only

For details, please refer to the compiler user guide for details.

Fetching binutils for cross-building

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.

Building cross-tools

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

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.

Building binutils

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 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.

Install include files and libraries

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!

Building the C compiler

Note that this failed. Instead, we established that the free TI compiler is a better choice.

Application architecture

Following is the architecture for the application as it runs on a phone.

Grandstream bootloader

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.

Application architecture

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:

  • uIP is a very small TCP/IP stack with a far-from-standard API. Threads are stackless and calls are done in network-packet order. Although ideal for highly embedded systems which can only spare tens of kB, this is clearly too farfetched.
  • Linux is the other end of the spectrum; it requires a system with tens of MB to spare for the kernel. Also, this setup is better suited for systems that unpack the kernel from flash and then run it from RAM. This is not a reasonable option with phones, that tend to run directly from flash. (At least, that applies to Linksys SPA and Grandstream phones).
  • RTOS is a bit restrictive in letting new users in. It appears less in demand than RTEMS.
  • RTEMS appears to be fairly popular. It basically offers a single POSIX process; it lacks abilities for memory mapping, process forking, or shared memory. But it does come with a port of the BSD TCP/IP stack and it can even support file systems. RTEMS closely corresponds to POSIX profile 52.

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.

SIP and SDP handling

A few stacks exist to handle SIP and/or SDP in, as they say, very little space.

  • pjSIP appears to be too big.
  • oSIP is probably small enough.

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.

Telephone core module

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.

Docutils System Messages

System Message: ERROR/3 (../reverse/grandstream/toolkit.rst, line 37); backlink

Unknown target name: "gxv".