-----Original Message----- From: Wookey [mailto:wookey@wookware.org] Sent: Tuesday, August 20, 2013 0:31 To: linaro-dev@lists.linaro.org; Embedded Debian Cc: Joey Ye Subject: 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.
It is still a fully open source project though. svn://gcc.gnu.org/branches/arm/embedded-4_8-branch/gcc/ChangeLog.arm listed everything diff to FSF 4.8 branch.
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?)
I'm not sure what blocked M0. There are a few things suspicious: * Which C library is used? The one gcc-arm-embedded works, and the only one I know works for Cortex-M, is newlib. Other than that, good luck :-( * What is the newlib version, if you are using newlib. There were some patches for M0 when we enabled gcc-arm-embedded. But all of them are in latest newlib mainline now.
Overall, sharing a source between arm-linux and arm-none-eabi sounds a good idea, but library can be the road blocker. As bare-metal version should use newlib and linux use glibc, it is not that straight-forward as assumed. Please be aware of this extra burden.
Alternative approach is just grab the gcc-arm-embedded 4.8, which will be ready by Q4, and build it for debian. It will be straight forward as it is already built and released by launchpad as debian package and distributed as PPA. Also it will behavior the same as any other gcc-arm-embedded running on other linux distribution and Windows, which have been downloaded 100,000 copies.
I'm OK with both approaches but I believe the latter makes more sense.
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.
Yes, 4.8 will be release in Q4 this year. The arm/embedded-4_8-branch is now under development and will be the release branch by then.
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.
As I mentioned in another email, everything is at svn://gcc.gnu.org/branches/arm/embedded-4_x-branch/gcc/ChangeLog.arm given that you got correct newlib. Major stuff to make it work is multilib support, which is a piece of Makefile fragment to build library for armv6-m/7-m/7-a/7-r.
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?
Again, I'm not sure what blocked M0. I'm interested to know more details about this.
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.
Should work with multilib Makefile fragment and correct newlib version
Regards, Joey
Joey Ye joey.ye@arm.com writes:
I'm not sure what blocked M0. There are a few things suspicious:
- Which C library is used? The one gcc-arm-embedded works, and the only one
I know works for Cortex-M, is newlib. Other than that, good luck :-(
I'm using pdclib, which is not the best solution in most ways except that it's very portable :-)
Overall, sharing a source between arm-linux and arm-none-eabi sounds a good idea, but library can be the road blocker. As bare-metal version should use newlib and linux use glibc, it is not that straight-forward as assumed. Please be aware of this extra burden.
I've packaged a bare gcc which doesn't reference *any* libc, allowing the user to select the best libc for their project. We could separately package both newlib and pdclib for various targets if we liked?
Alternative approach is just grab the gcc-arm-embedded 4.8, which will be ready by Q4, and build it for debian. It will be straight forward as it is already built and released by launchpad as debian package and distributed as PPA. Also it will behavior the same as any other gcc-arm-embedded running on other linux distribution and Windows, which have been downloaded 100,000 copies.
I've grabbed the 4.7 q2 version for now and packaged that; I looked at the diffs from the 4.8 embedded tree to the current Debian 4.8 gcc sources and they were huge (700k line patch). I didn't analyze that further; perhaps it's mostly spurious?
Again, I'm not sure what blocked M0. I'm interested to know more details about this.
I can look at this in more detail if desired. I was getting a CPU fault (presumably from executing some non -M0 instructions) with the Debian bits compiled in precisely the same way as I am now successfully building the Linaro -q2 bits.
-keith
-
Joey Ye -
Keith Packard