On Tue, Mar 6, 2012 at 7:55 PM, Linus Walleij <linus.wall...@linaro.org> wrote: > On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope <michael.h...@linaro.org> wrote: > >> Hi Linus. Is this the arm-linux-gnueabi-gcc from the Ubuntu binary >> package? > > It's the binary package from: > https://launchpad.net/linaro-toolchain-binaries/trunk/2012.02/+download/gcc-linaro-arm-linux-gnueabi-2012.02-20120222_linux.tar.bz2 > > I'm using Fedora here so cannot really use the Ubuntu package. > But I suspect it's pretty much the same?
Yip, it uses the same configuration. The README covers the details. >> If so then the libgcc is an ARMv7 Thumb-2 VFP binary which >> won't run on an ARMv4. > > Aha! That explains everything. > >> The kernel gets around this by providing its >> own helper routines. > > Yes I noticed those helpers in the past, that explains why > my kernel is still booting fine with the same compiler. > >> Does u-boot do the same? > > Well partly it does, for example it has __div64_32() > in lib/div64.c. But the above code does no explicit calls to > that function or the others, my rough guess could be that > the arithmetic is such that libgcc gets linked implicitly, > but what do I know about GCC ... > >> The CodeSourcery toolchain is surviving as it targets ARMv5 by default >> and includes multilibs for earlier architectures? > > Yes probably. > >> What instructions are at or near 0x07fdecd4 and 07fdeb34? > > The boot monitor on the Integrator (ARMv4 system) cannot > disassemble, but the memory looks like this: > > boot Monitor > d 0x07fdecd4 > Displaying memory at 0x7FDECD4 > 0x07FDECD4: 0xF0C04770 > 0x07FDECD8: 0x42888124 > 0x07FDECDC: 0x8116F240 > 0x07FDECE0: 0xF0004211 > 0x07FDECE4: 0xFAB08117 > 0x07FDECE8: 0xFAB1F380 > 0x07FDECEC: 0xEBA2F281 > 0x07FDECF0: 0xF1C30303 > > boot Monitor > d 0x07fdeb34 > Displaying memory at 0x7FDEB34 > 0x07FDEB34: 0xE1A04000 > 0x07FDEB38: 0xEBFFFFCE > 0x07FDEB3C: 0xE0804004 > 0x07FDEB40: 0xEBFFFFCC > 0x07FDEB44: 0xE1500004 > 0x07FDEB48: 0x3AFFFFFC > 0x07FDEB4C: 0xE8BD8010 > 0x07FDEB50: 0x000F4240 Hacking this into an assembly file then running objdump over it suggests this is Thumb-2 code. I think that's the problem. Sorry I don't have a solution. We're considering multilib in the future but it's not Linaro's focus. If I were to hack around it I'd grab the libgcc.a from Fedora (v5) or Debian (v4T) and drop it in over the supplied libgcc.a. This may void your warranty :) You could try the R&M baremetal toolchain. We're working with them on the build side: https://launchpad.net/gcc-arm-embedded -- Michael _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
