arch/blackfin/Kconfig.debug - kernel/prism - Git at Google

 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 HAVE_ARCH_KGDB
 	def_bool y

 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 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
	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 HAVE_ARCH_KGDB
	def_bool y

	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 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