]> git.proxmox.com Git - mirror_ubuntu-bionic-kernel.git/blame - arch/blackfin/Kconfig.debug
Blackfin: SMP: add flush_tlb_kernel_range stub
[mirror_ubuntu-bionic-kernel.git] / arch / blackfin / Kconfig.debug
CommitLineData
74ce8322
MF
1menu "Kernel hacking"
2
3source "lib/Kconfig.debug"
4
a45d575f
RG
5config DEBUG_STACKOVERFLOW
6 bool "Check for stack overflows"
7 depends on DEBUG_KERNEL
8 help
9 This option will cause messages to be printed if free stack space
10 drops below a certain limit.
11
12config DEBUG_STACK_USAGE
13 bool "Enable stack utilization instrumentation"
14 depends on DEBUG_KERNEL
15 help
16 Enables the display of the minimum amount of free stack which each
17 task has ever had available in the sysrq-T output.
18
19 This option will slow down process creation somewhat.
20
9f06c38f
RG
21config DEBUG_VERBOSE
22 bool "Verbose fault messages"
23 default y
24 select PRINTK
25 help
26 When a program crashes due to an exception, or the kernel detects
27 an internal error, the kernel can print a not so brief message
28 explaining what the problem was. This debugging information is
29 useful to developers and kernel hackers when tracking down problems,
30 but mostly meaningless to other people. This is always helpful for
31 debugging but serves no purpose on a production system.
32 Most people should say N here.
33
74ce8322
MF
34config DEBUG_MMRS
35 bool "Generate Blackfin MMR tree"
36 select DEBUG_FS
37 help
38 Create a tree of Blackfin MMRs via the debugfs tree. If
39 you enable this, you will find all MMRs laid out in the
40 /sys/kernel/debug/blackfin/ directory where you can read/write
41 MMRs directly from userspace. This is obviously just a debug
42 feature.
43
44config DEBUG_HWERR
45 bool "Hardware error interrupt debugging"
46 depends on DEBUG_KERNEL
47 help
48 When enabled, the hardware error interrupt is never disabled, and
49 will happen immediately when an error condition occurs. This comes
50 at a slight cost in code size, but is necessary if you are getting
51 hardware error interrupts and need to know where they are coming
52 from.
53
b9a3899d
RG
54config EXACT_HWERR
55 bool "Try to make Hardware errors exact"
56 depends on DEBUG_HWERR
57 help
58 By default, the Blackfin hardware errors are not exact - the error
59 be reported multiple cycles after the error happens. This delay
60 can cause the wrong application, or even the kernel to receive a
61 signal to be killed. If you are getting HW errors in your system,
62 try turning this on to ensure they are at least comming from the
63 proper thread.
64
65 On production systems, it is safe (and a small optimization) to say N.
66
0c7a6b21
RG
67config DEBUG_DOUBLEFAULT
68 bool "Debug Double Faults"
69 default n
70 help
71 If an exception is caused while executing code within the exception
72 handler, the NMI handler, the reset vector, or in emulator mode,
73 a double fault occurs. On the Blackfin, this is a unrecoverable
74 event. You have two options:
75 - RESET exactly when double fault occurs. The excepting
76 instruction address is stored in RETX, where the next kernel
77 boot will print it out.
78 - Print debug message. This is much more error prone, although
79 easier to handle. It is error prone since:
80 - The excepting instruction is not committed.
81 - All writebacks from the instruction are prevented.
82 - The generated exception is not taken.
83 - The EXCAUSE field is updated with an unrecoverable event
84 The only way to check this is to see if EXCAUSE contains the
85 unrecoverable event value at every exception return. By selecting
86 this option, you are skipping over the faulting instruction, and
87 hoping things stay together enough to print out a debug message.
88
89 This does add a little kernel code, but is the only method to debug
90 double faults - if unsure say "Y"
91
92choice
93 prompt "Double Fault Failure Method"
94 default DEBUG_DOUBLEFAULT_PRINT
95 depends on DEBUG_DOUBLEFAULT
96
97config DEBUG_DOUBLEFAULT_PRINT
98 bool "Print"
99
100config DEBUG_DOUBLEFAULT_RESET
101 bool "Reset"
102
103endchoice
104
74ce8322
MF
105config DEBUG_ICACHE_CHECK
106 bool "Check Instruction cache coherency"
107 depends on DEBUG_KERNEL
108 depends on DEBUG_HWERR
109 help
110 Say Y here if you are getting weird unexplained errors. This will
111 ensure that icache is what SDRAM says it should be by doing a
112 byte wise comparison between SDRAM and instruction cache. This
113 also relocates the irq_panic() function to L1 memory, (which is
114 un-cached).
115
116config DEBUG_HUNT_FOR_ZERO
117 bool "Catch NULL pointer reads/writes"
118 default y
119 help
120 Say Y here to catch reads/writes to anywhere in the memory range
121 from 0x0000 - 0x0FFF (the first 4k) of memory. This is useful in
122 catching common programming errors such as NULL pointer dereferences.
123
124 Misbehaving applications will be killed (generate a SEGV) while the
125 kernel will trigger a panic.
126
127 Enabling this option will take up an extra entry in CPLB table.
128 Otherwise, there is no extra overhead.
129
130config DEBUG_BFIN_HWTRACE_ON
131 bool "Turn on Blackfin's Hardware Trace"
132 default y
133 help
134 All Blackfins include a Trace Unit which stores a history of the last
135 16 changes in program flow taken by the program sequencer. The history
136 allows the user to recreate the program sequencer’s recent path. This
137 can be handy when an application dies - we print out the execution
138 path of how it got to the offending instruction.
139
140 By turning this off, you may save a tiny amount of power.
141
142choice
143 prompt "Omit loop Tracing"
144 default DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
145 depends on DEBUG_BFIN_HWTRACE_ON
146 help
147 The trace buffer can be configured to omit recording of changes in
148 program flow that match either the last entry or one of the last
149 two entries. Omitting one of these entries from the record prevents
150 the trace buffer from overflowing because of any sort of loop (for, do
151 while, etc) in the program.
152
153 Because zero-overhead Hardware loops are not recorded in the trace buffer,
154 this feature can be used to prevent trace overflow from loops that
155 are nested four deep.
156
157config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
158 bool "Trace all Loops"
159 help
160 The trace buffer records all changes of flow
161
162config DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
163 bool "Compress single-level loops"
164 help
165 The trace buffer does not record single loops - helpful if trace
166 is spinning on a while or do loop.
167
168config DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
169 bool "Compress two-level loops"
170 help
171 The trace buffer does not record loops two levels deep. Helpful if
172 the trace is spinning in a nested loop
173
174endchoice
175
176config DEBUG_BFIN_HWTRACE_COMPRESSION
177 int
178 depends on DEBUG_BFIN_HWTRACE_ON
179 default 0 if DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
180 default 1 if DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
181 default 2 if DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
182
183
184config DEBUG_BFIN_HWTRACE_EXPAND
185 bool "Expand Trace Buffer greater than 16 entries"
186 depends on DEBUG_BFIN_HWTRACE_ON
187 default n
188 help
189 By selecting this option, every time the 16 hardware entries in
190 the Blackfin's HW Trace buffer are full, the kernel will move them
191 into a software buffer, for dumping when there is an issue. This
192 has a great impact on performance, (an interrupt every 16 change of
193 flows) and should normally be turned off, except in those nasty
194 debugging sessions
195
196config DEBUG_BFIN_HWTRACE_EXPAND_LEN
197 int "Size of Trace buffer (in power of 2k)"
198 range 0 4
199 depends on DEBUG_BFIN_HWTRACE_EXPAND
200 default 1
201 help
202 This sets the size of the software buffer that the trace information
203 is kept in.
204 0 for (2^0) 1k, or 256 entries,
205 1 for (2^1) 2k, or 512 entries,
206 2 for (2^2) 4k, or 1024 entries,
207 3 for (2^3) 8k, or 2048 entries,
208 4 for (2^4) 16k, or 4096 entries
209
210config DEBUG_BFIN_NO_KERN_HWTRACE
e60cb8a9 211 bool "Turn off hwtrace in CPLB handlers"
74ce8322 212 depends on DEBUG_BFIN_HWTRACE_ON
e60cb8a9 213 default y
74ce8322 214 help
e60cb8a9 215 The CPLB error handler contains a lot of flow changes which can
74ce8322
MF
216 quickly fill up the hardware trace buffer. When debugging crashes,
217 the hardware trace may indicate that the problem lies in kernel
218 space when in reality an application is buggy.
219
220 Say Y here to disable hardware tracing in some known "jumpy" pieces
221 of code so that the trace buffer will extend further back.
222
223config EARLY_PRINTK
224 bool "Early printk"
225 default n
0cfbb323 226 select SERIAL_CORE_CONSOLE
74ce8322
MF
227 help
228 This option enables special console drivers which allow the kernel
229 to print messages very early in the bootup process.
230
231 This is useful for kernel debugging when your machine crashes very
232 early before the console code is initialized. After enabling this
233 feature, you must add "earlyprintk=serial,uart0,57600" to the
234 command line (bootargs). It is safe to say Y here in all cases, as
235 all of this lives in the init section and is thrown away after the
236 kernel boots completely.
237
60ffdb36
GY
238config NMI_WATCHDOG
239 bool "Enable NMI watchdog to help debugging lockup on SMP"
240 default n
241 depends on (SMP && !BFIN_SCRATCH_REG_RETN)
242 help
243 If any CPU in the system does not execute the period local timer
244 interrupt for more than 5 seconds, then the NMI handler dumps debug
245 information. This information can be used to debug the lockup.
246
74ce8322
MF
247config CPLB_INFO
248 bool "Display the CPLB information"
249 help
cf93425d 250 Display the CPLB information via /proc/cplbinfo.
74ce8322
MF
251
252config ACCESS_CHECK
253 bool "Check the user pointer address"
254 default y
255 help
256 Usually the pointer transfer from user space is checked to see if its
257 address is in the kernel space.
258
259 Say N here to disable that check to improve the performance.
260
c40cdb2c
MF
261config BFIN_ISRAM_SELF_TEST
262 bool "isram boot self tests"
263 default n
264 help
265 Run some self tests of the isram driver code at boot.
266
74ce8322 267endmenu