Gnu tools for ARM Cortex development
in [Embedded]
|
Prev: Simulation of ARM7TDMI-S
Next: Which controller to use?
From: Tim Wescott on 4 May 2010 14:09 Is anyone out there doing development for the ARM Cortex (specifically the m3) with the Gnu tools? Are you using the CodeSourcery set, or are you building your own? If so, how are things going? There seems to be a welter of "how to" pages on this, but nearly all of them seem to be as old as the hills. My spare-time job right now is bringing up a set of tools that'll work on Linux and will let me develop on the TI LM3S811. I'm trying to keep everything 100% open source; since CodeSourcery is exceedingly coy about coughing up source code (I certainly haven't found it) and because their install scripts don't seem to be terribly compatible with my Linux installation (Ubuntu Karmic) I'm building from scratch. Things seem to be going well, although not completely straightforward -- my current task is to write or find the obligatory startup code to establish a C++ run-time environment so that the rest of my code will work, and to verify that OpenOCD really does function on this machine. Aside from "you're crazy, see a shrink!" does anyone have any useful observations on the process? Any known-fresh web pages? TIA -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: David Brown on 4 May 2010 15:02 Tim Wescott wrote: > Is anyone out there doing development for the ARM Cortex (specifically > the m3) with the Gnu tools? > > Are you using the CodeSourcery set, or are you building your own? > I'm working with CodeSourcery Cortex tools at the moment, but I've barely got started. I have the "personal" license version, which comes with Eclipse and some integration, and extra debugger interfaces. In practice I suspect I will use the "lite" version as much as anything else, since it is not locked to any given system, and since I prefer more manual configuration and command lines anyway. > If so, how are things going? There seems to be a welter of "how to" > pages on this, but nearly all of them seem to be as old as the hills. > > My spare-time job right now is bringing up a set of tools that'll work > on Linux and will let me develop on the TI LM3S811. I'm trying to keep > everything 100% open source; since CodeSourcery is exceedingly coy about > coughing up source code (I certainly haven't found it) and because their > install scripts don't seem to be terribly compatible with my Linux > installation (Ubuntu Karmic) I'm building from scratch. > CodeSourcery does try to encourage people towards their paid-for packages, understandably enough. But their "lite" versions are totally free in cost, and pretty much entirely open source (there may be a few utilities or debug connectors that don't come with the source code, but nothing more than that). There are also source tarballs as well as binary installers for Linux and Windows. <http://www.codesourcery.com/sgpp/lite/arm> <http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite> <http://www.codesourcery.com/sgpp/lite/arm/portal/release1294> Even their paid-for subscription versions have source tarballs - you can re-compile them yourself with the node-locking code disabled if you want (the debug sprites don't all have source code, however). Also, everything CodeSourcery does in the main tools (gcc, binutils, gdb) goes back to the FSF trees - they are the maintainers for various gcc ports including ARM. However, their own branches that you get directly from them are updated faster, as they don't have to keep everything in sync for all ports, and they also have more comprehensive test suites (again, because they don't have to support everything at once). Their discussion lists are open to all who register at their site, and the CodeSourcery developers are very helpful. For building this sort of thing, I'd recommend using virtual machines - install Virtual Box (it's free, and runs on Linux and Windows) and make your build machines as virtual installations. That way you can easily try out different distros and keep your test builds isolated and under control. Sometimes these things work better with particular versions of particular tools (though gcc should build cleanly with most tool versions), and with virtual machines for testing you can avoid messing around with different versions of gcc on your main machine. > Things seem to be going well, although not completely straightforward -- > my current task is to write or find the obligatory startup code to > establish a C++ run-time environment so that the rest of my code will > work, and to verify that OpenOCD really does function on this machine. > > Aside from "you're crazy, see a shrink!" does anyone have any useful > observations on the process? Any known-fresh web pages? > Just remember, you're doing this for fun - and building gcc /is/ fun (if you don't want the fun, pay your $400 and get a ready-to-run binary with support from CodeSourcery). Every hurdle on the way is a learning opportunity, and you'll end up understanding your tools better after you've built them. Also, keep notes under way - there's nothing more annoying than getting your build to work but forgetting what you did to get there... mvh., David
From: Grant Edwards on 4 May 2010 15:18 On 2010-05-04, Tim Wescott <tim(a)seemywebsite.now> wrote: > Is anyone out there doing development for the ARM Cortex (specifically > the m3) with the Gnu tools? I've used CodeSourcery light for ARM Coretex M3 and for ARM9. I haven't used either one extensively, but the seem to be solid enough to me. > Are you using the CodeSourcery set, or are you building your own? I do both. For building my own, I've used home-grown scripts as well as Crosstool-NG. Both work fine. > If so, how are things going? Fine. > There seems to be a welter of "how to" pages on this, but nearly all > of them seem to be as old as the hills. > > My spare-time job right now is bringing up a set of tools that'll work > on Linux and will let me develop on the TI LM3S811. I'm trying to keep > everything 100% open source; since CodeSourcery is exceedingly coy about > coughing up source code (I certainly haven't found it) I agree that they don't make it easy to get source code from them. > and because their > install scripts don't seem to be terribly compatible with my Linux > installation (Ubuntu Karmic) I'm building from scratch. For the lite edition, installtion consists entirely of unpacking a tar archive anywhere you like. If you want to build your own with libc, crosstool-NG works well. If you just want a bare-metal compiler (with no libc) that's pretty trivial to do on your own. Building with newlib isn't that much more difficult. -- Grant Edwards grant.b.edwards Yow! Will this never-ending at series of PLEASURABLE gmail.com EVENTS never cease?
From: Oliver Betz on 4 May 2010 16:19 David Brown wrote: [...] >Even their paid-for subscription versions have source tarballs - you can >re-compile them yourself with the node-locking code disabled if you want Sure? As far as I understand, you don't get the library sources in the personal version. Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
From: John Devereux on 4 May 2010 16:54
David Brown <david.brown(a)hesbynett.removethisbit.no> writes: [...] > > > For building this sort of thing, I'd recommend using virtual machines > - > install Virtual Box (it's free, and runs on Linux and Windows) and > make your build machines as virtual installations. That way you can > easily try out different distros and keep your test builds isolated > and under control. Sometimes these things work better with particular > versions of particular tools (though gcc should build cleanly with > most tool versions), and with virtual machines for testing you can > avoid messing around with different versions of gcc on your main > machine. That seems like a lot of work - I just set the PREFIX in the build script and use that path subsequently in project makefiles. E.g. install to /opt/arm-elf-4.4.0. You can also set CC before building if you want to build with a different compiler version. Lately I've been archiving the entire compiler along with each projects source code. That is, the stripped toolchain binaries are in a subdirectory of the project and are put under revision control along with it. Also there is a compiler build script as part of the project which can fetch the source code and rebuild the compiler if needed. [...] -- John Devereux |