Dan Kegel's crosstool is where it's at for cross-development toolchains. Unless code density is your only god, you needn't bother with ARM Ltd's own tools, if targeting Linux or Ecos.

Depending on exactly what your software does, it should be possible to compile and run most of it on x86 Linux -- at Empeg we have some code (even onto bare Xt it's not that much code) that makes an X window appear to the device as its own display, so much of the software, and particularly its UI, can be written and debugged without so much as a sniff of target hardware. (In particular, you get to use valgrind on x86 Linux.) If you've got custom hardware on the target, you could write x86 Linux "dummy" device drivers that appear to your software to be that hardware. This can also make unit-testing and other automated tests easier than use of the target device. The ARM and x86 processors are pretty similar (endianness and so on), so unless you're intending to write much ARM assembler, it should be OK. (There are a couple of ARM/x86 gotchas -- it's possible to write C that gives different results on the two. One way is to shift an int by 32 bits -- but this is implementation-defined, so don't do it! Also the in-memory representation of 64-bit doubles is different -- the 32-bit words are in the other order.)

If you're starting this from scratch, you want to look at much newer versions of gcc, glibc, and the kernel than we used on the car-player -- this may affect your ability to run stuff on a stock car-player. (Or, conversely, affect your ability to run stock Empeg code on a player you've upgraded.) If you don't want to mess with a car-player, look at getting hold of a RiscPC (with StrongARM and Ethernet upgrades) from Ebay.

Peter