* [ECOS] RedBoot hits fetch instruction trap
@ 2014-07-30 5:24 Les Miklosy
2014-07-30 6:36 ` Kurt Siedenburg
0 siblings, 1 reply; 5+ messages in thread
From: Les Miklosy @ 2014-07-30 5:24 UTC (permalink / raw)
To: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
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
[-- Attachment #2: info_sys.txt --]
[-- Type: text/plain, Size: 1854 bytes --]
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>
[-- Attachment #3: timer_poll.txt --]
[-- Type: text/plain, Size: 1606 bytes --]
__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
[-- Attachment #4: timer_trap.txt --]
[-- Type: text/plain, Size: 1451 bytes --]
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>
[-- Attachment #5: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [ECOS] RedBoot hits fetch instruction trap
2014-07-30 5:24 [ECOS] RedBoot hits fetch instruction trap Les Miklosy
@ 2014-07-30 6:36 ` Kurt Siedenburg
2014-07-30 21:25 ` Les Miklosy
2014-07-31 6:22 ` Les Miklosy
0 siblings, 2 replies; 5+ messages in thread
From: Kurt Siedenburg @ 2014-07-30 6:36 UTC (permalink / raw)
To: Les Miklosy, ecos-discuss
I once had a similar problem which turned out to be unaligned instructions.
Source was an assembly file with embedded strings which didn't contain proper alignment directives.
Thus a modified string now contained an odd number of characters. And the instructions after that string all became unaligned.
Please note that I never dealt with Sparc - only with ARM and MIPS and some x86. So I don't know if the above applies in your case.
If you want to follow up on this you can look at your map file.
Check if the addresses for _timer_poll, do_idle, and net_io_test happens to be odd (with DEBUG disabled).
Possibly with DEBUG enabled the addresses could be aligned again.
Good luck,
Kurt
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Les Miklosy
Sent: Tuesday, July 29, 2014 10:19 PM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] RedBoot hits fetch instruction trap
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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] RedBoot hits fetch instruction trap
2014-07-30 6:36 ` Kurt Siedenburg
@ 2014-07-30 21:25 ` Les Miklosy
2014-07-31 6:22 ` Les Miklosy
1 sibling, 0 replies; 5+ messages in thread
From: Les Miklosy @ 2014-07-30 21:25 UTC (permalink / raw)
To: Kurt Siedenburg; +Cc: ecos-discuss
The dump file shows address boundaries are even for my three suspect
functions, the remaining functions appear on even boundaries too. But I
do suspect my memory map. I don't have a good template to start from so
after many experiments I'm using a map with no confidence. I'll do some
checking and report back here, thank you for the tip Kurt.
Les
On 07/29/2014 11:35 PM, Kurt Siedenburg wrote:
> I once had a similar problem which turned out to be unaligned instructions.
> Source was an assembly file with embedded strings which didn't contain proper alignment directives.
> Thus a modified string now contained an odd number of characters. And the instructions after that string all became unaligned.
>
> Please note that I never dealt with Sparc - only with ARM and MIPS and some x86. So I don't know if the above applies in your case.
>
> If you want to follow up on this you can look at your map file.
> Check if the addresses for _timer_poll, do_idle, and net_io_test happens to be odd (with DEBUG disabled).
> Possibly with DEBUG enabled the addresses could be aligned again.
>
> Good luck,
> Kurt
>
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Les Miklosy
> Sent: Tuesday, July 29, 2014 10:19 PM
> To: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] RedBoot hits fetch instruction trap
>
> 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
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] RedBoot hits fetch instruction trap
2014-07-30 6:36 ` Kurt Siedenburg
2014-07-30 21:25 ` Les Miklosy
@ 2014-07-31 6:22 ` Les Miklosy
2014-07-31 9:08 ` Kurt Siedenburg
1 sibling, 1 reply; 5+ messages in thread
From: Les Miklosy @ 2014-07-31 6:22 UTC (permalink / raw)
To: Kurt Siedenburg; +Cc: ecos-discuss
Hope the following is useful information. I used the -nb -nswb switches
when starting grmon to remove the erroneous exception notices. With a
break point at RedBoot's _rb_gets I still see multiple traps (think
grmon creates the last one in each list). The instruction at 0x4000bee8
is _rb_gets_preloaded. After a 'cont' command the process is trapped and
neither RedBoot nor grmon returns control to the user.
Anyone have a clue? Here is the sequence just described:
grmon2> go 0
breakpoint 1 hit
0x4000c5a4: c02a0000 clrb [%o0]
grmon2> hist
TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA
98758063 4000AE00 or %l0, 0x298, %o0 [4001FA98]
98758064 4000C5AC AHB read mst=0 size=2 [7FFFFE4B]
98758065 4000C5B0 AHB read mst=0 size=2 [9E104000]
98758066 4000C5B4 AHB read mst=0 size=2 [01000000]
98758067 4000C5B8 AHB read mst=0 size=2 [9DE3BF90]
98758068 4000C5BC AHB read mst=0 size=2 [9210001A]
98758070 4000AE04 mov 256, %o1 [00000100]
98758071 4000AE08 call 0x4000C5A4 [4000AE08]
98758072 4000AE0C mov 10, %o2 [0000000A]
98758073 4000C5A4 clrb [%o0] [ TRAP ]
grmon2> step 10
0x4000c5a4: c02a0000 clrb [%o0]
0x4000c5a8: 8213c000 or %o7, %g1
0x4000c5ac: 7ffffe4b call 0x4000BED8
0x4000c5b0: 9e104000 or %g1, %o7
0x4000bed8: 9de3bf90 save %sp, -112, %sp
0x4000bedc: 1110004e sethi %hi(0x40013800), %o0
0x4000bee0: ea022390 ld [%o0 + 0x390], %l5
0x4000bee4: a4100018 mov %i0, %l2
0x4000bee8: d24e0000 ldsb [%i0], %o1
0x4000beec: a6102000 mov 0, %l3
grmon2> hist
TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA
98758147 40013B90 AHB read mst=0 size=2 [FFFFFFFF]
98758148 4000BEE0 ld [%o0 + 0x390], %l5 [FFFFFFFF]
98758149 4000BEE4 mov %i0, %l2 [ TRAP ]
98758155 4000BEE4 mov %i0, %l2 [4001FA98]
98758156 4000BEE8 ldsb [%i0], %o1 [ TRAP ]
98758169 4001FA98 AHB read mst=0 size=2 [00656C70]
98758170 4000BEE8 ldsb [%i0], %o1 [00000000]
98758171 4000BEEC mov 0, %l3 [ TRAP ]
98758177 4000BEEC mov 0, %l3 [00000000]
98758178 4000BEF0 cmp %o1 [ TRAP ]
grmon2> cont
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [ECOS] RedBoot hits fetch instruction trap
2014-07-31 6:22 ` Les Miklosy
@ 2014-07-31 9:08 ` Kurt Siedenburg
0 siblings, 0 replies; 5+ messages in thread
From: Kurt Siedenburg @ 2014-07-31 9:08 UTC (permalink / raw)
To: Les Miklosy; +Cc: ecos-discuss
What I do see from the stuff below would result in data abort exceptions on other architectures - but not in instruction fetch exceptions:
- The instructions themselves are in valid address space, are all well aligned and seem to be valid opcodes
- But the data those instructions fetch may not be valid addresses (00000000, FFFFFFFF)
Again I'm not familiar with SPARC - and its CPU exception architecture.
Sorry - I don't think I can help any further.
Kurt
-----Original Message-----
From: Les Miklosy [mailto:lgm0@verizon.net]
Sent: Wednesday, July 30, 2014 11:18 PM
To: Kurt Siedenburg
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] RedBoot hits fetch instruction trap
Hope the following is useful information. I used the -nb -nswb switches when starting grmon to remove the erroneous exception notices. With a break point at RedBoot's _rb_gets I still see multiple traps (think grmon creates the last one in each list). The instruction at 0x4000bee8 is _rb_gets_preloaded. After a 'cont' command the process is trapped and neither RedBoot nor grmon returns control to the user.
Anyone have a clue? Here is the sequence just described:
grmon2> go 0
breakpoint 1 hit
0x4000c5a4: c02a0000 clrb [%o0]
grmon2> hist
TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA
98758063 4000AE00 or %l0, 0x298, %o0 [4001FA98]
98758064 4000C5AC AHB read mst=0 size=2 [7FFFFE4B]
98758065 4000C5B0 AHB read mst=0 size=2 [9E104000]
98758066 4000C5B4 AHB read mst=0 size=2 [01000000]
98758067 4000C5B8 AHB read mst=0 size=2 [9DE3BF90]
98758068 4000C5BC AHB read mst=0 size=2 [9210001A]
98758070 4000AE04 mov 256, %o1 [00000100]
98758071 4000AE08 call 0x4000C5A4 [4000AE08]
98758072 4000AE0C mov 10, %o2 [0000000A]
98758073 4000C5A4 clrb [%o0] [ TRAP ]
grmon2> step 10
0x4000c5a4: c02a0000 clrb [%o0]
0x4000c5a8: 8213c000 or %o7, %g1
0x4000c5ac: 7ffffe4b call 0x4000BED8
0x4000c5b0: 9e104000 or %g1, %o7
0x4000bed8: 9de3bf90 save %sp, -112, %sp
0x4000bedc: 1110004e sethi %hi(0x40013800), %o0
0x4000bee0: ea022390 ld [%o0 + 0x390], %l5
0x4000bee4: a4100018 mov %i0, %l2
0x4000bee8: d24e0000 ldsb [%i0], %o1
0x4000beec: a6102000 mov 0, %l3
grmon2> hist
TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA
98758147 40013B90 AHB read mst=0 size=2 [FFFFFFFF]
98758148 4000BEE0 ld [%o0 + 0x390], %l5 [FFFFFFFF]
98758149 4000BEE4 mov %i0, %l2 [ TRAP ]
98758155 4000BEE4 mov %i0, %l2 [4001FA98]
98758156 4000BEE8 ldsb [%i0], %o1 [ TRAP ]
98758169 4001FA98 AHB read mst=0 size=2 [00656C70]
98758170 4000BEE8 ldsb [%i0], %o1 [00000000]
98758171 4000BEEC mov 0, %l3 [ TRAP ]
98758177 4000BEEC mov 0, %l3 [00000000]
98758178 4000BEF0 cmp %o1 [ TRAP ]
grmon2> cont
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-07-31 9:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 5:24 [ECOS] RedBoot hits fetch instruction trap Les Miklosy
2014-07-30 6:36 ` Kurt Siedenburg
2014-07-30 21:25 ` Les Miklosy
2014-07-31 6:22 ` Les Miklosy
2014-07-31 9:08 ` Kurt Siedenburg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).