[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: M0 and M3 patches in linaro toolchains

+++ Matthew Gretton-Dann [2013-08-19 16:58 +0100]:
> On 19 August 2013 15:04, Wookey <wookey@wookware.org> wrote:
> > Debconf13 (last week) considered the matter of bare-metal
> > cross-toolchains in Debian.

> > The linaro embedded toolchains
> > (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are
> > good, and work, both for M0 and M3. But building nominally the same
> > thing from upstream gcc gets something where M3 works but M0 doesn't.
> OK - These aren't Linaro owned tools.  They are produced by ARM.  We
> link to them to make sure people can find the tools they need.

Aha. I had assumed it was something linaro was now doing. I'll see if
I can find some more details inside ARM then.

> Can you expand (possibly in a separate thread) on "M3 works but M0
> doesn't"? I'd expect the gcc-arm-embedded tools to support all
> M-profile cores out of the box.

You misread (or I was unclear). The arm-provided toolchain referenced
above does indeed work for M3 and M0. It's a toolchain built from
debian sources that doesn't work for M0. Keithp did the tests and has
the details of exactly what he tested. (are we talking 4.7 or 4.8 (or
both) here keith?)

> > Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default.
> If history is anything to go by there will be a 4.8 release of that
> toolchain sometime in Q4 2013.

OK, that will be useful but another big code dump with a huge diff is
only a partial solution. We really want to get to see which important
bits are actually missing in Debian.

> The Linaro branch for 4.8 is in the main SVN repository for GCC:
>   svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch

OK. And do you think that should support M0 and M3 correctly already?
Do we expect M0/M3 support there to be good? Or should I ask Joey
these questions?

Debian is currently using 4.8.1 (with a pile of packaging patches and
some backported fixes). So I guess the question really is whether that
is expected to work.

> And we use svn merge to keep track of merge data.
> We work by getting patches accepted into trunk and then backporting
> them - so every substantive patch is a backport from trunk.  There are
> some patches in the Linaro branch which are not also in trunk - but
> these all relate to release stuff - and so don't make any difference
> to the code generation.

OK, that's helpful.

> Personally, even if you end up just using the Debian patchset by
> default (which will not be a terrible starting point), you should take
> a look at the way the GCC ARM Embedded toolchain configures multilib
> for bare-metal.  These are a good starting point for choosing a set of
> multilibs to build.


Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: