[U-Boot-Users] Problem with IXDP425 u-boot.
Herb Radford
hradford at symbium.com
Wed Jan 12 16:38:07 CET 2005
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
More information about the U-Boot
mailing list