[U-Boot-Users] Problem with IXDP425 u-boot.

[Wolfgang Denk]

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>