[U-Boot-Users] Problem with IXDP425 u-boot.
Wolfgang Denk
wd at denx.de
Thu Jan 13 10:58:29 CET 2005
Dear Herb,
in message <1105551343.13808.475.camel at 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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Let's say the docs present a simplified view of reality... :-)
- Larry Wall in <6940 at jpl-devvax.JPL.NASA.GOV>
More information about the U-Boot
mailing list