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