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
Attachment:
pgpCfjJnNDpU9.pgp
Description: PGP signature