[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