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

Wolfgang Denk wd at denx.de
Wed Jan 12 18:10:26 CET 2005


In message <1105544287.13808.449.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.

...
>                                                                                 
> 00f88088 <__umodsi3>:
>   f88088:       000051e3        andeq   r5, r0, r3, ror #3
>   f8808c:       2900000a        stmcsdb r0, {r1, r3}
>   f88090:       010051e3        smlatteq        r0, r3, r1, r5
>   f88094:       01005011        tsteq   r0, r1, lsl r0
>   f88098:       0000a003        andeq   sl, r0, r3
>   f8809c:       1eff2f31        mrcne   15, 7, r2, cr15, cr1, {1}
>   f880a0:       0130a0e3        teqeq   r0, r3, ror #1
>   f880a4:       010251e3        smlatteq        r2, r3, r1, r5
>   f880a8:       00005131        andeq   r5, r0, r1, lsr r1
>   f880ac:       0112a031        tsteq   r2, r1, lsr r0
>   f880b0:       0332a031        teqeq   r2, #49 ; 0x31
>   f880b4:       faffff3a        blx     f87da4 <srec_decode+0xbc>
>   f880b8:       020151e3        andeq   r5, r1, #-1073741768    ;
> 0xc0000038
>   f880bc:       00005131        andeq   r5, r0, r1, lsr r1
>   f880c0:       8110a031        tsthi   r0, r1, lsr r0
>   f880c4:       8330a031        teqhi   r0, #49 ; 0x31
>   f880c8:       faffff3a        blx     f87db8 <srec_decode+0xd0>
>   f880cc:       0020a0e3        eoreq   sl, r0, r3, ror #1
>   f880d0:       010050e1        smlatteq        r0, r1, r0, r5
>   f880d4:       01004020        tsteq   r0, r0, lsr #32
>   f880d8:       a10050e1        smlattge        r0, r1, r0, r5
>                                                                                 
> Note that a large number of instructions have the "condition" field
> (bits 28-31)set to EQ - not a common occurrence in "real" code.
> Most "real" code has this field set to AL (always or unconditional.)

This is probably a bug with by objdump; I  see  the  same  here  when
disassembling the "u-boot" ELF file:

00f8e348 <__umodsi3>:
  f8e348:       000051e3        andeq   r5, r0, r3, ror #3
  f8e34c:       2900000a        stmcsdb r0, {r1, r3}
  f8e350:       010051e3        smlatteq        r0, r3, r1, r5
  f8e354:       01005011        tsteq   r0, r1, lsl r0
  f8e358:       0000a003        andeq   sl, r0, r3
  f8e35c:       1eff2f31        mrcne   15, 7, r2, cr15, cr1, {1}
  f8e360:       0130a0e3        teqeq   r0, r3, ror #1
  f8e364:       010251e3        smlatteq        r2, r3, r1, r5
  f8e368:       00005131        andeq   r5, r0, r1, lsr r1
  f8e36c:       0112a031        tsteq   r2, r1, lsr r0
  f8e370:       0332a031        teqeq   r2, #49 ; 0x31
  f8e374:       faffff3a        blx     f8e064 <srec_decode+0xbc>


But obviously it makes no sense to have a reference to srec_decode in
a divide routine. And when looking at the object file this looks like
this:

-> arm-linux-objdump -D lib_arm/_umodsi3.o

lib_arm/_umodsi3.o:     file format elf32-bigarm

Disassembly of section .text:

00000000 <__umodsi3>:
   0:   e3510000        cmp     r1, #0  ; 0x0
   4:   0a000027        beq     a4 <Ldiv0>
   8:   e3a03001        mov     r3, #1  ; 0x1
   c:   e1500001        cmp     r0, r1
  10:   31a0f00e        movcc   pc, lr

00000014 <Loop1>:
  14:   e3510201        cmp     r1, #268435456  ; 0x10000000
  18:   31510000        cmpcc   r1, r0
  1c:   31a01201        movcc   r1, r1, lsl #4
  20:   31a03203        movcc   r3, r3, lsl #4
  24:   3a000003        bcc     14 <Loop1>

...which matches the source code.

Seems to be some endianess problem in objdump or so...

[Maybe we should rename it into objdumb ;-) ]

> This code is in the middle of "srec_decode".

And this doesn't make you nervous?

> The code at __umodsi3 (0xf88088) looks like it was compiled for the
> Thumb instruction set. What's up with that??
>                                                                                 
> This code is pulled in from this library:
> /opt/eldkarm31/usr/bin/../lib/gcc-lib/arm-linux/3.3.3/libgcc.a(_umodsi3.o)

Are you absolutely sure about this? I think it comes from
lib_arm/_umodsi3.o !

> 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.

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
That was the thing about deserts. They had their  own  gravity.  They
sucked you into the centre.           - Terry Pratchett, _Small Gods_




More information about the U-Boot mailing list