[ECOS] RedBoot hits fetch instruction trap
Les Miklosy
lgm0@verizon.net
Wed Jul 30 05:24:00 GMT 2014
During execution of RedBoot configured for a Sparc Leon3 IP core the
process hits a trap on instruction fetch in the RedBoot routine
_timer_poll(). The debugger history and assembly are attached. The
process will execute RedBoot commands at the command prompt and
otherwise behave normally until a branch instruction to do_idle and
subsequently net_io_test(), that is where execution eventually fails.
Oddly the process runs without fault when DEBUG command options are
selected during configuration of the build with configtool, trouble
begins when the DEBUG options are again removed. The DEBUG instructions
appear in the ethernet modules and in RedBoot's net_io. If this is a
timing issue can someone please suggest what parameters can be tweeked
to resolve the traps, or if a memory alignment problem can someone offer
a memory map and alignment parameters? Are there configuration
selections in the amba bus header file, those might be helpful too.
The compiler is sparc-elf-gcc-3.4.4 I'm using two additional
compilation flags -msoft-float and D-ECOS. The system configuration is
also attached to this email. Thank you for directions. -Les
-------------- next part --------------
grlib> info sys
00.01:003 Gaisler Research LEON3 SPARC V8 Processor (ver 0x0)
ahb master 0
01.01:007 Gaisler Research AHB Debug UART (ver 0x0)
ahb master 1
apb: 80000700 - 80000800
baud rate 115200, ahb frequency 40.00
02.01:01c Gaisler Research AHB Debug JTAG TAP (ver 0x0)
ahb master 2
03.01:01d Gaisler Research GR Ethernet MAC (ver 0x0)
ahb master 3, irq 13
apb: 80000d00 - 80000e00
edcl ip 192.168.0.51, buffer 2 kbyte
00.04:00f European Space Agency LEON2 Memory Controller (ver 0x1)
ahb: 00000000 - 20000000
ahb: 20000000 - 40000000
ahb: 40000000 - 80000000
apb: 80000000 - 80000100
8-bit prom @ 0x00000000
32-bit sdram: 1 * 64 Mbyte @ 0x40000000, col 9, cas 2, ref 7.8 us
01.01:006 Gaisler Research AHB/APB Bridge (ver 0x0)
ahb: 80000000 - 80100000
02.01:004 Gaisler Research LEON3 Debug Support Unit (ver 0x1)
ahb: 90000000 - a0000000
AHB trace 128 lines, stack pointer 0x43fffff0
CPU#0 win 8, hwbp 2, itrace 128, V8 mul/div, srmmu, lddel 1
icache 2 * 4 kbyte, 32 byte/line lru
dcache 1 * 4 kbyte, 16 byte/line lru
01.01:00c Gaisler Research Generic APB UART (ver 0x1)
irq 2
apb: 80000100 - 80000200
baud rate 38400
02.01:00d Gaisler Research Multi-processor Interrupt Ctrl (ver 0x3)
apb: 80000200 - 80000300
03.01:011 Gaisler Research Modular Timer Unit (ver 0x0)
irq 8
apb: 80000300 - 80000400
8-bit scaler, 2 * 32-bit timers, divisor 40
08.01:01a Gaisler Research General purpose I/O port (ver 0x0)
apb: 80000800 - 80000900
grlib>
-------------- next part --------------
__timer_poll(void)
{
40011b94: 9d e3 bf 98 save %sp, -104, %sp
timer_t *prev, *t;
prev = NULL;
t = tmr_list;
40011b98: 11 10 00 94 sethi %hi(0x40025000), %o0
40011b9c: e0 02 22 38 ld [ %o0 + 0x238 ], %l0 ! 40025238 <tmr_list>
while (t) {
40011ba0: 80 a4 20 00 cmp %l0, 0
40011ba4: 02 80 00 1d be 40011c18 <__timer_poll+0x84>
40011ba8: a2 10 20 00 clr %l1
40011bac: a4 10 00 08 mov %o0, %l2
if ((MS_TICKS_DELAY() - t->start) >= t->delay) {
40011bb0: 7f ff f5 8c call 4000f1e0 <do_ms_tick>
40011bb4: 01 00 00 00 nop
40011bb8: d2 04 20 08 ld [ %l0 + 8 ], %o1
40011bbc: d4 04 20 04 ld [ %l0 + 4 ], %o2
40011bc0: 90 22 00 09 sub %o0, %o1, %o0
40011bc4: 80 a2 00 0a cmp %o0, %o2
40011bc8: 2a 80 00 12 bcs,a 40011c10 <__timer_poll+0x7c>
40011bcc: a2 10 00 10 mov %l0, %l1
/* remove it before calling handler */
if (prev)
40011bd0: 80 a4 60 00 cmp %l1, 0
40011bd4: 02 80 00 0d be 40011c08 <__timer_poll+0x74>
40011bd8: d0 04 00 00 ld [ %l0 ], %o0
prev->next = t->next;
40011bdc: d0 24 40 00 st %o0, [ %l1 ]
else
tmr_list = t->next;
/* now, call the handler */
t->handler(t->user_data);
40011be0: d0 04 20 10 ld [ %l0 + 0x10 ], %o0
40011be4: d2 04 20 0c ld [ %l0 + 0xc ], %o1
40011be8: 9f c2 40 00 call %o1
40011bec: a2 10 20 00 clr %l1
-------------- next part --------------
grlib> c
IU in error mode (tt = 0x01)
a80ceff0 0ceff000 unknown opcode: 0x0ceff000
grlib> hist
91756041 40011bc8 bcs,a 0x40011c10 [00000000]
91756043 40011bd0 cmp %l1 [80000200]
91756053 40011bd4 be 0x40011c08 [00000000]
91756059 ahb read, mst=0, size=2 [40011bfc 12bfffed]
91756130 ahb read, mst=0, size=2 [00002000 a7580000]
91756132 40011bd8 ld [%l0], %o0 [a7580000]
91756134 40011bdc st %o0, [%l1] [80000200 a7580000]
91756136 ahb write, mst=0, size=2 [80000200 a7580000]
91756206 ahb read, mst=0, size=2 [00002010 a7580000]
91756208 40011be0 ld [%l0 + 0x10], %o0 [a7580000]
91756278 ahb read, mst=0, size=2 [0000200c a80ceff0]
91756279 40011be4 ld [%l0 + 0xc], %o1 [a80ceff0]
91756283 ahb read, mst=0, size=2 [a80ceff0 0ceff0f0]
91756284 40011be8 call %o1 [40011be8]
91756285 ahb read, mst=0, size=2 [a80ceff4 0ceff0f0]
91756286 40011bec mov 0, %l1 [00000000]
91756287 ahb read, mst=0, size=2 [a80ceff8 0ceff0f0]
91756289 ahb read, mst=0, size=2 [a80ceffc 0ceff0f0]
91756294 ahb read, mst=0, size=2 [a80cf000 0ceff0f0]
91756295 a80ceff0 unknown opcode: 0x0ceff0f0 [trapped]
grlib>
-------------- next part --------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list