Bombing U-Boot on ARMv4, any hints?
michael.hope at linaro.org
Tue Mar 6 09:42:02 UTC 2012
On Tue, Mar 6, 2012 at 7:55 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope <michael.hope at linaro.org> wrote:
>> Hi Linus. Is this the arm-linux-gnueabi-gcc from the Ubuntu binary
> It's the binary package from:
> 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:
More information about the linaro-toolchain