Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | ==================== |
2 | DEBUGGING FR-V LINUX | |
3 | ==================== | |
4 | ||
5 | ||
6 | The kernel contains a GDB stub that talks GDB remote protocol across a serial | |
7 | port. This permits GDB to single step through the kernel, set breakpoints and | |
8 | trap exceptions that happen in kernel space and interrupt execution. It also | |
9 | permits the NMI interrupt button or serial port events to jump the kernel into | |
10 | the debugger. | |
11 | ||
12 | On the CPUs that have on-chip UARTs (FR400, FR403, FR405, FR555), the | |
13 | GDB stub hijacks a serial port for its own purposes, and makes it | |
14 | generate level 15 interrupts (NMI). The kernel proper cannot see the serial | |
15 | port in question under these conditions. | |
16 | ||
17 | On the MB93091-VDK CPU boards, the GDB stub uses UART1, which would otherwise | |
18 | be /dev/ttyS1. On the MB93093-PDK, the GDB stub uses UART0. Therefore, on the | |
19 | PDK there is no externally accessible serial port and the serial port to | |
20 | which the touch screen is attached becomes /dev/ttyS0. | |
21 | ||
22 | Note that the GDB stub runs entirely within CPU debug mode, and so should not | |
23 | incur any exceptions or interrupts whilst it is active. In particular, note | |
24 | that the clock will lose time since it is implemented in software. | |
25 | ||
26 | ||
27 | ================== | |
28 | KERNEL PREPARATION | |
29 | ================== | |
30 | ||
31 | Firstly, a debuggable kernel must be built. To do this, unpack the kernel tree | |
32 | and copy the configuration that you wish to use to .config. Then reconfigure | |
33 | the following things on the "Kernel Hacking" tab: | |
34 | ||
35 | (*) "Include debugging information" | |
36 | ||
37 | Set this to "Y". This causes all C and Assembly files to be compiled | |
38 | to include debugging information. | |
39 | ||
40 | (*) "In-kernel GDB stub" | |
41 | ||
42 | Set this to "Y". This causes the GDB stub to be compiled into the | |
43 | kernel. | |
44 | ||
45 | (*) "Immediate activation" | |
46 | ||
47 | Set this to "Y" if you want the GDB stub to activate as soon as possible | |
48 | and wait for GDB to connect. This allows you to start tracing right from | |
49 | the beginning of start_kernel() in init/main.c. | |
50 | ||
51 | (*) "Console through GDB stub" | |
52 | ||
53 | Set this to "Y" if you wish to be able to use "console=gdb0" on the | |
54 | command line. That tells the kernel to pass system console messages to | |
55 | GDB (which then prints them on its standard output). This is useful when | |
56 | debugging the serial drivers that'd otherwise be used to pass console | |
57 | messages to the outside world. | |
58 | ||
59 | Then build as usual, download to the board and execute. Note that if | |
60 | "Immediate activation" was selected, then the kernel will wait for GDB to | |
61 | attach. If not, then the kernel will boot immediately and GDB will have to | |
5d3f083d | 62 | interrupt it or wait for an exception to occur before doing anything with |
1da177e4 LT |
63 | the kernel. |
64 | ||
65 | ||
66 | ========================= | |
67 | KERNEL DEBUGGING WITH GDB | |
68 | ========================= | |
69 | ||
70 | Set the serial port on the computer that's going to run GDB to the appropriate | |
71 | baud rate. Assuming the board's debug port is connected to ttyS0/COM1 on the | |
72 | computer doing the debugging: | |
73 | ||
74 | stty -F /dev/ttyS0 115200 | |
75 | ||
76 | Then start GDB in the base of the kernel tree: | |
77 | ||
78 | frv-uclinux-gdb linux [uClinux] | |
79 | ||
80 | Or: | |
81 | ||
82 | frv-uclinux-gdb vmlinux [MMU linux] | |
83 | ||
84 | When the prompt appears: | |
85 | ||
86 | GNU gdb frv-031024 | |
87 | Copyright 2003 Free Software Foundation, Inc. | |
88 | GDB is free software, covered by the GNU General Public License, and you are | |
89 | welcome to change it and/or distribute copies of it under certain conditions. | |
90 | Type "show copying" to see the conditions. | |
91 | There is absolutely no warranty for GDB. Type "show warranty" for details. | |
92 | This GDB was configured as "--host=i686-pc-linux-gnu --target=frv-uclinux"... | |
93 | (gdb) | |
94 | ||
95 | Attach to the board like this: | |
96 | ||
97 | (gdb) target remote /dev/ttyS0 | |
98 | Remote debugging using /dev/ttyS0 | |
99 | start_kernel () at init/main.c:395 | |
100 | (gdb) | |
101 | ||
102 | This should show the appropriate lines from the source too. The kernel can | |
103 | then be debugged almost as if it's any other program. | |
104 | ||
105 | ||
106 | =============================== | |
107 | INTERRUPTING THE RUNNING KERNEL | |
108 | =============================== | |
109 | ||
110 | The kernel can be interrupted whilst it is running, causing a jump back to the | |
111 | GDB stub and the debugger: | |
112 | ||
113 | (*) Pressing Ctrl-C in GDB. This will cause GDB to try and interrupt the | |
114 | kernel by sending an RS232 BREAK over the serial line to the GDB | |
115 | stub. This will (mostly) immediately interrupt the kernel and return it | |
116 | to the debugger. | |
117 | ||
118 | (*) Pressing the NMI button on the board will also cause a jump into the | |
119 | debugger. | |
120 | ||
121 | (*) Setting a software breakpoint. This sets a break instruction at the | |
122 | desired location which the GDB stub then traps the exception for. | |
123 | ||
124 | (*) Setting a hardware breakpoint. The GDB stub is capable of using the IBAR | |
125 | and DBAR registers to assist debugging. | |
126 | ||
127 | Furthermore, the GDB stub will intercept a number of exceptions automatically | |
128 | if they are caused by kernel execution. It will also intercept BUG() macro | |
a982ac06 | 129 | invocation. |
1da177e4 | 130 |