Strategy for packaging an ARM Cortex-M toolchain

Rob Spanton rspanton at zepler.net
Wed May 23 16:07:27 UTC 2012


Hi,

There are an increasing number of ARM Cortex-M based boards around, and
I'd like to get a cross-compilation toolchain for them into the Fedora
repositories.  I'd like to make it just as easy to compile for Cortex-M
chips under Fedora as it is to compile for AVR or MSP430 targets right
now (i.e. `yum install ...`).

So I've cobbled together packages for a prototype toolchain [1],
consisting of binutils, gcc, newlib and gdb.  Currently with the
target-triplet "arm-none-eabi", which I think I'll be changing to
"arm-cortex_m-eabi".

I'd like to avoid this toolchain conflicting with, or duplicating the
effort put into other cross-compilation toolchains that are currently in
Fedora.

There are two things that I can think of that this cortex-m3 toolchain
might interact with at the moment:
     1. The arm-gp2x-linux toolchain currently in the repositories.
     2. Any cross-compilation toolchains generated by the Fedora ARM
        {primary,secondary} architecture stuff that's happening.

I think the binutils and gdb builds for these things would be
practically identical to the cortex-m one.  So it might be sensible for
them to share the same binutils and gdb packages.  Maybe ABI differences
would make it impossible to use the same gdb, but I'm not sure about
that.

Since these platforms use different C libraries (the Linux-based ones
use glibc, and the cortex-m one uses newlib built and optimised for
cortex-m), it's not possible for these platforms to use the same gcc or
C library packages.

So is it best to attempt to get one arm-binutils package and remove
redundancy, or is it going to be more productive to just put up with the
redundancy for now?

Cheers,

Rob

[1] http://users.ecs.soton.ac.uk/rds/rpm/arm-none-eabi/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120523/fe02be06/attachment.sig>


More information about the devel mailing list