RedBoot hits fetch instruction trap

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RedBoot hits fetch instruction trap

Les G. Miklosy-2
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

info_sys.txt (1K) Download Attachment
timer_poll.txt (1K) Download Attachment
timer_trap.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: RedBoot hits fetch instruction trap

Kurt Siedenburg
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: [hidden email] [mailto:[hidden email]] On Behalf Of Les Miklosy
Sent: Tuesday, July 29, 2014 10:19 PM
To: [hidden email]
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

Reply | Threaded
Open this post in threaded view
|

Re: RedBoot hits fetch instruction trap

Les G. Miklosy-2
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: [hidden email] [mailto:[hidden email]] On Behalf Of Les Miklosy
> Sent: Tuesday, July 29, 2014 10:19 PM
> To: [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

Re: RedBoot hits fetch instruction trap

Les G. Miklosy-2
In reply to this post by Kurt Siedenburg
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

Reply | Threaded
Open this post in threaded view
|

RE: RedBoot hits fetch instruction trap

Kurt Siedenburg
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:[hidden email]]
Sent: Wednesday, July 30, 2014 11:18 PM
To: Kurt Siedenburg
Cc: [hidden email]
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