2007-11-21 15:50:49 +00:00
|
|
|
|
menu "Kernel hacking"
|
|
|
|
|
|
|
|
|
|
source "lib/Kconfig.debug"
|
|
|
|
|
|
2008-10-13 06:07:19 +00:00
|
|
|
|
config HAVE_ARCH_KGDB
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2007-11-21 15:50:49 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2008-10-08 08:27:12 +00:00
|
|
|
|
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
|
|
|
|
|
|
2007-11-21 15:50:49 +00:00
|
|
|
|
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 "Trace user apps (turn off hwtrace in kernel)"
|
|
|
|
|
depends on DEBUG_BFIN_HWTRACE_ON
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Some pieces of the kernel contain 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
|
2008-10-09 09:39:37 +00:00
|
|
|
|
select SERIAL_CORE_CONSOLE
|
2007-11-21 15:50:49 +00:00
|
|
|
|
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
|
2008-02-02 07:32:40 +00:00
|
|
|
|
Display the CPLB information via /proc/cplbinfo.
|
2007-11-21 15:50:49 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
endmenu
|