[mirror_ubuntu-bionic-kernel.git] / arch / blackfin / Kconfig.debug

menu "Kernel hacking"

source "lib/Kconfig.debug"

config DEBUG_STACKOVERFLOW
	bool "Check for stack overflows"
	depends on DEBUG_KERNEL
	help
	  This option will cause messages to be printed if free stack space
	  drops below a certain limit.

config DEBUG_STACK_USAGE
	bool "Enable stack utilization instrumentation"
	depends on DEBUG_KERNEL
	help
	  Enables the display of the minimum amount of free stack which each
	  task has ever had available in the sysrq-T output.

	  This option will slow down process creation somewhat.

config DEBUG_VERBOSE
	bool "Verbose fault messages"
	default y
	select PRINTK
	help
	  When a program crashes due to an exception, or the kernel detects
	  an internal error, the kernel can print a not so brief message
	  explaining what the problem was. This debugging information is
	  useful to developers and kernel hackers when tracking down problems,
	  but mostly meaningless to other people. This is always helpful for
	  debugging but serves no purpose on a production system.
	  Most people should say N here.

config DEBUG_MMRS
	bool "Generate Blackfin MMR tree"
	select DEBUG_FS
	help
	  Create a tree of Blackfin MMRs via the debugfs tree.  If
	  you enable this, you will find all MMRs laid out in the
	  /sys/kernel/debug/blackfin/ directory where you can read/write
	  MMRs directly from userspace.  This is obviously just a debug
	  feature.

config DEBUG_HWERR
	bool "Hardware error interrupt debugging"
	depends on DEBUG_KERNEL
	help
	  When enabled, the hardware error interrupt is never disabled, and
	  will happen immediately when an error condition occurs.  This comes
	  at a slight cost in code size, but is necessary if you are getting
	  hardware error interrupts and need to know where they are coming
	  from.

config EXACT_HWERR
	bool "Try to make Hardware errors exact"
	depends on DEBUG_HWERR
	help
	  By default, the Blackfin hardware errors are not exact - the error
          be reported multiple cycles after the error happens. This delay
	  can cause the wrong application, or even the kernel to receive a
	  signal to be killed. If you are getting HW errors in your system,
	  try turning this on to ensure they are at least comming from the
	  proper thread.

	  On production systems, it is safe (and a small optimization) to say N.

config DEBUG_DOUBLEFAULT
	bool "Debug Double Faults"
	default n
	help
	  If an exception is caused while executing code within the exception
	  handler, the NMI handler, the reset vector, or in emulator mode,
	  a double fault occurs. On the Blackfin, this is a unrecoverable
	  event. You have two options:
	  - RESET exactly when double fault occurs. The excepting
	    instruction address is stored in RETX, where the next kernel
	    boot will print it out.
	  - Print debug message. This is much more error prone, although
	    easier to handle. It is error prone since:
	    - The excepting instruction is not committed.
	    - All writebacks from the instruction are prevented.
	    - The generated exception is not taken.
	    - The EXCAUSE field is updated with an unrecoverable event
	    The only way to check this is to see if EXCAUSE contains the
	    unrecoverable event value at every exception return. By selecting
	    this option, you are skipping over the faulting instruction, and 
	    hoping things stay together enough to print out a debug message.

	  This does add a little kernel code, but is the only method to debug
	  double faults - if unsure say "Y"

choice
	prompt "Double Fault Failure Method"
	default DEBUG_DOUBLEFAULT_PRINT
	depends on DEBUG_DOUBLEFAULT

config DEBUG_DOUBLEFAULT_PRINT
	bool "Print"

config DEBUG_DOUBLEFAULT_RESET
	bool "Reset"

endchoice

config DEBUG_ICACHE_CHECK
	bool "Check Instruction cache coherency"
	depends on DEBUG_KERNEL
	depends on DEBUG_HWERR
	help
	  Say Y here if you are getting weird unexplained errors. This will
	  ensure that icache is what SDRAM says it should be by doing a
	  byte wise comparison between SDRAM and instruction cache. This
	  also relocates the irq_panic() function to L1 memory, (which is
	  un-cached).

config DEBUG_HUNT_FOR_ZERO
	bool "Catch NULL pointer reads/writes"
	default y
	help
	  Say Y here to catch reads/writes to anywhere in the memory range
	  from 0x0000 - 0x0FFF (the first 4k) of memory.  This is useful in
	  catching common programming errors such as NULL pointer dereferences.

	  Misbehaving applications will be killed (generate a SEGV) while the
	  kernel will trigger a panic.

	  Enabling this option will take up an extra entry in CPLB table.
	  Otherwise, there is no extra overhead.

config DEBUG_BFIN_HWTRACE_ON
	bool "Turn on Blackfin's Hardware Trace"
	default y
	help
	  All Blackfins include a Trace Unit which stores a history of the last
	  16 changes in program flow taken by the program sequencer. The history
	  allows the user to recreate the program sequencer’s recent path. This
	  can be handy when an application dies - we print out the execution
	  path of how it got to the offending instruction.

	  By turning this off, you may save a tiny amount of power.

choice
	prompt "Omit loop Tracing"
	default DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
	depends on DEBUG_BFIN_HWTRACE_ON
	help
	  The trace buffer can be configured to omit recording of changes in
	  program flow that match either the last entry or one of the last
	  two entries. Omitting one of these entries from the record prevents
	  the trace buffer from overflowing because of any sort of loop (for, do
	  while, etc) in the program.

	  Because zero-overhead Hardware loops are not recorded in the trace buffer,
	  this feature can be used to prevent trace overflow from loops that
	  are nested four deep.

config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
	bool "Trace all Loops"
	help
	  The trace buffer records all changes of flow 

config DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
	bool "Compress single-level loops"
	help
	  The trace buffer does not record single loops - helpful if trace 
	  is spinning on a while or do loop.

config DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
	bool "Compress two-level loops"
	help
	  The trace buffer does not record loops two levels deep. Helpful if
	  the trace is spinning in a nested loop

endchoice

config DEBUG_BFIN_HWTRACE_COMPRESSION
	int
	depends on DEBUG_BFIN_HWTRACE_ON
	default 0 if DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
	default 1 if DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
	default 2 if DEBUG_BFIN_HWTRACE_COMPRESSION_TWO


config DEBUG_BFIN_HWTRACE_EXPAND
	bool "Expand Trace Buffer greater than 16 entries"
	depends on DEBUG_BFIN_HWTRACE_ON
	default n
	help
	  By selecting this option, every time the 16 hardware entries in
	  the Blackfin's HW Trace buffer are full, the kernel will move them
	  into a software buffer, for dumping when there is an issue. This 
	  has a great impact on performance, (an interrupt every 16 change of 
	  flows) and should normally be turned off, except in those nasty
	  debugging sessions

config DEBUG_BFIN_HWTRACE_EXPAND_LEN
	int "Size of Trace buffer (in power of 2k)"
	range 0 4
	depends on DEBUG_BFIN_HWTRACE_EXPAND
	default 1
	help
	  This sets the size of the software buffer that the trace information
	  is kept in.
	  0 for (2^0)  1k, or 256 entries,
	  1 for (2^1)  2k, or 512 entries,
	  2 for (2^2)  4k, or 1024 entries,
	  3 for (2^3)  8k, or 2048 entries,
	  4 for (2^4) 16k, or 4096 entries

config DEBUG_BFIN_NO_KERN_HWTRACE
	bool "Turn off hwtrace in CPLB handlers"
	depends on DEBUG_BFIN_HWTRACE_ON
	default y
	help
	  The CPLB error handler contains a lot of flow changes which can
	  quickly fill up the hardware trace buffer.  When debugging crashes,
	  the hardware trace may indicate that the problem lies in kernel
	  space when in reality an application is buggy.

	  Say Y here to disable hardware tracing in some known "jumpy" pieces
	  of code so that the trace buffer will extend further back.

config EARLY_PRINTK
	bool "Early printk" 
	default n
	select SERIAL_CORE_CONSOLE
	help
	  This option enables special console drivers which allow the kernel
	  to print messages very early in the bootup process.

	  This is useful for kernel debugging when your machine crashes very
	  early before the console code is initialized. After enabling this
	  feature, you must add "earlyprintk=serial,uart0,57600" to the
	  command line (bootargs). It is safe to say Y here in all cases, as
	  all of this lives in the init section and is thrown away after the
	  kernel boots completely.

config NMI_WATCHDOG
	bool "Enable NMI watchdog to help debugging lockup on SMP"
	default n
	depends on (SMP && !BFIN_SCRATCH_REG_RETN)
	help
	  If any CPU in the system does not execute the period local timer
	  interrupt for more than 5 seconds, then the NMI handler dumps debug
	  information. This information can be used to debug the lockup.

config CPLB_INFO
	bool "Display the CPLB information"
	help
	  Display the CPLB information via /proc/cplbinfo.

config ACCESS_CHECK
	bool "Check the user pointer address"
	default y
	help
	  Usually the pointer transfer from user space is checked to see if its
	  address is in the kernel space.

	  Say N here to disable that check to improve the performance.

config BFIN_ISRAM_SELF_TEST
	bool "isram boot self tests"
	default n
	help
	  Run some self tests of the isram driver code at boot.

endmenu
Commit	Line	Data
74ce8322 MF	1	menu "Kernel hacking"
	2
	3	source "lib/Kconfig.debug"
	4
a45d575f RG	5	config 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
	12	config 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	21	config 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	34	config 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
	44	config 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	54	config 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	67	config 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
	92	choice
	93	prompt "Double Fault Failure Method"
	94	default DEBUG_DOUBLEFAULT_PRINT
	95	depends on DEBUG_DOUBLEFAULT
	96
	97	config DEBUG_DOUBLEFAULT_PRINT
	98	bool "Print"
	99
	100	config DEBUG_DOUBLEFAULT_RESET
	101	bool "Reset"
	102
	103	endchoice
	104
74ce8322 MF	105	config 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
	116	config 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
	130	config 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
	142	choice
	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
	157	config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
	158	bool "Trace all Loops"
	159	help
	160	The trace buffer records all changes of flow
	161
	162	config 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
	168	config 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
174	endchoice
175
176	config 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
184	config 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
196	config 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
210	config 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
	223	config 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	238	config 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	247	config CPLB_INFO
	248	bool "Display the CPLB information"
	249	help
cf93425d	250	Display the CPLB information via /proc/cplbinfo.
74ce8322 MF	251
	252	config 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	261	config 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	267	endmenu