GRMON2 User's Manual

GRMON connects to a GRLIB target using one debug link interface, the command line options selects which interface the PC uses to connect to the target and optionally how the debug link is configured. All options are described in Chapter 4, Debug link.

The debug drivers provide an interface to view and access AMBA devices during debugging and they offer device specific ways to configure the hardware when connecting and before running the executable. Drivers usually auto-probe their devices for optimal configuration values, however sometimes it is useful to override the auto-probed values. Some options affects multiple drivers. The debug driver options are described in Chapter 5, Debug drivers.

The general options are mostly target independent options configuring the behavior of GRMON. Some of them affects how the target system is accessed both during connection and during the whole debugging session. All general options are described below.

grmon [options]

When connecting for the first time it is essential to verify that GRMON has auto-detected all devices and their configuration correctly. At start-up GRMON will print the cores and the frequency detected. From the command line one can examine the system by executing info sys as below:

grmon2> info sys
  cpu0      Aeroflex Gaisler  LEON3-FT SPARC V8 Processor    
            AHB Master 0
  cpu1      Aeroflex Gaisler  LEON3-FT SPARC V8 Processor    
            AHB Master 1
  greth0    Aeroflex Gaisler  GR Ethernet MAC    
            AHB Master 3
            APB: 80000E00 - 80000F00
            IRQ: 14
  grspw0    Aeroflex Gaisler  GRSPW2 SpaceWire Serial Link    
            AHB Master 5
            APB: 80100800 - 80100900
            IRQ: 22
            Number of ports: 1
  grspw1    Aeroflex Gaisler  GRSPW2 SpaceWire Serial Link    
            AHB Master 6
            APB: 80100900 - 80100A00
            IRQ: 23
            Number of ports: 1
  mctrl0    Aeroflex Gaisler  Memory controller with EDAC    
            AHB: 00000000 - 20000000
            AHB: 20000000 - 40000000
            AHB: 40000000 - 80000000
            APB: 80000000 - 80000100
            8-bit prom @ 0x00000000
            32-bit static ram: 1 * 8192 kbyte @ 0x40000000
            32-bit sdram: 2 * 128 Mbyte @ 0x60000000
            col 10, cas 2, ref 7.8 us
  apbmst0   Aeroflex Gaisler  AHB/APB Bridge    
            AHB: 80000000 - 80100000
  dsu0      Aeroflex Gaisler  LEON3 Debug Support Unit    
            AHB: 90000000 - A0000000
            AHB trace: 256 lines, 32-bit bus
            CPU0:  win 8, hwbp 2, itrace 256, V8 mul/div, srmmu, lddel 1, GRFPU
                   stack pointer 0x407ffff0
                   icache 4 * 4096 kB, 32 B/line lru
                   dcache 4 * 4096 kB, 16 B/line lru
            CPU1:  win 8, hwbp 2, itrace 256, V8 mul/div, srmmu, lddel 1, GRFPU
                   stack pointer 0x407ffff0
                   icache 4 * 4096 kB, 32 B/line lru
                   dcache 4 * 4096 kB, 16 B/line lru
  uart0     Aeroflex Gaisler  Generic UART    
            APB: 80000100 - 80000200
            IRQ: 2
            Baudrate 38461, FIFO debug mode
  irqmp0    Aeroflex Gaisler  Multi-processor Interrupt Ctrl.    
            APB: 80000200 - 80000300
            EIRQ: 12
  gptimer0  Aeroflex Gaisler  Modular Timer Unit    
            APB: 80000300 - 80000400
            IRQ: 8
            16-bit scalar, 4 * 32-bit timers, divisor 80
  grgpio0   Aeroflex Gaisler  General Purpose I/O port    
            APB: 80000900 - 80000A00
  uart1     Aeroflex Gaisler  Generic UART    
            APB: 80100100 - 80100200
            IRQ: 17
            Baudrate 38461
 ...

The memory section for example tells us that GRMON are using the correct amount of memory and memory type. The parameters can be tweaked by passing memory driver specific options on start-up, see the section called “Starting GRMON”. The current memory settings can be viewed in detail by listing the registers with info reg or by accessing the registers by the Tcl variables exported by GRMON:

grmon2> info sys
 ...
  mctrl0    Aeroflex Gaisler  Memory controller with EDAC
            AHB: 00000000 - 20000000
            AHB: 20000000 - 40000000
            AHB: 40000000 - 80000000
            APB: 80000000 - 80000100
            8-bit prom @ 0x00000000
            32-bit static ram: 1 * 8192 kbyte @ 0x40000000
            32-bit sdram: 2 * 128 Mbyte @ 0x60000000
            col 10, cas 2, ref 7.8 us
 ...
 grmon2> info reg
 ...
  Memory controller with EDAC
      0x80000000  Memory config register 1                0x1003c0ff
      0x80000004  Memory config register 2                0x9ac05463
      0x80000008  Memory config register 3                0x0826e000
 ...
grmon2> puts [format 0x%08x $mctrl0::               [TAB-COMPLETION]
mctrl0::mcfg1    mctrl0::mcfg2    mctrl0::mcfg3    mctrl0::pnp::
mctrl0::mcfg1::  mctrl0::mcfg2::  mctrl0::mcfg3::  
grmon2> puts [format 0x%08x $mctrl0::mcfg1]
  0x0003c0ff
 
grmon2> puts [format 0x%08x $mctrl0::mcfg2 ::       [TAB-COMPLETION]
mctrl0::mcfg2::d64          mctrl0::mcfg2::sdramcmd
mctrl0::mcfg2::rambanksz    mctrl0::mcfg2::sdramcolsz
mctrl0::mcfg2::ramrws       mctrl0::mcfg2::sdramrf
mctrl0::mcfg2::ramwidth     mctrl0::mcfg2::sdramtcas
mctrl0::mcfg2::ramwws       mctrl0::mcfg2::sdramtrfc
mctrl0::mcfg2::rbrdy        mctrl0::mcfg2::sdramtrp
mctrl0::mcfg2::rmw          mctrl0::mcfg2::se
mctrl0::mcfg2::sdpb         mctrl0::mcfg2::si
mctrl0::mcfg2::sdrambanksz  
grmon2> puts [format %x $mctrl0::mcfg2::ramwidth]
  2

A LEON software application can be uploaded to the target system memory using the load command:

grmon2> load v8/stanford.exe
  40000000 .text                     54.8kB /  54.8kB   [===============>] 100%
  4000DB30 .data                      2.9kB /   2.9kB   [===============>] 100%
  Total size: 57.66kB (786.00kbit/s)
  Entry point 0x40000000
  Image /home/daniel/examples/v8/stanford.exe loaded

The supported file formats are SPARC ELF-32, ELF-64 (MSB truncated to 32-bit addresses), srecord and a.out binaries. Each section is loaded to its link address. The program entry point of the file is used to set the %PC, %NPC when the application is later started with run. It is also possible to load binary data by specifying file and target address using the bload command.

One can use the verify command to make sure that the file has been loaded correctly to memory as below. Any discrepancies will be reported in the GRMON console.

grmon2> verify v8/stanford.exe
  40000000 .text                     54.8kB /  54.8kB   [===============>] 100%
  4000DB30 .data                      2.9kB /   2.9kB   [===============>] 100%
  Total size: 57.66kB (726.74kbit/s)
  Entry point 0x40000000
  Image of /home/daniel/examples/v8/stanford.exe verified without errors

After the application has been uploaded to the target with load the run command can be used to start execution. The entry-point taken from the ELF-file during loading will serve as the starting address, the first instruction executed. The run command issues a driver reset, however it may be neccessary to perform a reset prior to loading the image to avoid that DMA overwrites the image. See the reset command for details. Applications already located in FLASH can be started by specifying an absolute address. The cont command resumes execution after a temporary stop, e.g. a breakpoint hit. go also affects the CPU execution, the difference compared to run is that the target device hardware is not initialized before starting execution.

grmon2> reset
grmon2> load v8/stanford.exe
  40000000 .text                     54.8kB /  54.8kB   [===============>] 100%
  4000DB30 .data                      2.9kB /   2.9kB   [===============>] 100%
  Total size: 57.66kB (786.00kbit/s)
  Entry point 0x40000000
  Image /home/daniel/examples/v8/stanford.exe loaded

grmon2> run
Starting
    Perm  Towers  Queens   Intmm      Mm  Puzzle   Quick  Bubble    Tree     FFT
      34      67      33     117    1117     367      50      50     250    1133

Nonfloating point composite is        144

Floating point composite is        973

  CPU 0:  Program exited normally.
  CPU 1:  Power down mode

The output from the application normally appears on the LEON UARTs and thus not in the GRMON console. However, if GRMON is started with the -u switch, the UART is put into debug mode and the output is tunneled over the debug-link and finally printed on the console by GRMON. See the section called “Forwarding application console I/O”. Note that older hardware (GRLIB 1.0.17-b2710 and older) has only partial support for -u, it will not work when the APBUART software driver uses interrupt driven I/O, thus Linux and vxWorks are not supported on older hardware. Instead, a terminal emulator should be connected to UART 1 of the target system.

Since the application changes (at least) the .data segment during run-time the application must be reloaded before it can be executed again. If the application uses the MMU (e.g. Linux) or installs data exception handlers (e.g. eCos), GRMON should be started with -nb to avoid going into break mode on a page-fault or data exception. Likewise, when a software debugger is running on the target (e.g. GDB natively in Linux user-space or WindRiver Workbench debugging a task) soft breakpoints ("TA 0x01" instruction) will result in traps that the OS will handle and tell the native debugger. To prevent GRMON from interpreting it as its own breakpoints and stop the CPU one must use the -nswb switch.

All breakpoints are inserted with the bp command. The subcommand (soft, hard, watch, bus, data, delete) given to bp determine which type of breakpoint is inserted, if no subcommand is given bp defaults to a software breakpoint.

Instruction breakpoints are inserted using bp soft or bp hard commands. Inserting a software breakpoint will add a (TA 0x1) instruction by modifying the target's memory before starting the CPU, while bp hard will insert a hardware breakpoint using one of the IU watchpoint registers. To debug instruction code in read-only memories or memories which are self-modifying the only option is hardware breakpoints. Note that it's possible to debug any RAM-based code using software breakpoints, even where traps are disabled such as in trap handlers. Since hardware breakpoints triggers on the CPU instruction address one must be aware that when the MMU is turned on, virtual addresses are triggered upon.

CPU data address watchpoints (read-only, write-only or read-write) are inserted using the bp watch command. Watchpoints can be setup to trigger within a range determined by a bit-mask where a one means that the address must match the address pattern and a zero mask indicate don't care. The lowest 2-bits are not available, meaning that 32-bit words are the smallest address that can be watched. Byte accesses can still be watched but accesses to the neighboring three bytes will also be watched.

AMBA-bus watchpoints can be inserted using bp bus or bp data. When a bus watchpoint is hit the trace buffer will freeze. The processor can optionally be put in debug mode when the bus watchpoint is hit. This is controlled by the tmode command:

grmon2> tmode break N

If N = 0, the processor will not be halted when the watchpoint is hit. A value > 0 will break the processor and set the AHB trace buffer delay counter to the same value.

The current register window of a LEON processor can be displayed using the reg command or by accessing the Tcl cpu namespace that GRMON provides. GRMON exports cpu and cpuN where N selects which CPU's registers are accessed, the cpu namespace points to the active CPU selected by the cpu command.

grmon2> reg
  	     INS        LOCALS     OUTS       GLOBALS
     0:  00000008   0000000C   00000000   00000000
     1:  80000070   00000020   00000000   00000001
     2:  00000000   00000000   00000000   00000002
     3:  00000000   00000000   00000000   00300003
     4:  00000000   00000000   00000000   00040004
     5:  00000000   00000000   00000000   00005005
     6:  407FFFF0   00000000   407FFFF0   00000606
     7:  00000000   00000000   00000000   00000077

   psr: F34010E0   wim: 00000002   tbr: 40000060   y: 00000000

   pc:   40003E44  be  0x40003FB8
   npc:  40003E48  nop
grmon2> puts [format %x $::cpu::iu::o6]
  407ffff0

Other register windows can be displayed using reg wN, when N denotes the window number. Use the float command to show the FPU registers (if present).

When debugging an application it is often most useful to view how the CPU entered the current function. The bt command analyze the previous stack frames to determine the backtrace. GRMON reads the register windows and then switches to read from the stack depending on the %WIM and %PSR register.

The backtrace is presented with the caller's program counter (%PC) to return to (below where the CALL instruction was issued) and the stack pointer (%SP) at that time. The first entry (frame #0) indicates the current location of the CPU and the current stack pointer. The right most column print out the %PC address relative the function symbol, i.e. if symbols are present.

grmon2> bt

       %pc          %sp 
  #0   0x40003e24   0x407ffdb8   <Fft+0x4>
  #1   0x40005034   0x407ffe28   <main+0xfc4>
  #2   0x40001064   0x407fff70   <_start+0x64>
  #3   0x4000cf40   0x407fffb0   <_hardreset_real+0x78>

Any memory location can be displayed and written using the mem commands listed in the table below. Memory commands that are prefixed with a v access the virtual address space seen by doing MMU address lookups for active CPU.

The mem command requires an address and an optional length, if the length is left out 64 bytes are displayed. If a program has been loaded, text symbols can be used instead of a numeric address. The memory content is displayed in hexadecimal-decimal format, grouped in 32-bit words. The ASCII equivalent is printed at the end of the line.

grmon> mem 0x40000000

 40000000  a0100000  29100004  81c52000  01000000    ...)..... .....
 40000010  91d02000  01000000  01000000  01000000    . .............
 40000020  91d02000  01000000  01000000  01000000    . .............
 40000030  91d02000  01000000  01000000  01000000    . .............

grmon> mem 0x40000000 16

 40000000  a0100000  29100004  81c52000  01000000    ...)..... .....

grmon> mem main 48

 40003278  9de3bf98  2f100085  31100037  90100000    ..../...1..7....
 40003288  d02620c0  d025e178  11100033  40000b4b    & .%.x...3@..K
 40003298  901223b0  11100033  40000af4  901223c0    ..#....3@.....#.

If the memory contents is SPARC machine code, the contents can be displayed in assembly code using the disassemble command:

grmon2> disassemble 0x40000000 10
  0x40000000: 88100000  clr  %g4                     <start+0>
  0x40000004: 09100034  sethi  %hi(0x4000d000), %g4  <start+4>
  0x40000008: 81c12034  jmp  %g4 + 0x34              <start+8>
  0x4000000c: 01000000  nop                          <start+12>
  0x40000010: a1480000  mov  %psr, %l0               <start+16>
  0x40000014: a7500000  mov  %wim, %l3               <start+20>
  0x40000018: 10803401  ba  0x4000d01c               <start+24>
  0x4000001c: ac102001  mov  1, %l6                  <start+28>
  0x40000020: 91d02000  ta  0x0                      <start+32>
  0x40000024: 01000000  nop                          <start+36>

grmon2> dis main
  0x40004070: 9de3beb8  save  %sp, -328, %sp         <main+0>
  0x40004074: 15100035  sethi  %hi(0x4000d400), %o2  <main+4>
  0x40004078: d102a3f4  ld  [%o2 + 0x3f4], %f8       <main+8>
  0x4000407c: 13100035  sethi  %hi(0x4000d400), %o1  <main+12>
  0x40004080: 39100088  sethi  %hi(0x40022000), %i4  <main+16>
  0x40004084: 3710003a  sethi  %hi(0x4000e800), %i3  <main+20>
  0x40004088: d126e2e0  st  %f8, [%i3 + 0x2e0]       <main+24>
  0x4000408c: d1272398  st  %f8, [%i4 + 0x398]       <main+28>
  0x40004090: 400006a9  call  0x40005b34             <main+32>
  0x40004094: 901262f0  or  %o1, 0x2f0, %o0          <main+36>
  0x40004098: 11100035  sethi  %hi(0x4000d400), %o0  <main+40>
  0x4000409c: 40000653  call  0x400059e8             <main+44>
  0x400040a0: 90122300  or  %o0, 0x300, %o0          <main+48>
  0x400040a4: 7ffff431  call  0x40001168             <main+52>
  0x400040a8: 3510005b  sethi  %hi(0x40016c00), %i2  <main+56>
  0x400040ac: 2510005b  sethi  %hi(0x40016c00), %l2  <main+60>

The LEON processor and associated debug support unit (DSU) can be configured with trace buffers to store both the latest executed instructions and the latest AHB bus transfers. The trace buffers are automatically enabled by GRMON during start-up , but can also be individually enabled and disabled using tmode command. The command ahb is used to show the AMBA buffer. The command inst is used to show the instruction buffer. The command hist is used to display the contents of the instruction and the AMBA buffers mixed together. Below is an example debug session that shows the usage of breakpoints, watchpoints and the trace buffer:

grmon2> lo v8/stanford.exe
  40000000 .text                     54.8kB /  54.8kB   [===============>] 100%
  4000DB30 .data                      2.9kB /   2.9kB   [===============>] 100%
  Total size: 57.66kB (786.00kbit/s)
  Entry point 0x40000000
  Image /home/daniel/examples/v8/stanford.exe loaded

grmon2> bp Fft
  Software breakpoint 1 at <Fft>

grmon2> bp watch 0x4000eae0
  Hardware watchpoint 2 at 0x4000eae0

grmon2> bp
  NUM   ADRESS      MASK        TYPE        SYMBOL
    1 : 0x40003e20              (soft)      Fft+0
    2 : 0x4000eae0  0xfffffffc  (watch rw)  floated+0

grmon2> run

  CPU 0:  watchpoint 2 hit
          0x40001024: c0388003  std  %g0, [%g2 + %g3]  <_start+36>
  CPU 1:  Power down mode

grmon2> inst
      TIME     ADDRESS   INSTRUCTION                   RESULT    
        84675  40001024  std  %g0, [%g2 + %g3]         [4000eaf8 00000000 00000000]
        84678  4000101c  subcc  %g3, 8, %g3            [00000440]
        84679  40001020  bge,a  0x4000101c             [00000448]
        84682  40001024  std  %g0, [%g2 + %g3]         [4000eaf0 00000000 00000000]
        84685  4000101c  subcc  %g3, 8, %g3            [00000438]
        84686  40001020  bge,a  0x4000101c             [00000440]
        84689  40001024  std  %g0, [%g2 + %g3]         [4000eae8 00000000 00000000]
        84692  4000101c  subcc  %g3, 8, %g3            [00000430]
        84693  40001020  bge,a  0x4000101c             [00000438]
        84694  40001024  std  %g0, [%g2 + %g3]         [  TRAP  ]

grmon2> ahb
      TIME    ADDRESS  TYPE  D[31:0]  TRANS SIZE BURST MST LOCK RESP HIRQ
        84664 4000eb08 write 00000000   2    2     1    0   0    0   0000
        84667 4000eb0c write 00000000   3    2     1    0   0    0   0000
        84671 4000eb00 write 00000000   2    2     1    0   0    0   0000
        84674 4000eb04 write 00000000   3    2     1    0   0    0   0000
        84678 4000eaf8 write 00000000   2    2     1    0   0    0   0000
        84681 4000eafc write 00000000   3    2     1    0   0    0   0000
        84685 4000eaf0 write 00000000   2    2     1    0   0    0   0000
        84688 4000eaf4 write 00000000   3    2     1    0   0    0   0000
        84692 4000eae8 write 00000000   2    2     1    0   0    0   0000
        84695 4000eaec write 00000000   3    2     1    0   0    0   0000       

grmon2> reg
  	  INS       LOCALS      OUTS     GLOBALS
     0:  80000200   00000000   00000000   00000000
     1:  80000200   00000000   00000000   00000000
     2:  0000000C   00000000   00000000   4000E6B0
     3:  FFF00000   00000000   00000000   00000430
     4:  00000002   00000000   00000000   4000CC00
     5:  800FF010   00000000   00000000   4000E680
     6:  407FFFB0   00000000   407FFF70   4000CF34
     7:  4000CF40   00000000   00000000   00000000
  
   psr: F30010E7   wim: 00000002   tbr: 40000000   y: 00000000
  
   pc:   40001024  std  %g0, [%g2 + %g3]       
   npc:  4000101c  subcc  %g3, 8, %g3          

grmon2> bp del 2

grmon2> cont
  Towers  Queens   Intmm      Mm  Puzzle   Quick  Bubble    Tree     FFT
  CPU 0:  breakpoint 1 hit
          0x40003e24: a0100018  mov  %i0, %l0  <Fft+4>
  CPU 1:  Power down mode  

grmon2>
grmon2> hist
      TIME     ADDRESS   INSTRUCTIONS/AHB SIGNALS      RESULT/DATA
     30046975  40003e20  AHB read   mst=0  size=2      [9de3bf90]
     30046976  40005030  or  %l2, 0x1e0, %o3           [40023de0]
     30046980  40003e24  AHB read   mst=0  size=2      [91d02001]
     30046981  40005034  call  0x40003e20              [40005034]
     30046985  40003e28  AHB read   mst=0  size=2      [b136201f]
     30046990  40003e2c  AHB read   mst=0  size=2      [f83fbff0]
     30046995  40003e30  AHB read   mst=0  size=2      [82040018]
     30047000  40003e34  AHB read   mst=0  size=2      [d11fbff0]
     30047005  40003e38  AHB read   mst=0  size=2      [9a100019]
     30047010  40003e3c  AHB read   mst=0  size=2      [9610001a]

When printing executed instructions, the value within brackets denotes the instruction result, or in the case of store instructions the store address and store data. The value in the first column displays the relative time, equal to the DSU timer. The time is taken when the instruction completes in the last pipeline stage (write-back) of the processor. In a mixed instruction/AHB display, AHB address and read or write value appears within brackets. The time indicates when the transfer completed, i.e. when HREADY was asserted.

GRMON supports profiling of LEON applications when run on real hardware. The profiling function collects (statistical) information on the amount of execution time spent in each function. Due to its non-intrusive nature, the profiling data does not take into consideration if the current function is called from within another procedure. Even so, it still provides useful information and can be used for application tuning.

grmon2> lo v8/stanford.exe
  40000000 .text                     54.8kB /  54.8kB   [===============>] 100%
  4000DB30 .data                      2.9kB /   2.9kB   [===============>] 100%
  Total size: 57.66kB (786.00kbit/s)
  Entry point 0x40000000
  Image /home/daniel/examples/v8/stanford.exe loaded
  
grmon2> profile on
  
grmon2> run
Starting 
    Perm  Towers  Queens   Intmm      Mm  Puzzle   Quick  Bubble    Tree     FFT
  
  CPU 0:  Interrupted!
          0x40003ee4: 95a0c8a4  fsubs  %f3, %f4, %f10  <Fft+196>
  CPU 1:  Interrupted!
          0x40000000: 88100000  clr  %g4  <start+0>
  
grmon2> prof
    FUNCTION                      SAMPLES    RATIO(%)
    Trial                         0000000096 27.35
    __window_overflow_rettseq_ret 0000000060 17.09
    main                          0000000051 14.52
    __window_overflow_slow1       0000000026  7.40
    Fft                           0000000023  6.55
    Insert                        0000000016  4.55
    Permute                       0000000013  3.70
    tower                         0000000013  3.70
    Try                           0000000013  3.70
    Quicksort                     0000000011  3.13
    Checktree                     0000000007  1.99
    _malloc_r                     0000000005  1.42
    start                         0000000004  1.13
    outbyte                       0000000003  0.85
    Towers                        0000000002  0.56
    __window_overflow_rettseq     0000000002  0.56
    ___st_pthread_mutex_lock      0000000002  0.56
    _start                        0000000001  0.28
    Perm                          0000000001  0.28
    __malloc_lock                 0000000001  0.28
    ___st_pthread_mutex_trylock   0000000001  0.28

When GRMON connects to a target system, it probes the configuration and initializes memory and registers. To determine why a target has crashed, or resume debugging without reloading the application, it might be desirable to connect to the target without performing a (destructive) initialization. This can be done by specifying the -ni switch during the start-up of GRMON. The system information print-out (info sys) will then however not be able to display the correct memory settings. The use of the -stack option and the go command might also be necessary in case the application is later restarted. The run command may not have the intended effect since the debug drivers have not been initialized during start-up.

In systems with more than one LEON processor, the cpu command can be used to control the state and debugging focus of the processors. In MP systems, the processors are enumerated with 0..N-1, where N is the number of processors. Each processor can be in two states; enabled or disabled. When enabled, a processor can be started by LEON software or by GRMON. When disabled, the processor will remain halted regardless. One can pause a MP operating system and disable a CPU to debug a hanged CPU for example.

Most per-CPU (DSU) debugging commands such as displaying registers, backtrace or adding breakpoints will be directed to the active processor only. Switching active processor can be done using the 'cpu active N' command, see example below. The Tcl cpu namespace exported by GRMON is also changed to point to the active CPU's namespace, thus accessing cpu will be the same as accessing cpu1 if CPU1 is the currently active CPU.

grmon2> cpu
   cpu 0: enabled  active
   cpu 1: enabled 
  
grmon2> cpu act 1
  
grmon2> cpu
   cpu 0: enabled 
   cpu 1: enabled  active
  
grmon2> cpu act 0
  
grmon2> cpu dis 1
  
grmon2> cpu
   cpu 0: enabled  active
   cpu 1: disabled

grmon2> puts $cpu::fpu::f1
  -1.984328031539917
  
grmon2> puts $cpu0::fpu::f1
  -1.984328031539917
  
grmon2> puts $cpu1::fpu::f1
  2.3017966689845248e+18

The stack pointer is located in %O6 (%SP) register of SPARC CPUs. GRMON sets the stack pointer before starting the CPU with the run command. The address is auto-detected to end of main memory, however it is overridable using the -stack when starting GRMON or by issuing the stack command. Thus stack pointer can be used by software to detect end of main memory.

The entry point (EP) determines at which address the CPU start its first instruction execution. The EP defaults to main memory start and normally overridden by the load command when loading the application. ELF-files has support for storing entry point. The entry point can manually be set with the ep command.

In a MP systems if may be required to set EP and stack pointer individual per CPU, one can use the cpu command in conjunction with ep and stack.

The LEON optionally implements the reference MMU (SRMMU) described in the SPARCv8 specification. GRMON support viewing and changing the MMU registers through the DSU, using the mmu command. GRMON also supports address translation by reading the MMU table from memory similar to the MMU. The walk command looks up one address by walking the MMU table printing out every step taken and the result. To simply print out the result of such a translation, use the va command.

The memory commands that are prefixed with a v work with virtual addresses, the addresses given are translated before listing or writing physical memory. If the MMU is not enabled, the vmem command for example is an alias for mem. See the section called “Displaying memory contents” for more information.

The LEON optionally implements Level-1 instruction-cache and data-cache. GRMON supports the CPU's cache by adopting certain operations depending on if the cache is activated or not. The user may also be able to access the cache directly. This is however not normally needed, but may be useful when debugging or analyzing different cache aspects. By default the L1-cache is turned on by GRMON , the cctrl command can be used to change the cache control register. The commandline switches -nic and -ndc disables instruction and data cache respectively.

With the icache and dcache commands it is possible to view the current content of the cache or check if the cache is consistent with the memory. Both caches can be flushed instantly using the commands cctrl flush. The data cache can be flushed instantly using the commands dcache flush. The instruction cache can be flushed instantly using the commands icache flush.

GRMON creates several independent TCL shells, each with its own set of commands and variables. I.e. changing active CPU in one shell does not affect any other shell. There are two shells available for the user, the CLI shell and a GDB shell. The CLI shell is access from the terminal and the GDB shell is accessed from GDB by using the command mon. There is also a system shell running in the background that GRMON uses internally.

There are two groups of commands, the native Tcl commands and GRMON's commands. Information about the native Tcl commands and their syntax can be found at the Tcl website. The GRMON commands' syntax documentation can be found in Appendix B, Command syntax.

The commands have three types of output:

For some of the GRMON commands it is possible to specify which core the commands is operation on. This is implemented differently depending for each command, see the commands' syntax documentation in Appendix B, Command syntax for more details. Some of these commands use a device name to specify which core to interact with, see Appendix C, Tcl API for more information about device names.

It is possible to extend GRMON using Tcl. GRMON provides an API that makes it possible do write own device drivers, implement hooks and to write advanced commands. See Appendix C, Tcl API for a detailed description of the API.

GRMON will automatically load the scripts in GRMON appdata folder. On Linux the appdata folder is located in ~/.grmon-2.0/ and on Windows it's typically located at C:\Documents and Settings\username\Application Data\Aeroflex Gaisler\GRMON\2.0\. In the folder there are two different sub folders where scripts may be found, <appdata>/scripts/sys and <appdata>/scripts/user. Scripts located in the sys-folder will be loaded into the system shell only, before the Plug and Play area is scanned, i.e. drivers and fix-ups should be defined here. The scripts found in the user-folder will be loaded into all shells (including the system shell), i.e. all user defined commands and hooks should be defined there. In addition there are two commandline switches -udrv <filename> and -ucmd <filename> to load scripts into the system shell or all shells.

More about Tcl, its syntax and other useful information can be found at:

When loading symbols into GRMON it is possible to associate them with a CPU. When all symbols/images are associated with CPU index 0, then GRMON will assume its a single-core or SMP application and lookup all symbols from the symbols table associated with CPU index 0.

If different CPU indexes are specified (by setting active CPU or adding cpu# argument to the commands) when loading symbols/images, then GRMON will assume its an AMP application that has been loaded. GRMON will use the current active CPU (or cpu# argument) to determine which CPU index to lookup symbols from.

grmon2> cpu active 1
  
grmon2> symbols ../tests/threads/rtems-mp2
  Loaded 1630 symbols
	
grmon2> bp _Thread_Handler
  Software breakpoint 1 at <_Thread_Handler>
  
grmon2> symbols ../tests/threads/rtems-mp1 cpu0
  Loaded 1630 symbols
  
grmon2> bp _Thread_Handler cpu0
  Software breakpoint 2 at <_Thread_Handler>
  
grmon2> bp
  NUM   ADRESS      MASK        TYPE        CPU  SYMBOL
    1 : 0x40418408              (soft)        1  _Thread_Handler+0
    2 : 0x40019408              (soft)        0  _Thread_Handler+0

GRMON can act as a remote target for GDB, allowing symbolic debugging of target applications. To initiate GDB communications, start the monitor with the -gdb switch or use the GRMON gdb start command:

$ grmon -xilusb -gdb
...
	Started GDB service on port 2222.	
...
grmon2> gdb status
  GDB Service is waiting for incoming connection
  Port: 2222

Then, start GDB in a different window and connect to GRMON using the extended-remote protocol. By default, GRMON listens on port 2222 for the GDB connection:

(gdb) target extended-remote :2222
Remote debugging using :2222
main () at stanford.c:1033
1033	{
(gdb) monitor gdb status
GDB Service is running
Port: 2222
(gdb) 

While GDB is attached to GRMON, most GRMON commands can be executed using the GDB monitor command. Output from the GRMON commands is then displayed in the GDB console like below. Some DSU commands are naturally not available since they would conflict with GDB. All commands executed from GDB are executed in a separate Tcl interpreter, thus variables created from GDB will not be available from the GRMON terminal.

(gdb) monitor hist
      TIME     ADDRESS   INSTRUCTIONS/AHB SIGNALS      RESULT/DATA
     30046975  40003e20  AHB read   mst=0  size=2      [9de3bf90]
     30046976  40005030  or  %l2, 0x1e0, %o3           [40023de0]
     30046980  40003e24  AHB read   mst=0  size=2      [91d02001]
     30046981  40005034  call  0x40003e20              [40005034]
     30046985  40003e28  AHB read   mst=0  size=2      [b136201f]
     30046990  40003e2c  AHB read   mst=0  size=2      [f83fbff0]
     30046995  40003e30  AHB read   mst=0  size=2      [82040018]
     30047000  40003e34  AHB read   mst=0  size=2      [d11fbff0]
     30047005  40003e38  AHB read   mst=0  size=2      [9a100019]
     30047010  40003e3c  AHB read   mst=0  size=2      [9610001a]
(gdb) 

To load and start an application, use the GDB load and run command.

$ sparc-rtems-gdb v8/stanford.exe
(gdb) target extended-remote :2222
Remote debugging using :2222
main () at stanford.c:1033
1033	{
(gdb) load
Loading section .text, size 0xdb30 lma 0x40000000
Loading section .data, size 0xb78 lma 0x4000db30
Start address 0x40000000, load size 59048
Transfer rate: 18 KB/sec, 757 bytes/write.
(gdb) b main
Breakpoint 1 at 0x40004074: file stanford.c, line 1033.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/daniel/examples/v8/stanford.exe

Breakpoint 1, main () at stanford.c:1033
1033	{
(gdb) list
1028		  /* Printcomplex( 6, 99, z, 1, 256, 17 ); */
1029	      };
1030	} /* oscar */ ;
1031	
1032	main ()
1033	{
1034	    int i;
1035	    fixed = 0.0;
1036	    floated = 0.0;
1037	    printf ("Starting \n");
(gdb) 

To interrupt execution, Ctrl-C can be typed in GDB terminal (similar to GRMON). The program can be restarted using the GDB run command but the program image needs to be reloaded first using the load command. Software trap 1 (TA 0x1) is used by GDB to insert breakpoints and should not be used by the application.

GRMON translates SPARC traps into (UNIX) signals which are properly communicated to GDB. If the application encounters a fatal trap, execution will be stopped exactly before the failing instruction. The target memory and register values can then be examined in GDB to determine the error cause.

GRMON implements the GDB breakpoint and watchpoint interface and makes sure that memory and cache are synchronized.

If GRMON is running on the same computer as GDB, or if the executable is available on the remote computer that is running GRMON, it is recommended to issue the GDB command set remote exec-file <remote-file-path>. After this has been set, GRMON will automatically load the file, and symbols if available, when the GDB command run is issued.

$ sparc-rtems-gdb /opt/rtems-4.11/src/rtems-4.11/testsuites/libtests/ticker/ticker.exe 
GNU gdb 6.8.0.20090916-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sparc-rtems"...
(gdb) target extended-remote :2222
Remote debugging using :2222
0x00000000 in ?? ()
(gdb) set remote exec-file /opt/rtems-4.11/src/rtems-4.11/testsuites/libtests/ticker/ticker.exe
(gdb) break Init
Breakpoint 1 at 0x40001318: file ../../../../../leon3smp/lib/include/rtems/score/thread.h, line 627.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/rtems-4.11/src/rtems-4.11/testsuites/libtests/ticker/ticker.exe

If the executable is not available on the remote computer where GRMON is running, then the GDB command load can be used to load the software to the target system. In addition the entry points for all CPU's, except the first, must be set manually using the GRMON ep before starting the application.

$ sparc-rtems-gdb /opt/rtems-4.11/src/rtems-4.11/testsuites/libtests/ticker/ticker.exe
GNU gdb 6.8.0.20090916-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sparc-rtems"...
(gdb) target extended-remote :2222
Remote debugging using :2222
trap_table () at /opt/rtems-4.11/src/rtems-4.11/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start
/start.S:69
69	/opt/rtems-4.11/src/rtems-4.11/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start/start.S: No
such file or directory.
	in /opt/rtems-4.11/src/rtems-4.11/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start/start.S
Current language:  auto; currently asm
(gdb) load
Loading section .text, size 0x1aed0 lma 0x40000000
Loading section .data, size 0x5b0 lma 0x4001aed0
Start address 0x40000000, load size 111744
Transfer rate: 138 KB/sec, 765 bytes/write.
(gdb) mon ep $cpu::iu::pc cpu1
(gdb) mon ep $cpu::iu::pc cpu2
(gdb) mon ep $cpu::iu::pc cpu3
Cpu 1 entry point: 0x40000000
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/rtems-4.11/src/rtems-4.11/testsuites/libtests/ticker/ticker.exe

If GRMON is running on the same computer as GDB, or if the executables are available on the remote computer that is running GRMON, it is recommended to issue the GDB command set remote exec-file <remote-file-path>. When this is set, GRMON will automatically load the file,and symbols if available, when the GDB command run is issued. The second application needs to be loaded into GRMON using the GRMON command load <remote-file-path> cpu1. In addition the stacks must also be set manually in GRMON using the command stack <address> cpu# for both CPUs.

$ sparc-rtems-gdb /opt/rtems-4.10/src/samples/rtems-mp1
GNU gdb 6.8.0.20090916-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sparc-rtems"...
(gdb) target extended-remote :2222
Remote debugging using :2222
(gdb) set remote exec-file /opt/rtems-4.10/src/samples/rtems-mp1
(gdb) mon stack 0x403fff00 cpu0
 CPU 0 stack pointer: 0x403fff00
(gdb) mon load /opt/rtems-4.10/src/samples/rtems-mp2 cpu1
Total size: 177.33kB (1.17Mbit/s)
Entry point 0x40400000
Image /opt/rtems-4.10/src/samples/rtems-mp2 loaded
(gdb) mon stack 0x407fff00 cpu1
 CPU 1 stack pointer: 0x407fff00
(gdb) run
Starting program: /opt/rtems-4.10/src/samples/rtems-mp1 
NODE[0]: is Up!
NODE[0]: Waiting for Semaphore A to be created (0x53454d41)
NODE[0]: Waiting for Semaphore B to be created (0x53454d42)
NODE[0]: Waiting for Task A to be created (0x54534b41)
^C[New Thread 151060481]

Program received signal SIGINT, Interrupt.
[Switching to Thread 151060481]
pwdloop () at /opt/rtems-4.10/src/rtems-4.10/c/src/lib/libbsp/sparc/leon3/startup/bspidle.S:26
warning: Source file is more recent than executable.
26	          retl
Current language:  auto; currently asm 
(gdb) 

If the executable is not available on the remote computer where GRMON is running, then the GDB command file and load can be used to load the software to the target system. Use the GRMON command cpu act <num> before issuing the GDB command load to specify which CPU is the target for the software being loaded. In addition the stacks must also be set manually in GRMON using the command stack <address> cpu# for both CPUs.

$ sparc-rtems-gdb 
GNU gdb 6.8.0.20090916-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sparc-rtems".
(gdb) target extended-remote :2222
Remote debugging using :2222
0x40000000 in ?? ()
(gdb) file /opt/rtems-4.10/src/samples/rtems-mp2
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from /opt/rtems-4.10/src/samples/rtems-mp2...done.
(gdb) mon cpu act 1
(gdb) load
Loading section .text, size 0x2b3e0 lma 0x40400000
Loading section .data, size 0x1170 lma 0x4042b3e0
Loading section .jcr, size 0x4 lma 0x4042c550
Start address 0x40400000, load size 181588
Transfer rate: 115 KB/sec, 759 bytes/write.
(gdb) file /opt/rtems-4.10/src/samples/rtems-mp1
A program is being debugged already.
Are you sure you want to change the file? (y or n) y

Load new symbol table from "/opt/rtems-4.10/src/samples/rtems-mp1"? (y or n) y
Reading symbols from /opt/rtems-4.10/src/samples/rtems-mp1...done.
(gdb) mon cpu act 0
(gdb) load
Loading section .text, size 0x2b3e0 lma 0x40001000
Loading section .data, size 0x1170 lma 0x4002c3e0
Loading section .jcr, size 0x4 lma 0x4002d550
Start address 0x40001000, load size 181588
Transfer rate: 117 KB/sec, 759 bytes/write.
(gdb) mon stack 0x407fff00 cpu1
 CPU 1 stack pointer: 0x407fff00
(gdb) mon stack 0x403fff00 cpu0
 CPU 0 stack pointer: 0x403fff00
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/rtems-4.10/src/samples/samples/rtems-mp1

GDB is capable of listing a operating system's threads, however it relies on GRMON to implement low-level thread access. GDB normally fetches the threading information on every stop, for example after a breakpoint is reached or between single-stepping stops. GRMON have to access the memory rather many times to retrieve the information, GRMON. See the section called “Thread support” for more information.

Start GRMON with the -nothreads switch to disable threads in GRMON and thus in GDB too.

Note that GRMON must have access to the symbol table of the operating system so that the thread structures of the target OS can be found. The symbol table can be loaded from GDB by one must bear in mind that the path is relative to where GRMON has been started. If GDB is connected to GRMON over the network one must make the symbol file available on the remote computer running GRMON.

(gdb) mon puts [pwd]
/home/daniel
(gdb) pwd
Working directory /home/daniel.
(gdb) mon sym load /opt/rtems-4.10/src/samples/rtems-hello
(gdb) mon sym
0x00016910  GLOBAL  FUNC     imfs_dir_lseek
0x00021f00  GLOBAL  OBJECT   Device_drivers
0x0001c6b4  GLOBAL  FUNC     _mprec_log10
...

When a program running in GDB stops GRMON reports which thread it is in. The command info threads can be used in GDB to list all known threads, thread N to switch to thread N and bt to list the backtrace of the selected thread.

Program received signal SIGINT, Interrupt.
[Switching to Thread 167837703]

0x40001b5c in console_outbyte_polled (port=0, ch=113 `q`) at rtems/.../leon3/console/debugputs.c:38
38      while ((LEON3_Console_Uart[LEON3_Cpu_Index+port]->status & LEON_REG_UART_STATUS_THE) == 0);

(gdb) info threads

  8 Thread 167837702 (FTPD Wevnt) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  7 Thread 167837701 (FTPa Wevnt) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  6 Thread 167837700 (DCtx Wevnt) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  5 Thread 167837699 (DCrx Wevnt) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  4 Thread 167837698 (ntwk ready) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  3 Thread 167837697 (UI1  ready) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
  2 Thread 151060481 (Int. ready) 0x4002f760 in _Thread_Dispatch () at rtems/.../threaddispatch.c:109
* 1 Thread 167837703 (HTPD ready )  0x40001b5c in console_outbyte_polled (port=0, ch=113 `q`)
    at ../../../rtems/c/src/lib/libbsp/sparc/leon3/console/debugputs.c:38
		(gdb) thread 8

[Switching to thread 8 (Thread 167837702)]#0  0x4002f760 in _Thread_Dispatch ()
 at rtems/.../threaddispatch.c:109
109         _Context_Switch( &executing->Registers, &heir->Registers );
(gdb) bt

#0  0x4002f760 in _Thread_Dispatch () at rtems/cpukit/score/src/threaddispatch.c:109
#1  0x40013ee0 in rtems_event_receive(event_in=33554432, option_set=0, ticks=0, event_out=0x43fecc14)
    at ../../../../leon3/lib/include/rtems/score/thread.inl:205
#2  0x4002782c in rtems_bsdnet_event_receive (event_in=33554432, option_set=2, ticks=0,
    event_out=0x43fecc14) at rtems/cpukit/libnetworking/rtems/rtems_glue.c:641
#3  0x40027548 in soconnsleep (so=0x43f0cd70) at rtems/cpukit/libnetworking/rtems/rtems_glue.c:465
#4  0x40029118 in accept (s=3, name=0x43feccf0, namelen=0x43feccec) at rtems/.../rtems_syscall.c:215
#5  0x40004028 in daemon () at rtems/c/src/libnetworking/rtems_servers/ftpd.c:1925
#6  0x40053388 in _Thread_Handler () at rtems/cpukit/score/src/threadhandler.c:123
#7  0x40053270 in __res_mkquery (op=0, dname=0x0, class=0, type=0, data=0x0, datalen=0, newrr_in=0x0,
                                 buf=0x0, buflen=0)
    at ../rtems/cpukit/libnetworking/libc/res_mkquery.c:199
#8  0x00000008 in ?? ()
#9  0x00000008 in ?? ()
Previous frame identical to this frame (corrupt stack?)

In comparison to GRMON the frame command in GDB can be used to select a individual stack frame. One can also step between frames by issuing the up or down commands. The CPU registers can be listed using the info registers command. Note that the info registers command only can see the following registers for an inactive task: g0-g7, l0-l7, i0-i7, o0-o7, PC and PSR. The other registers will be displayed as 0:

gdb) frame 5

#5  0x40004028 in daemon () at rtems/.../rtems_servers/ftpd.c:1925
1925        ss = accept(s, (struct sockaddr *)&addr, &addrLen);

(gdb) info reg

g0             0x0      0
g1             0x0      0
g2             0xffffffff       -1
g3             0x0      0
g4             0x0      0
g5             0x0      0
g6             0x0      0
g7             0x0      0
o0             0x3      3
o1             0x43feccf0       1140772080
o2             0x43feccec       1140772076
o3             0x0      0
o4             0xf34000e4       -213909276
o5             0x4007cc00       1074252800
sp             0x43fecc88       0x43fecc88
o7             0x40004020       1073758240
l0             0x4007ce88       1074253448
l1             0x4007ce88       1074253448
l2             0x400048fc       1073760508
l3             0x43feccf0       1140772080
l4             0x3      3
l5             0x1      1
l6             0x0      0
l7             0x0      0
i0             0x0      0
i1             0x40003f94       1073758100
i2             0x0      0
i3             0x43ffafc8       1140830152
i4             0x0      0
i5             0x4007cd40       1074253120
fp             0x43fecd08       0x43fecd08
i7             0x40053380       1074082688
y              0x0      0
psr            0xf34000e0       -213909280
wim            0x0      0
tbr            0x0      0
pc             0x40004028       0x40004028 <daemon+148>
npc            0x4000402c       0x4000402c <daemon+152>
fsr            0x0      0
csr            0x0      0

There is no way for GRMON to determine if an address sent from GDB is physical or virtual. If an MMU unit is present in the system and it is enabled, then GRMON will assume that all addresses are virtual and try to translate them. When debugging an application that uses the MMU one typically have an image with physical addresses used to load data into the memory and a second image with debug-symbols of virtual addresses. It is therefore important to make sure that the MMU is enabled/disabled when each image is used.

The example below will show a typical case on how to handle virtual and physical addresses when debugging with GDB. The application being debugged is Linux and it consists of two different images created with Linuxbuild. The file image.ram contains physical addresses and a small loader, that among others configures the MMU, while the file image contains all the debug-symbols in virtual address-space.

First start GRMON and start the GDB server.

$ grmon -nb -gdb -xilusb

Then start GDB in a second shell, load both files into GDB, connect to GRMON and then upload the application into the system. The addresses will be interpreted as physical since the MMU is disabled when GRMON starts.

$ sparc-linux-gdb 
GNU gdb 6.8.0.20090916-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sparc-linux".
(gdb) file output/images/image.ram 
Reading symbols from /home/user/linuxbuild-1.0.2/output/images/image.ram...(no d
ebugging symbols found)...done.
(gdb) symbol-file output/images/image
Reading symbols from /home/user/linuxbuild-1.0.2/output/images/image...done.
(gdb) target extended-remote :2222
Remote debugging using :2222
t_tflt () at /home/user/linuxbuild-1.0.2/linux/linux-2.6-git/arch/sparc/kernel/h
ead_32.S:88
88	t_tflt:	SPARC_TFAULT                        /* Inst. Access Exception
 */
Current language:  auto; currently asm
(gdb) load
Loading section .text, size 0x10b0 lma 0x40000000
Loading section .data, size 0x50 lma 0x400010b0
Loading section .vmlinux, size 0x3f1a60 lma 0x40004000
Loading section .startup_prom, size 0x7ee0 lma 0x403f5a60
Start address 0x40000000, load size 4172352
Transfer rate: 18 KB/sec, 765 bytes/write.

The program must reach a state where the MMU is enabled before any virtual address can be translated. Software breakpoints cannot be used since the MMU is still disabled and GRMON won't translate them into a physical. Hardware breakpoints don't need to be translated into physical addresses, therefore set a hardware assisted breakpoint at 0xf0004000, which is the virtual start address for the Linux kernel.

(gdb) hbreak *0xf0004000
Hardware assisted breakpoint 1 at 0xf0004000: file /home/user/linuxbuild-1.0.2/l
inux/linux-2.6-git/arch/sparc/kernel/head_32.S, line 87.
(gdb) cont
Continuing.

Breakpoint 1, trapbase_cpu0 () at /home/user/linuxbuild-1.0.2/linux/linux-2.6-gi
t/arch/sparc/kernel/head_32.S:87
87	t_zero:	b gokernel; nop; nop; nop;

At this point the loader has enabled the MMU and both software breakpoints and symbols can be used.

(gdb) break leon_init_timers 
Breakpoint 2 at 0xf03cff14: file /home/user/linuxbuild-1.0.2/linux/linux-2.6-git
/arch/sparc/kernel/leon_kernel.c, line 116.

(gdb) cont
Continuing.

Breakpoint 2, leon_init_timers (counter_fn=0xf00180c8 <timer_interrupt>)
    at /home/user/linuxbuild-1.0.2/linux/linux-2.6-git/arch/sparc/kernel/leon_ke
rnel.c:116
116		leondebug_irq_disable = 0;
Current language:  auto; currently c
(gdb) bt
#0  leon_init_timers (counter_fn=0xf00180c8 <timer_interrupt>)
    at /home/user/linuxbuild-1.0.2/linux/linux-2.6-git/arch/sparc/kernel/leon_ke
rnel.c:116
#1  0xf03ce944 in time_init () at /home/user/linuxbuild-1.0.2/linux/linux-2.6-gi
t/arch/sparc/kernel/time_32.c:227
#2  0xf03cc13c in start_kernel () at /home/user/linuxbuild-1.0.2/linux/linux-2.6
-git/init/main.c:619
#3  0xf03cb804 in sun4c_continue_boot ()
#4  0xf03cb804 in sun4c_continue_boot ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info locals
eirq = <value optimized out>
rootnp = <value optimized out>
np = <value optimized out>
pp = <value optimized out>
len = 13
ampopts = <value optimized out>
(gdb) print len
$2 = 13

If the application for some reason need to be reloaded, then the MMU must first be disabled via GRMON. In addition all software breakpoints should be deleted before the application is restarted since the MMU has been disabled and GRMON won't translate virtual addresses anymore.

(gdb) mon mmu mctrl 0
mctrl: 006E0000  ctx: 00000000  ctxptr: 40440800  fsr: 00000000  far: 00000000
(gdb) load
Loading section .text, size 0x10b0 lma 0x40000000
Loading section .data, size 0x50 lma 0x400010b0
Loading section .vmlinux, size 0x3f1a60 lma 0x40004000
Loading section .startup_prom, size 0x7ee0 lma 0x403f5a60
Start address 0x40000000, load size 4172352
Transfer rate: 18 KB/sec, 765 bytes/write.
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) hbreak *0xf0004000
Hardware assisted breakpoint 3 at 0xf0004000: file /home/user/linuxbuild-1.0.2/l
inux/linux-2.6-git/arch/sparc/kernel/head_32.S, line 87.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/user/linuxbuild-1.0.2/output/images/image.ram 

Breakpoint 3, trapbase_cpu0 () at /home/user/linuxbuild-1.0.2/linux/linux-2.6-gi
t/arch/sparc/kernel/head_32.S:87
87	t_zero:	b gokernel; nop; nop; nop;
Current language:  auto; currently asm
(gdb) break leon_init_timers 
Breakpoint 4 at 0xf03cff14: file /home/user/linuxbuild-1.0.2/linux/linux-2.6-git
/arch/sparc/kernel/leon_kernel.c, line 116.
(gdb) cont
Continuing.

Breakpoint 4, leon_init_timers (counter_fn=0xf00180c8 <timer_interrupt>)
    at /home/user/linuxbuild-1.0.2/linux/linux-2.6-git/arch/sparc/kernel/leon_ke
rnel.c:116
116		leondebug_irq_disable = 0;
Current language:  auto; currently c

GRMON detects GDB access to register window frames in memory which are not yet flushed and only reside in the processor register file. When such a memory location is read, GRMON will read the correct value from the register file instead of the memory. This allows GDB to form a function trace-back without any (intrusive) modification of memory. This feature is disabled during debugging of code where traps are disabled, since no valid stack frame exist at that point.

To avoid a huge number of cache-flushes GRMON auto-detects when GDB loads a new application to memory, this approach however requires the user to restart the application after loading a file. Thus, loading files during run-time may not work as expected.

GDB must be built for the SPARC architecture, a native PC GDB does not work together with GRMON. The toolchains that Aeroflex Gaisler distributes comes with a patched and tested version of GDB targeting all SPARC LEON development tools.

Do not use the GDB where commands in parts of an application where traps are disabled (e.g.trap handlers). Since the stack pointer is not valid at this point, GDB might go into an infinite loop trying to unwind false stack frames. The thread support might not work either in some trap handler cases.

The step instruction commands si or stepi are implemented by GDB inserting software breakpoints through GRMON. This is an approach that is not possible when debugging in read-only memory such as boot sequences executed in PROM/FLASH. One can instead use hardware breakpoints using the GDB command hbreak manually.

thread info lists all threads currently available in the operating system. The currently running thread is marked with an asterisk.

grmon> thread info

  Name | Type     | Id         | Prio | Ticks    | Entry point             | PC           | State
-------------------------------------------------------------------------------------------------
  Int. | internal | 0x09010001 |  255 |      138 | _CPU_Thread_Idle_body   | 0x4002f760   | READY
-------------------------------------------------------------------------------------------------
  UI1  | classic  | 0x0a010001 |  120 |      290 | Init                    | 0x4002f760   | READY
-------------------------------------------------------------------------------------------------
  ntwk | classic  | 0x0a010002 |  100 |       11 | rtems_bsdnet_schedneti  | 0x4002f760   | READY
-------------------------------------------------------------------------------------------------
  DCrx | classic  | 0x0a010003 |  100 |        2 | rtems_bsdnet_schedneti  | 0x4002f760   | Wevnt
-------------------------------------------------------------------------------------------------
  DCtx | classic  | 0x0a010004 |  100 |        4 | rtems_bsdnet_schedneti  | 0x4002f760   | Wevnt
-------------------------------------------------------------------------------------------------
  FTPa | classic  | 0x0a010005 |   10 |        1 | split_command           | 0x4002f760   | Wevnt
-------------------------------------------------------------------------------------------------
  FTPD | classic  | 0x0a010006 |   10 |        1 | split_command           | 0x4002f760   | Wevnt
-------------------------------------------------------------------------------------------------
* HTPD | classic  | 0x0a010007 |   40 |       79 | rtems_initialize_webse  | 0x40001b60   | READY
-------------------------------------------------------------------------------------------------

thread bt ?id? lists the stack back trace. bt lists the back trace of the currently executing thread as usual.

grmon> thread bt 0x0a010003

    %pc
#0   0x4002f760   _Thread_Dispatch + 0x11c
#1   0x40013ed8   rtems_event_receive + 0x88
#2   0x40027824   rtems_bsdnet_event_receive + 0x18
#3   0x4000b664   websFooter + 0x484
#4   0x40027708   rtems_bsdnet_schednetisr + 0x158

A backtrace of the current thread (equivalent to the bt command):

grmon> thread bt 0x0a010007

    %pc          %sp
#0   0x40001b60   0x43fea130   console_outbyte_polled + 0x34
#1   0x400017fc   0x43fea130   console_write_support + 0x18
#2   0x4002dde8   0x43fea198   rtems_termios_puts + 0x128
#3   0x4002df60   0x43fea200   rtems_termios_puts + 0x2a0
#4   0x4002dfe8   0x43fea270   rtems_termios_write + 0x70
#5   0x400180a4   0x43fea2d8   rtems_io_write + 0x48
#6   0x4004eb98   0x43fea340   device_write + 0x2c
#7   0x40036ee4   0x43fea3c0   write + 0x90
#8   0x4001118c   0x43fea428   trace + 0x38
#9   0x4000518c   0x43fea498   websOpenListen + 0x108
#10  0x40004fb4   0x43fea500   websOpenServer + 0xc0
#11  0x40004b0c   0x43fea578   rtems_initialize_webserver + 0x204
#12  0x40004978   0x43fea770   rtems_initialize_webserver + 0x70
#13  0x40053380   0x43fea7d8   _Thread_Handler + 0x10c
#14  0x40053268   0x43fea840   __res_mkquery + 0x2c8

When the application is running with UART debug mode enabled the following key sequences will be available. The sequences can be used to adjust the input to what the target system expects.

GRMON supports programming of CFI compatible flash PROMs attached to the external memory bus, through the flash command. Flash programming is only supported if the target system contains one of the following memory controllers MCTRL, FTMCTRL, FTSRCTRL or SSRCTRL. The PROM bus width can be 8-, 16- or 32-bit. It is imperative that the PROM width in the MCFG1 register correctly reflects the width of the external PROM.

To program 8-bit and 16-bit PROMs, GRMON must be able to do byte (or half-word) accesses to the target system. To support this either connect with a JTAG debug link or have at least one working SRAM/SDRAM bank and a CPU available in the target system.

Some flash chips provides lock protection to prevent the flash from being accidentally written. The user is required to actively lock and unlock the flash. Note that the memory controller can disable all write cycles to the flash also, however GRMON automatically enables PROM write access before the flash is accessed.

The flash device configuration is auto-detected, the information is printed out like in the example below. One can verify the configuration so that the auto-detection is correct if problems are experienced. The block lock status (if implement by the flash chip) can be viewed like in the following example:

grmon2> flash
  Manuf.        : Intel             
  Device        : MT28F640J3        
  Device ID     : 09169e01734a9981  
  User ID       : ffffffffffffffff  
  
  1 x 8 Mbytes = 8 Mbytes total @ 0x00000000
  
  CFI information
  Flash family  : 1
  Flash size    : 64 Mbit
  Erase regions : 1
  Erase blocks  : 64
  Write buffer  : 32 bytes
  Lock-down     : Not supported
  Region  0     : 64 blocks of 128 kbytes

	grmon2> flash status
  Block lock status: U = Unlocked; L = Locked; D = Locked-down
  Block   0 @ 0x00000000 : L 
  Block   1 @ 0x00020000 : L 
  Block   2 @ 0x00040000 : L 
  Block   3 @ 0x00060000 : L 
...
  Block  60 @ 0x00780000 : L 
  Block  61 @ 0x007a0000 : L 
  Block  62 @ 0x007c0000 : L 
  Block  63 @ 0x007e0000 : L

A typical command sequence to erase and re-program a flash memory could be:

grmon2> flash unlock all
  Unlock complete

grmon2> flash erase all
  Erase in progress
  Block @ 0x007e0000 : code = 0x80  OK
  Erase complete

grmon2> flash load rom_image.prom
...
grmon2> flash lock all
  Lock complete

GRMON supports programming of SPI memory devices that are attached to a SPICTRL or SPIMCTRL core. The flash programming commands are available through the cores' debug drivers. A SPI flash connected to the SPICTRL controller is programmed using 'spi flash', for SPIMCTRL connected devices the 'spim flash' command is used instead. See the command reference for respective command for the complete syntax, below are some typical use cases exemplified.

When interacting with a memory device via SPICTRL the driver assumes that the clock scaler settings have been initialized to attain a frequency that is suitable for the memory device. When interacting with a memory device via SPIMCTRL all commands are issued with the normal scaler setting unless the alternate scaler has been enabled.

A command sequence to save the original first 32 bytes of data before erasing and programming the SPI memory device connected via SPICTRL could be:

spi set div16
spi flash select 1
spi flash dump 0 32 32bytes.srec
spi flash erase
spi flash load romfs.elf

The first command initializes the SPICTRL clock scaler. The second command selects a SPI memory device configuration and the third command dumps the first 32 bytes of the memory device to the file 32bytes.srec. The fourth command erases all blocks of the SPI flash. The last command loads the ELF-file romfs.elf into the device, the addresses are determined by the ELF-file section address.

Below is a command sequence to dump the data of a SPI memory device connected via SPIMCTRL. The first command tries to auto-detect the type of memory device. If auto-detection is successful GRMON will report the device selected. The second command dumps the first 128 bytes of the memory device to the file 128bytes.srec.

spim flash detect
spim flash dump 0 128 128bytes.srec

If target system has the JTAG AHB debug link, GRMON can connect to the system through Xilinx Parallel Cable III or IV. The cable should be connected to the host computers parallel port, and GRMON should be started with the -jtag switch. Use -jtagcable to select port. On Linux, you must have read and write permission, i.e. make sure that you are a member of the group 'lp'. I.a. on some systems the Linux module lp must be unloaded, since it uses the port.

JTAG debugging using the Xilinx USB Platform cable is supported on Linux and Windows systems. The platform cable models DLC9G and DLC10 are supported. The legacy model DLC9 is not supported. GRMON should be started with -xilusb switch. Certain FPGA boards have a USB platform cable logic implemented directly on the board, using a Cypress USB device and a dedicated Xilinx CPLD. GRMON can also connect to these boards, using the --xilusb switch.

On Linux systems, the Xilinx USB drivers must be installed by executing ’./setup_pcusb’ in the ISE bin/bin/lin directory (see ISE documentation). I.a. the program fxload must be available in /sbin on the used host, and libusb must be installed.

On Windows hosts follow the instructions below. the USB cable drivers should be installed from ISE or ISE-Webpack. Xilinx ISE 9.2i or later is required. Then install the filter driver, from the libusb-win32 project, by running install-filter-win.exe from the libusb package.

For GRLIB systems implemented on Altera devices GRMON can use USB blaster or Byte Blaster cable to connect to the system. GRMON is started with -altjtag switch. Drivers are included in the the Altera Quartus software, see Actel's documentation on how to install on your host computer.

On Linux systems, the path to Quartus shared libraries has to be defined in the LD_LIBRARY_PATH environment variable, i.e.

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/quartus/linux
$ grmon -altjtag
				
	GRMON2 LEON debug monitor v2.0.15 professional version
	...

On Windows, the path to the Quartus binary folder must the added to the environment variable PATH, see Appendix E, Appending environment variables in how to this. The default installation path to the binary folder should be similar to C:\altera\11.1sp2\quartus\bin, where 11.1sp2 is the version of Quartus.

JTAG debugging using a FTDI FT2232/FT4232 chip in MPSSE-JTAG-emulation mode is supported in Linux and Windows. GRMON has support for two different back ends, one based on libftdi and the other based on FTDI's official d2xx library.

When using Windows, GRMON will use the d2xx back end per default. FTDI’s D2XX driver must be installed. Drivers and installation guides can be found at FTDI's website.

In Linux, the libftdi back end is used per default. The user must also have read and write permission to the device file. This can be achieved by creating a udev rules file, /etc/udev/rules.d/51-ftdi.rules, containing the lines below and then reconnect the USB cable.

ATTR{idVendor}=="0403", ATTR{idProduct}=="6010", MODE="666"
					ATTR{idVendor}=="0403", ATTR{idProduct}=="6011", MODE="666"
					ATTR{idVendor}=="0403", ATTR{idProduct}=="6014", MODE="666"
					ATTR{idVendor}=="0403", ATTR{idProduct}=="cff8", MODE="666"

The Amontec JTAGkey is based on a FTDI device, therefore see the section called “FTDI FT4232/FT2232” about FTDI devices on how to connect. Note that the user does not need to specify VID/PID for the Amontec cable. The drivers and installation guide can be found at Amontec's website.

JTAG debugging using the Actel FlashPro 3/3x/4 cable is only possible for GRLIB systems implemented on Actel devices and on Windows hosts. This also requires FlashPro 9.1 SP1 software or later to be installed on the host computer (to be downloaded from Actel's website). Windows support is detailed at the website. GRMON is started with the -fpro switch and is only implemented for the GRMON professional version. Technical support is provided through Aeroflex Gaisler only via support@gaisler.com.

JTAG debugging using a Digilent JTAG HS1 cable is supported on Linux and Windows systems. Start GRMON with the -digilent switch to use this interface.

On Windows hosts, the Digilent Adept System software must be installed on the host computer, which can be downloaded from Digilent's website.

On Linux systems, the Digilent Adept Runtime x86 must be installed on the host computer, which can be downloaded from Digilent's website. The Adept v2.10.2 Runtime x86 supports the Linux distributions listed below.

On 64-bit Linux systems it's recommended to install the 32-bit runtime using the manual instructions from the README provided by the runtime distribution. Note that the 32-bit Digilent Adept runtime depends on 32-bit versions of FTID's libd2xx library and the libusb-1.0 library.

Below is a list of commandline switches that affects how the DSU driver interacts with the DSU hardware.

The driver for the debug support unit provides the commands listed in Table 5.1.

The DSU driver exports one Tcl variable per CPU (cpuN), they allow the user to access various registers of any CPU instead of using the standard reg, float and cpu commands. The variables are mostly intended for Tcl scripting. See the section called “Multi-processor support” for more information how the cpu variable can be used.

The driver for the greth core provides the commands listed in Table 5.2.

The driver for the Debug support unit provides the commands listed in Table 5.3.

The pci trace commands are supported by the cores PCITRACE, GRPCI2 and GRPCI2_TB. The commands can be used to control the trace and viewing trace data. With the commands it is possible to set up trigger conditions that must match to set the trigger off. When the triggering condition is matched the AHBTRACE stops the recording of the PCI bus and the log is available for inspection using the pci trace log command. The pci trace tdelay command can be used to delay the stop of the trace recording after a trigging match.

The info sys command displays the size of the trace buffer in number of lines.

  pcitrace0 Aeroflex Gaisler  32-bit PCI Trace Buffer    
            APB: C0101000 - C0200000
            Trace buffer size: 128 lines
  pci0      Aeroflex Gaisler  GRPCI2 PCI/AHB bridge    
            AHB Master 5
            AHB: C0000000 - D0000000
            AHB: FFF00000 - FFF40000
            APB: 80000600 - 80000700
            IRQ: 6
            Trace buffer size: 1024 lines
  pcitrace1 Aeroflex Gaisler  GRPCI2 Trace buffer    
            APB: 80040000 - 80080000
            Trace buffer size: 1024 lines