Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6

1.5 SuperH

----------

The following SuperH processors are supported by cpufreq:

SH-3

SH-4

All SuperH processors supporting rate rounding through the clock

framework are supported by cpufreq.

1.6 Blackfin

------------

This file describes the configuration and behavior of KGDB for the SH

kernel. Based on a description from Henry Bell <henry.bell@st.com>, it

has been modified to account for quirks in the current implementation.

Version

=======

This version of KGDB was written for 2.4.xx kernels for the SH architecture.

Further documentation is available from the linux-sh project website.

Debugging Setup: Host

======================

The two machines will be connected together via a serial line - this

should be a null modem cable i.e. with a twist.

On your DEVELOPMENT machine, go to your kernel source directory and

build the kernel, enabling KGDB support in the "kernel hacking" section.

This includes the KGDB code, and also makes the kernel be compiled with

the "-g" option set -- necessary for debugging.

To install this new kernel, use the following installation procedure.

Decide on which tty port you want the machines to communicate, then

cable them up back-to-back using the null modem.  On the DEVELOPMENT

machine, you may wish to create an initialization file called .gdbinit

(in the kernel source directory or in your home directory) to execute 

commonly-used commands at startup.

A minimal .gdbinit might look like this:

  file vmlinux

  set remotebaud 115200

  target remote /dev/ttyS0

Change the "target" definition so that it specifies the tty port that

you intend to use.  Change the "remotebaud" definition to match the

data rate that you are going to use for the com line (115200 is the

default). 

Debugging Setup: Target

========================

By default, the KGDB stub will communicate with the host GDB using

ttySC1 at 115200 baud, 8 databits, no parity; these defaults can be

changed in the kernel configuration. As the kernel starts up, KGDB will

initialize so that breakpoints, kernel segfaults, and so forth will

generally enter the debugger.

This behavior can be modified by including the "kgdb" option in the

kernel command line; this option has the general form:

  kgdb=<ttyspec>,<action>

The <ttyspec> indicates the port to use, and can optionally specify

baud, parity and databits -- e.g. "ttySC0,9600N8" or "ttySC1,19200".

The <action> can be "halt" or "disabled".  The "halt" action enters the

debugger via a breakpoint as soon as kgdb is initialized; the "disabled"

action causes kgdb to ignore kernel segfaults and such until explicitly

entered by a breakpoint in the code or by external action (sysrq or NMI). 

(Both <ttyspec> and <action> can appear alone, w/o the separating comma.)

For example, if you wish to debug early in kernel startup code, you

might specify the halt option:

  kgdb=halt

Boot the TARGET machine, which will appear to hang. 

On your DEVELOPMENT machine, cd to the source directory and run the gdb

program.  (This is likely to be a cross GDB which runs on your host but

is built for an SH target.) If everything is working correctly you

should see gdb print out a few lines indicating that a breakpoint has

been taken.  It will actually show a line of code in the target kernel

inside the gdbstub activation code.

NOTE: BE SURE TO TERMINATE OR SUSPEND any other host application which

may be using the same serial port (for example, a terminal emulator you

have been using to connect to the target boot code.)  Otherwise, data

from the target may not all get to GDB!

You can now use whatever gdb commands you like to set breakpoints.

Enter "continue" to start your target machine executing again.  At this

point the target system will run at full speed until it encounters

your breakpoint or gets a segment violation in the kernel, or whatever.

Serial Ports: KGDB, Console

============================

This version of KGDB may not gracefully handle conflict with other

drivers in the kernel using the same port. If KGDB is configured on the

same port (and with the same parameters) as the kernel console, or if

CONFIG_SH_KGDB_CONSOLE is configured, things should be fine (though in

some cases console messages may appear twice through GDB).  But if the

KGDB port is not the kernel console and used by another serial driver

which assumes different serial parameters (e.g. baud rate) KGDB may not

recover.

Also, when KGDB is entered via sysrq-g (requires CONFIG_KGDB_SYSRQ) and

the kgdb port uses the same port as the console, detaching GDB will not

restore the console to working order without the port being re-opened.

Another serious consequence of this is that GDB currently CANNOT break

into KGDB externally (e.g. via ^C or <BREAK>); unless a breakpoint or

error is encountered, the only way to enter KGDB after the initial halt

(see above) is via NMI (CONFIG_KGDB_NMI) or sysrq-g (CONFIG_KGDB_SYSRQ).

Code is included for the basic Hitachi Solution Engine boards to allow

the use of ttyS0 for KGDB if desired; this is less robust, but may be

useful in some cases.  (This cannot be selected using the config file, 

but only through the kernel command line, e.g. "kgdb=ttyS0", though the

configured defaults for baud rate etc. still apply if not overridden.)

If gdbstub Does Not Work

========================

If it doesn't work, you will have to troubleshoot it.  Do the easy

things first like double checking your cabling and data rates.  You

might try some non-kernel based programs to see if the back-to-back

connection works properly.  Just something simple like cat /etc/hosts

/dev/ttyS0 on one machine and cat /dev/ttyS0 on the other will tell you

if you can send data from one machine to the other.  There is no point

in tearing out your hair in the kernel if the line doesn't work.

If you need to debug the GDB/KGDB communication itself, the gdb commands

"set debug remote 1" and "set debug serial 1" may be useful, but be

warned: they produce a lot of output.

Threads

=======

Each process in a target machine is seen as a gdb thread. gdb thread related

commands (info threads, thread n) can be used. CONFIG_KGDB_THREAD must

be defined for this to work.

In this version, kgdb reports PID_MAX (32768) as the process ID for the

idle process (pid 0), since GDB does not accept 0 as an ID.

Detaching (exiting KGDB)

=========================

There are two ways to resume full-speed target execution: "continue" and

"detach". With "continue", GDB inserts any specified breakpoints in the

target code and resumes execution; the target is still in "gdb mode".

If a breakpoint or other debug event (e.g. NMI) happens, the target

halts and communicates with GDB again, which is waiting for it.

With "detach", GDB does *not* insert any breakpoints; target execution

is resumed and GDB stops communicating (does not wait for the target).

In this case, the target is no longer in "gdb mode" -- for example,

console messages no longer get sent separately to the KGDB port, or

encapsulated for GDB.  If a debug event (e.g. NMI) occurs, the target

will re-enter "gdb mode" and will display this fact on the console; you

must give a new "target remote" command to gdb.

NOTE: TO AVOID LOSSING CONSOLE MESSAGES IN CASE THE KERNEL CONSOLE AND

KGDB USING THE SAME PORT, THE TARGET WAITS FOR ANY INPUT CHARACTER ON

THE KGDB PORT AFTER A DETACH COMMAND.  For example, after the detach you

could start a terminal emulator on the same host port and enter a <cr>;

however, this program must then be terminated or suspended in order to

use GBD again if KGDB is re-entered.

Acknowledgements

================

This code was mostly generated by Henry Bell <henry.bell@st.com>;

largely from KGDB by Amit S. Kale <akale@veritas.com> - extracts from

code by Glenn Engel, Jim Kingdon, David Grothe <dave@gcom.com>, Tigran

Aivazian <tigran@sco.com>, William Gatliff <bgat@open-widgets.com>, Ben

Lee, Steve Chamberlain and Benoit Miller <fulg@iname.com> are also

included. 

Jeremy Siegel

<jsiegel@mvista.com>

	select HAVE_OPROFILE

	select HAVE_GENERIC_DMA_COHERENT

	select HAVE_IOREMAP_PROT if MMU

	select HAVE_ARCH_TRACEHOOK

	help

	  The SuperH is a RISC processor targeted for use in embedded systems

	  and consumer electronics; it was also used in the Sega Dreamcast

	def_bool !SUPERH64

	select HAVE_KPROBES

	select HAVE_KRETPROBES

	select HAVE_ARCH_TRACEHOOK

	select HAVE_FUNCTION_TRACER

	select HAVE_FTRACE_MCOUNT_RECORD

	select HAVE_DYNAMIC_FTRACE

	select HAVE_ARCH_KGDB

config SUPERH64

	def_bool y if CPU_SH5

config GENERIC_HARDIRQS_NO__DO_IRQ

	def_bool y

	depends on SUPERH32 && (!SH_DREAMCAST && !SH_SH4202_MICRODEV && \

				!SH_7751_SYSTEMH && !HD64461)

config GENERIC_IRQ_PROBE

	def_bool y

config SYS_SUPPORTS_PM

	bool

	depends on !SMP

config ARCH_SUSPEND_POSSIBLE

	def_bool n

config ARCH_HIBERNATION_POSSIBLE

	def_bool n

config SYS_SUPPORTS_APM_EMULATION

	bool

	select SYS_SUPPORTS_PM

	select ARCH_SUSPEND_POSSIBLE

config SYS_SUPPORTS_SMP

	bool

# SH-2A Processor Support

config CPU_SUBTYPE_SH7201

	bool "Support SH7201 processor"

	select CPU_SH2A

	select CPU_HAS_FPU

config CPU_SUBTYPE_SH7203

	bool "Support SH7203 processor"

	select CPU_SH2A

	depends on CPU_FREQ

	select CPU_FREQ_TABLE

	help

	  This adds the cpufreq driver for SuperH. At present, only

	  the SH-4 is supported.

	  This adds the cpufreq driver for SuperH. Any CPU that supports

	  clock rate rounding through the clock framework can use this

	  driver. While it will make the kernel slightly larger, this is

	  harmless for CPUs that don't support rate rounding. The driver

	  will also generate a notice in the boot log before disabling

	  itself if the CPU in question is not capable of rate rounding.

	  For details, take a look at <file:Documentation/cpu-freq>.

endmenu

config ISA_DMA_API

	bool

menu "Kernel features"

source kernel/Kconfig.hz

         Dreamcast with a serial line terminal or a remote network

         connection.

config CF_ENABLER

	bool "Compact Flash Enabler support"

	depends on SOLUTION_ENGINE || SH_SH03

	---help---

	  Compact Flash is a small, removable mass storage device introduced

	  in 1994 originally as a PCMCIA device.  If you say `Y' here, you

	  compile in support for Compact Flash devices directly connected to

	  a SuperH processor.  A Compact Flash FAQ is available at

	  <http://www.compactflash.org/faqs/faq.htm>.

	  If your board has "Directly Connected" CompactFlash at area 5 or 6,

	  you may want to enable this option.  Then, you can use CF as

	  primary IDE drive (only tested for SanDisk).

	  If in doubt, select 'N'.

choice

	prompt "Compact Flash Connection Area"

	depends on CF_ENABLER

	default CF_AREA6

config CF_AREA5

	bool "Area5"

	help

	  If your board has "Directly Connected" CompactFlash, You should

	  select the area where your CF is connected to.

	  - "Area5" if CompactFlash is connected to Area 5 (0x14000000)

	  - "Area6" if it is connected to Area 6 (0x18000000)

	  "Area6" will work for most boards.

config CF_AREA6

	bool "Area6"

endchoice

config CF_BASE_ADDR

	hex

	depends on CF_ENABLER

	default "0xb8000000" if CF_AREA6

	default "0xb4000000" if CF_AREA5

source "arch/sh/drivers/pci/Kconfig"

source "drivers/pci/Kconfig"

endmenu

menu "Power management options (EXPERIMENTAL)"

depends on EXPERIMENTAL && SYS_SUPPORTS_PM

depends on EXPERIMENTAL

config ARCH_SUSPEND_POSSIBLE

	def_bool y

	depends on !SMP

source "kernel/power/Kconfig"

source kernel/power/Kconfig

source "drivers/cpuidle/Kconfig"

endmenu

	  for handling hard and soft interrupts.  This can help avoid

	  overflowing the process kernel stacks.

config SH_KGDB

	bool "Include KGDB kernel debugger"

	select FRAME_POINTER

	select DEBUG_INFO

	depends on CPU_SH3 || CPU_SH4

config DUMP_CODE

	bool "Show disassembly of nearby code in register dumps"

	depends on DEBUG_KERNEL && SUPERH32

	default y if DEBUG_BUGVERBOSE

	default n

	help

	  This prints out a code trace of the instructions leading up to

	  the faulting instruction as a debugging aid. As this does grow

	  the kernel in size a bit, most users will want to say N here.

	  Those looking for more verbose debugging output should say Y.

config SH_NO_BSS_INIT

	bool "Avoid zeroing BSS (to speed-up startup on suitable platforms)"

	depends on DEBUG_KERNEL

	default n

	help

	  Include in-kernel hooks for kgdb, the Linux kernel source level

	  debugger.  See <http://kgdb.sourceforge.net/> for more information.

	  Unless you are intending to debug the kernel, say N here.

	  If running in painfully slow environments, such as an RTL

	  simulation or from remote memory via SHdebug, where the memory

	  can already be gauranteed to ber zeroed on boot, say Y.

menu "KGDB configuration options"

	depends on SH_KGDB

	  For all other cases, say N. If this option seems perplexing, or

	  you aren't sure, say N.

config MORE_COMPILE_OPTIONS

	bool "Add any additional compile options"

	string "Additional compile arguments"

	depends on MORE_COMPILE_OPTIONS

config KGDB_NMI

	def_bool n

	prompt "Enter KGDB on NMI"

config SH_KGDB_CONSOLE

	def_bool n

	prompt "Console messages through GDB"

	depends on !SERIAL_SH_SCI_CONSOLE && SERIAL_SH_SCI=y

	select SERIAL_CORE_CONSOLE

config KGDB_SYSRQ

	def_bool y

	prompt "Allow SysRq 'G' to enter KGDB"

	depends on MAGIC_SYSRQ

comment "Serial port setup"

config KGDB_DEFPORT

	int "Port number (ttySCn)"

	default "1"

config KGDB_DEFBAUD

	int "Baud rate"

	default "115200"

choice

	prompt "Parity"

	depends on SH_KGDB

	default KGDB_DEFPARITY_N

config KGDB_DEFPARITY_N

	bool "None"

config KGDB_DEFPARITY_E

	bool "Even"

config KGDB_DEFPARITY_O

	bool "Odd"

endchoice

choice

	prompt "Data bits"

	depends on SH_KGDB

	default KGDB_DEFBITS_8

config KGDB_DEFBITS_8

	bool "8"

config KGDB_DEFBITS_7

	bool "7"

endchoice

endmenu

if SUPERH64

config SH64_PROC_ASIDS

	bool "Debug: report ASIDs through /proc/asids"

	depends on PROC_FS && MMU

config SH64_SR_WATCH

	bool "Debug: set SR.WATCH to enable hardware watchpoints and trace"

	depends on SUPERH64

config POOR_MANS_STRACE

	bool "Debug: enable rudimentary strace facility"

	depends on SUPERH64

	help

	  This option allows system calls to be traced to the console.  It also

	  aids in detecting kernel stack underflow.  It is useful for debugging

	  early-userland problems (e.g. init incurring fatal exceptions.)

config SH_ALPHANUMERIC

	bool "Enable debug outputs to on-board alphanumeric display"

	depends on SH_CAYMAN

config SH_NO_BSS_INIT

	bool "Avoid zeroing BSS (to speed-up startup on suitable platforms)"

endif

endmenu

	$(call cc-option,-mno-implicit-fp,-m4-nofpu)

cflags-$(CONFIG_CPU_SH4A)		+= $(call cc-option,-m4a,) \

					   $(call cc-option,-m4a-nofpu,)

cflags-$(CONFIG_CPU_SH4AL_DSP)		+= $(call cc-option,-m4al,)

cflags-$(CONFIG_CPU_SH5)		:= $(call cc-option,-m5-32media-nofpu,)

ifeq ($(cflags-y),)

# In the case where we are stuck with a compiler that has been uselessly

# restricted to a particular ISA, a favourite default of newer GCCs when

# extensive multilib targets are not provided, ensure we get the best fit

# regarding FP generation. This is necessary to avoid references to FP

# variants in libgcc where integer variants exist, which otherwise result

# in link errors. This is intentionally stupid (albeit many orders of

# magnitude less than GCC's default behaviour), as anything with a large

# number of multilib targets better have been built correctly for

# the target in mind.

# regarding FP generation. This is intentionally stupid (albeit many

# orders of magnitude less than GCC's default behaviour), as anything

# with a large number of multilib targets better have been built

# correctly for the target in mind.

#

cflags-y	+= $(shell $(CC) $(KBUILD_CFLAGS) -print-multi-lib | \

		     grep nofpu | sed q | sed -e 's/^/-/;s/;.*$$//')

endif

cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -mb

cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -ml

cflags-y	+= $(call cc-option,-mno-fdpic)

# At this point, anything goes.

isaflags-y	:= $(call as-option,-Wa$(comma)-isa=any,)

else

#

# -Wa,-isa= tuning implies -Wa,-dsp for the versions of binutils that

# support it, while -Wa,-dsp by itself limits the range of usable opcodes

isaflags-$(CONFIG_SH_DSP)		:= \

	$(call as-option,-Wa$(comma)-isa=$(isa-y),-Wa$(comma)-dsp)

endif

cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -mb

cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -ml

cflags-y	+= $(call cc-option,-mno-fdpic)

cflags-y	+= $(isaflags-y) -ffreestanding

cflags-$(CONFIG_MORE_COMPILE_OPTIONS)	+= \

# Give the various platforms the opportunity to set default image types

defaultimage-$(CONFIG_SUPERH32)			:= zImage

defaultimage-$(CONFIG_SH_SH7785LCR)		:= uImage

defaultimage-$(CONFIG_SH_RSK)			:= uImage

defaultimage-$(CONFIG_SH_7206_SOLUTION_ENGINE)	:= vmlinux

defaultimage-$(CONFIG_SH_7619_SOLUTION_ENGINE)	:= vmlinux

# Set some sensible Kbuild defaults

KBUILD_DEFCONFIG	:= shx3_defconfig

machdir-$(CONFIG_SH_TITAN)			+= mach-titan

machdir-$(CONFIG_SH_LBOX_RE2)			+= mach-lboxre2

machdir-$(CONFIG_SH_CAYMAN)			+= mach-cayman

machdir-$(CONFIG_SH_RSK)			+= mach-rsk

ifneq ($(machdir-y),)

core-y	+= $(addprefix arch/sh/boards/, \

KBUILD_CPPFLAGS		+= $(cflags-y)

KBUILD_AFLAGS		+= $(cflags-y)

LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)

libs-$(CONFIG_SUPERH32)		:= arch/sh/lib/	$(libs-y)

libs-$(CONFIG_SUPERH64)		:= arch/sh/lib64/ $(libs-y)

libs-y				+= $(LIBGCC)

PHONY += maketools FORCE