[U-Boot-Users] Problem with IXDP425 u-boot.
I'm having some problems getting u-boot to run on the IXDP425.
I'm using ELDK 3.1 from which I installed support for the "arm-linux" target (not clearly documented I must say) which provides the GCC3.3.3 tools.
I downloaded U-Boot 1.1.2 from sourceforge.
The u-boot compile had no errors.
Using a BDI2000 to debug the u-boot code in "display_banner. The first printf in display_banner works OK and prints the line:
U-Boot 1.1.2 (Jan 11 2005 - 15:47:30)
The BDI2000 then stops:
Core#0>reset - TARGET: processing reset request - TARGET: BDI asserts RESET and TRST - TARGET: BDI removed TRST - TARGET: Bypass check: 0x000000001 => 0x00000001 - TARGET: JTAG exists check passed - Core#0: ID code is 0x19274013 - Core#0: BDI sets hold_rst and halt mode - TARGET: BDI removes RESET - Core#0: BDI sets hold_rst and halt mode again - Core#0: BDI loads debug handler to mini IC - Core#0: BDI clears hold_rst - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Core#0>go - TARGET: core #0 has entered debug mode Core#0>info Core number : 0 Core state : debug mode (THUMB) Debug entry cause : Vector Trap (UNDEFINED) Current PC : 0x00f884d6 Current CPSR : 0x800000f3 (Supervisor) Core#0>
Here's my single-step through the second call to printf in display_banner.
Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f88088 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f8808c Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f88090 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f88094 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f88098 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f8809c Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880a0 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880a4 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880a8 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880ac Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880b0 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x00f880b4 Current CPSR : 0x200000d3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (THUMB) Debug entry cause : Single Step Current PC : 0x00f87da4 Current CPSR : 0x200000f3 (Supervisor) Core#0>ti Core number : 0 Core state : debug mode (THUMB) Debug entry cause : Single Step Current PC : 0x00f878d4 Current CPSR : 0x200000f3 (Supervisor)
And here's the code (using arm-linux-objdump -D u-boot):
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.)
The code follows the flow and at 0xf880b4 executes a "blx" instruction which causes a change in flow to start at 0xf87da4 BUT EXECUTING THUMB instructions!
This code is in the middle of "srec_decode". 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)
This is part of the software floating point support for IXP425.
Any ideas?
Regards, Herb
In message 1105544287.13808.449.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.
...
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
participants (2)
-
Herb Radford -
Wolfgang Denk