GNU ARM7 toolchain for FreeCalypso

[Mychaela Falconia]

Hello my dear ones,

I got a few thoughts regarding the toolchain in the subject line:

1. Right now both target-utils and gsm-fw use a few libc functions
   from newlib, the latter being the C library built as part of our
   toolchain.  But newlib's implementation of this very small subset
   of libc we need is starting to be a bit of a pita, and I am
   starting to feel that we would be better off if our fw were
   completely self-contained, i.e., provided its own implementations
   of the few libc functions and headers it needs.  As it is we have
   to override newlib versions of some functions (printf and sprintf
   most prominently) with our own implementations, so why not use our
   own throughout?

   In my past self-contained OS-less firmware projects for M68K and
   PowerPC processors I always put my own libc implementation (the
   tiny subset of libc that is actually needed) into the project, and
   the toolchains were built without newlib, with just binutils and
   gcc.  When I started FreeCalypso in the spring of 2013 I took the
   newlib route because I felt like trying something different, and
   also because I was copying OsmocomBB's toolchain at that point: I
   was eager to start hacking on the Calypso and didn't feel like
   dealing with toolchain issues.

   But now I feel that it may be the right time to take the time
   (excuse the pun) to remove newlib from our set of dependencies,
   switch to using a newlib-less toolchain with just binutils and gcc,
   and add the necessary subset-libc implementations to target-utils
   and gsm-fw.

2. Right now the target prefix we use is arm-elf-, i.e., the toolchain
   binaries are named arm-elf-gcc and so on.  These arm-elf-gcc,
   arm-elf-ld etc names are hard-coded in every Makefile under both
   target-utils and gsm-fw.  But now I'm thinking that it would be
   easier to install our toolchain system-wide (more specific binary
   names, less system namespace pollution) if we changed our target
   prefix to arm7-elf, so we would have arm7-elf-gcc and so on.  The
   toolchain is already made specific to ARM7TDMI when we build gcc
   --with-cpu=arm7tdmi, so we may as well reflect this ARM7 specificity
   in the name.

   There aren't too many things out there any more with ARM7 cores
   besides our beloved TI GSM baseband processors ("modern" basebands,
   even 2G-only ones, have all switched to ARM926 or something else),
   so we can pretty much take arm7-elf-gcc as meaning FreeCalypso. :)

   I'm thinking it would be the easiest to make the transition from
   arm-elf-gcc etc to arm7-elf-gcc etc at the same time as the
   transition from newlib to our own in-tree nano-libc: make our
   target-utils and gsm-fw independent of toolchain-provided libc
   first, then build an arm7-elf toolchain without newlib, then change
   all the Makefiles from arm-elf-* to arm7-elf-*.

3. Das Signal wrote here recently about his experience with building
   the GNU ARM7 toolchain for FreeCalypso under a new Debian system:
   he got it to build, but he had to fix a couple of issues first
   where the too-finicky system gcc etc were complaining about
   something in the older versions of binutils and gcc which we need
   for the target.

   DS proposed a couple of patches to the toolchain build scripts in
   freecalypso-sw, but I have an even better idea: instead of gumming
   the toolchain build scripts in freecalypso-sw up with more and more
   patches to support capricious "modern" systems, why not make deb,
   rpm etc packages of the arm7-elf FreeCalypso toolchain for those
   systems?

DS, you use Debian, right?  Am I thinking right that if you were to
make a deb package for our arm7-elf toolchain, then any user of either
Debian or Ubuntu could just install that deb and have arm7-elf-gcc etc
on her system without any fuss?  If so, then I think we should do that
after I make the two changes proposed above: newlib elimination and
the change from arm-elf to arm7-elf.

Comments, suggestions, alternative ideas are welcome.

M~