Re: [U-Boot-Users] Problem with IXDP425 u-boot.
Dear Herb,
in message 1105551343.13808.475.camel@hr2600.symbium.com you wrote:
I'm using ELDK 3.1 from which I installed support for the "arm-linux" target (not clearly documented I must say) which
What exactly is "not clearly documented"? I'd like to improve this.
Wolfgang, the README file in ELDK3.1 says to specify a <cpu_family> so I tried "XScale" and got a failure. I had to go to the "Working with ELDK" section to find out that there is in fact ONLY ONE possible choice for <cpu_family> and it is used by all ARM targets!
I see. Will fix this ASAP.
Of course it makes me nervous, and when I look in u-boot.map it's not attributed to the local u-boot tree! Here's the u-boot.map line:
/opt/eldkarm31/usr/bin/../lib/gcc-lib/arm-linux/3.3.3/libgcc.a(_umodsi3.o)
This is indeed an interesting hint. Especially when you look at this object file:
-> arm-linux-objdump -D libgcc.a ... _umodsi3.o: file format elf32-littlearm ------------------------------------------^^^^^^^^^ Disassembly of section .text: 00000000 <__umodsi3>: 0: e3510000 cmp r1, #0 ; 0x0 4: 0a00002a beq b0 <__umodsi3+0xb0> 8: e3510001 cmp r1, #1 ; 0x1 c: 11500001 cmpne r0, r1 10: 03a00000 moveq r0, #0 ; 0x0 14: 312fff1e bxcc lr 18: e3a03001 mov r3, #1 ; 0x1 1c: e3510201 cmp r1, #268435456 ; 0x10000000 20: 31510000 cmpcc r1, r0 24: 31a01201 movcc r1, r1, lsl #4 28: 31a03203 movcc r3, r3, lsl #4
This explains why you see bogus code - this file is for little endian systems, while your board is built for bigendian mode.
Mixing these two doesn't make much sense.
This is part of the software floating point support for IXP425.
No, this has nothing to do with FP support. It's a simple division routine.
OK, then why does my IXP425 switch to Thumb mode when it executes:
28: e3510102 cmp r1, #-2147483648 ; 0x80000000
Because it doesn't understand that this is actually a "cmp r1, #0" instruction in wrong endianess.
Any ideas?
Yes. Find out why we use libgcc.a(_umodsi3.o) instead of lib_arm/libarm.a(_umodsi3.o) when building for bigendian systems.
Best regards,
Wolfgang Denk
On Thu, 2005-01-13 at 04:58, Wolfgang Denk wrote:
Dear Herb,
in message 1105551343.13808.475.camel@hr2600.symbium.com you wrote:
I'm using ELDK 3.1 from which I installed support for the "arm-linux" target (not clearly documented I must say) which
What exactly is "not clearly documented"? I'd like to improve this.
Wolfgang, the README file in ELDK3.1 says to specify a <cpu_family> so I tried "XScale" and got a failure. I had to go to the "Working with ELDK" section to find out that there is in fact ONLY ONE possible choice for <cpu_family> and it is used by all ARM targets!
I see. Will fix this ASAP.
Of course it makes me nervous, and when I look in u-boot.map it's not attributed to the local u-boot tree! Here's the u-boot.map line:
/opt/eldkarm31/usr/bin/../lib/gcc-lib/arm-linux/3.3.3/libgcc.a(_umodsi3.o)
This is indeed an interesting hint. Especially when you look at this object file:
-> arm-linux-objdump -D libgcc.a ... _umodsi3.o: file format elf32-littlearm ------------------------------------------^^^^^^^^^
Disassembly of section .text:
00000000 <__umodsi3>: 0: e3510000 cmp r1, #0 ; 0x0 4: 0a00002a beq b0 <__umodsi3+0xb0> 8: e3510001 cmp r1, #1 ; 0x1 c: 11500001 cmpne r0, r1 10: 03a00000 moveq r0, #0 ; 0x0 14: 312fff1e bxcc lr 18: e3a03001 mov r3, #1 ; 0x1 1c: e3510201 cmp r1, #268435456 ; 0x10000000 20: 31510000 cmpcc r1, r0 24: 31a01201 movcc r1, r1, lsl #4 28: 31a03203 movcc r3, r3, lsl #4
This explains why you see bogus code - this file is for little endian systems, while your board is built for bigendian mode.
Mixing these two doesn't make much sense.
This is part of the software floating point support for IXP425.
No, this has nothing to do with FP support. It's a simple division routine.
OK, then why does my IXP425 switch to Thumb mode when it executes:
28: e3510102 cmp r1, #-2147483648 ; 0x80000000
Because it doesn't understand that this is actually a "cmp r1, #0" instruction in wrong endianess.
Any ideas?
Yes. Find out why we use libgcc.a(_umodsi3.o) instead of lib_arm/libarm.a(_umodsi3.o) when building for bigendian systems.
Best regards,
Wolfgang Denk
Wolfgang, I didn't find out why libgcc.a is used for big-endian systems, I found line #124 was causing this. I don't know what PLATFORM_LIBS is really used for but by commenting that line out, u-boot comes up just fine.
Now on to PCI for this board!
(And that's going to be another thread!)
Regards, Herb
participants (2)
-
Herb Radford -
Wolfgang Denk