Hi toolchain folks,
I have a problem with U-boot compiled for an ARMv4 system (Integrator) using Linaro 2012.02-20120222, it just crashes. Compiling the same U-Boot with CodeSourcery 2010-q1 works fine.
Symptom: Resetting CPU ...
undefined instruction pc : [<07fdecd4>] lr : [<07fdeb34>] sp : 07f91380 ip : 00000000 fp : 00000001 r10: 010258fc r9 : 00000000 r8 : 07f94f64 r7 : 07f94eb0 r6 : 00989680 r5 : 000186a0 r4 : 000186a0 r3 : 000003e8 r2 : 000f423f r1 : 000f4240 r0 : 05f5e100 Flags: nzCv IRQs on FIQs on Mode SVC_32
(repeated ad nauseam)
The only hint I have is the constant 000186a0, which appears here in the put_dec() routine from U-boots vsprintf(), which is nothing special, it's Douglas Jones' binary to decimal conversion code from the Linux kernel, but the compiles objects DOES contain calls to __aeabi_uidivmod, __udivsi3, __div64_32.
Do we know of any potential trouble in these helpers on ARMv4?
The file containing these functions is compiled like this:
arm-linux-gnueabi-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x01000000 -I/var/linus/u-boot/build-integrator/include2 -I/var/linus/u-boot/build-integrator/include -I/var/linus/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/linus/src/gcc-linaro-arm-linux-gnueabi-2012.02-20120222_linux/bin/../lib/gcc/arm-linux-gnueabi/4.6.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv4 -MQ /var/linus/u-boot/build-integrator/lib/vsprintf.o vsprintf.c
/var/linus/u-boot/build-integrator/lib/.depend.vsprintf
Yours, Linus Walleij
On Tue, Mar 6, 2012 at 11:52 AM, Linus Walleij linus.walleij@linaro.org wrote:
Hi toolchain folks,
I have a problem with U-boot compiled for an ARMv4 system (Integrator) using Linaro 2012.02-20120222, it just crashes. Compiling the same U-Boot with CodeSourcery 2010-q1 works fine.
Symptom: Resetting CPU ...
undefined instruction pc : [<07fdecd4>] lr : [<07fdeb34>] sp : 07f91380 ip : 00000000 fp : 00000001 r10: 010258fc r9 : 00000000 r8 : 07f94f64 r7 : 07f94eb0 r6 : 00989680 r5 : 000186a0 r4 : 000186a0 r3 : 000003e8 r2 : 000f423f r1 : 000f4240 r0 : 05f5e100 Flags: nzCv IRQs on FIQs on Mode SVC_32
(repeated ad nauseam)
The only hint I have is the constant 000186a0, which appears here in the put_dec() routine from U-boots vsprintf(), which is nothing special, it's Douglas Jones' binary to decimal conversion code from the Linux kernel, but the compiles objects DOES contain calls to __aeabi_uidivmod, __udivsi3, __div64_32.
Do we know of any potential trouble in these helpers on ARMv4?
The file containing these functions is compiled like this:
arm-linux-gnueabi-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x01000000 -I/var/linus/u-boot/build-integrator/include2 -I/var/linus/u-boot/build-integrator/include -I/var/linus/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/linus/src/gcc-linaro-arm-linux-gnueabi-2012.02-20120222_linux/bin/../lib/gcc/arm-linux-gnueabi/4.6.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv4 -MQ /var/linus/u-boot/build-integrator/lib/vsprintf.o vsprintf.c
/var/linus/u-boot/build-integrator/lib/.depend.vsprintf
Hi Linus. Is this the arm-linux-gnueabi-gcc from the Ubuntu binary package? If so then the libgcc is an ARMv7 Thumb-2 VFP binary which won't run on an ARMv4. The kernel gets around this by providing its own helper routines. Does u-boot do the same?
The CodeSourcery toolchain is surviving as it targets ARMv5 by default and includes multilibs for earlier architectures?
What instructions are at or near 0x07fdecd4 and 07fdeb34?
-- Michaels
On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope michael.hope@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-...
I'm using Fedora here so cannot really use the Ubuntu package. But I suspect it's pretty much the same?
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
Yours, Linus Walleij
On Tue, Mar 6, 2012 at 7:55 PM, Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope michael.hope@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-...
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
On Tue, Mar 6, 2012 at 10:42 AM, Michael Hope michael.hope@linaro.org wrote:
Hacking this into an assembly file then running objdump over it suggests this is Thumb-2 code. I think that's the problem.
Probably so...
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 :)
Hehe :-)
Against all odds, this works!
I just took the libgcc.a from my old CodeSourcery 2010q1 toolchain and replaced the libgcc.a in the Linaro compiler with it and now it boots and runs like a charm.
This is a pretty insane trick but oh so convenient...
Thanks Michael!
Yours, Linus Walleij
linaro-toolchain@lists.linaro.org
-
Linus Walleij -
Michael Hope