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