TopPrepare to build your toolchain: collect the sources

The packages that are being used are: gcc-4.0.2, binutils-2.16.1, Insight-6.4, and NewLib-1.13.0. I like to build my development environment from source as I find that I not only have more control over the build process, but then I don't have to worry about keeping track of where I downloaded a prebuilt package. Or that the webpage for the package has disappeared. I only have to keep the scripts around to rebuild later on.

These are the source files that you will need:

binutils-2.16.1.tar.bz2

gcc-4.0.2.tar.bz2

insight-6.4.tar.bz2

newlib-1.13.0.tar.gz

gcc-4.0.2_patch.gz

newlib-1.13.0_patch.gz

newlib_makefile_patch.gz

You will also need some scripts to build the toolchain:

00setSources.sh

01makeBinUtils.sh

02makeBootGcc.sh

03makeNewLib.sh

04makeRealGcc.sh

05makeInsight.sh

allclean.sh

environ.sh

TopGetting ready to build

Note: All operations are done as an unpriviliged user.
Note: Scripts will install the results under $HOME/devtools/armThumb/ .

If this is not where you want the binaries, then edit the environ.sh script and change the PREFIX.

TopCreate and populate the build tree

Next is to make a directory tree to hold the sources and perform the builds: mkdir -p $HOME/ArmTools/downloads. Put the build scripts and other files you downloaded into the locations shown. Your tree will now look like this:
ArmTools/
 |-- 00setSources.sh
 |-- 01makeBinUtils.sh
 |-- 02makeBootGcc.sh
 |-- 03makeNewLib.sh
 |-- 04makeRealGcc.sh
 |-- 05makeInsight.sh
 |-- allclean.sh
 |-- downloads
 |   |-- binutils-2.16.1.tar.bz2
 |   |-- gcc-4.0.2.tar.bz2
 |   |-- gcc-4.0.2_patch.gz
 |   |-- insight-6.4.tar.bz2
 |   |-- newlib-1.13.0.tar.gz
 |   |-- newlib-1.13.0_patch.gz
 |   `-- newlib_makefile_patch.gz
 `-- environ.sh

TopBuild the tools!

Make the scripts executable: chmod u+x ArmTools/*.sh. We will now run all scripts in numerical succession, invoke them one-by-one to build each package. The first script sets the unpacks the sources into locations where the other scripts will build from.

From a user login (not as root), invoke the first script as ./00setSources.sh, and remaining scripts are also run as : ./<scriptname> (e.g. ./00setSources.sh, ./01makeBinUtils.sh, ./02makeBootGcc.sh, etc.). All scripts should complete without errors, when done, the $HOME directory will have a subdir called "devtools/armThumb/".

Note, if you wish to place the resulting binaries in a location other than what I have chosen, edit the environ.sh script and change the PREFIX location.

TopGetting ready to use the new tools

We are almost ready, but first you need to set a path to the new gcc cross compiler, binutils and insight. YMMV, each system is slightly different, on Mandrake I now edit $HOME/.bash_profile and add the new PATHs. My path statement in the .bash_profile is: PATH=$PATH:$HOME/bin:$HOME/devtools/armThumb/bin

TopFinishing up

Okay, you are done! Create an icon on your desktop to point to the Insight binary at $HOME/devtools/armThumb/bin/arm-elf-insight to have that handy. Next is to go out on the web and get a project framework (project sources) to begin building your project!

A note about the NewLib source and build tree, leave them under $HOME/devtools/armThumb/ (newlib_sources, newlib_build). By leaving those directories, you can do source level debugging of NewLib should it become necessary. However, if you don't want the various NewLib functions appearing in Insights' function list, you can safely delete those subdirs.

TopWhat not to use!

I strongly urge anyone not to use any gcc version 3.x to build Thumb code!

There is an optimizer bug (-Os) prior to version 4 which sometimes shows up as a stack corruption during interrupts. The bug is not easy to force to appear, it seems to take a number of conditions within a function source to be present. If an interrupt occurs while excuting that function, the contents of the stack will most likely be corrupted. One of the conditions which could create the bad code appears to be related to instantiating a local variable inside a code block and the size of the local is determined by a math calculation. Something like this:

void function_bad (void) {
struct ELEMENTS foobar;  // struct defined locally.
...
 for (i=0;i<MAX;i++) {  // do some test to get a variable count.
   if (some_test) foobar.elements++;
 }
 ...
 { // locally declare a variable lenght array of struct FOO.
   struct FOO foo [4 * foobar.elements];
   ...  // now we are probably in danger for stack corruption via interrupts,
   ...  // if the interrupt occurs while excuting this code!
 }
 ...  // interrupt may not affect us here.
}

I have been given code that does create this situation, it is not a myth! So, do not use gcc-3.x to generate ARM Thumb code!