Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc

- ia64 (Does not support probes on instruction slot1.)

- sparc64 (Return probes not yet implemented.)

- arm

- ppc

3. Configuring Kprobes

The PowerPC boot wrapper

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

Copyright (C) Secret Lab Technologies Ltd.

PowerPC image targets compresses and wraps the kernel image (vmlinux) with

a boot wrapper to make it usable by the system firmware.  There is no

standard PowerPC firmware interface, so the boot wrapper is designed to

be adaptable for each kind of image that needs to be built.

The boot wrapper can be found in the arch/powerpc/boot/ directory.  The

Makefile in that directory has targets for all the available image types.

The different image types are used to support all of the various firmware

interfaces found on PowerPC platforms.  OpenFirmware is the most commonly

used firmware type on general purpose PowerPC systems from Apple, IBM and

others.  U-Boot is typically found on embedded PowerPC hardware, but there

are a handful of other firmware implementations which are also popular.  Each

firmware interface requires a different image format.

The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and

it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target

image.  The details of the build system is discussed in the next section.

Currently, the following image format targets exist:

   cuImage.%:		Backwards compatible uImage for older version of

			U-Boot (for versions that don't understand the device

			tree).  This image embeds a device tree blob inside

			the image.  The boot wrapper, kernel and device tree

			are all embedded inside the U-Boot uImage file format

			with boot wrapper code that extracts data from the old

			bd_info structure and loads the data into the device

			tree before jumping into the kernel.

			  Because of the series of #ifdefs found in the

			bd_info structure used in the old U-Boot interfaces,

			cuImages are platform specific.  Each specific

			U-Boot platform has a different platform init file

			which populates the embedded device tree with data

			from the platform specific bd_info file.  The platform

			specific cuImage platform init code can be found in

			arch/powerpc/boot/cuboot.*.c.  Selection of the correct

			cuImage init code for a specific board can be found in

			the wrapper structure.

   dtbImage.%:		Similar to zImage, except device tree blob is embedded

			inside the image instead of provided by firmware.  The

			output image file can be either an elf file or a flat

			binary depending on the platform.

			  dtbImages are used on systems which do not have an

			interface for passing a device tree directly.

			dtbImages are similar to simpleImages except that

			dtbImages have platform specific code for extracting

			data from the board firmware, but simpleImages do not

			talk to the firmware at all.

			  PlayStation 3 support uses dtbImage.  So do Embedded

			Planet boards using the PlanetCore firmware.  Board

			specific initialization code is typically found in a

			file named arch/powerpc/boot/<platform>.c; but this

			can be overridden by the wrapper script.

   simpleImage.%:	Firmware independent compressed image that does not

			depend on any particular firmware interface and embeds

			a device tree blob.  This image is a flat binary that

			can be loaded to any location in RAM and jumped to.

			Firmware cannot pass any configuration data to the

			kernel with this image type and it depends entirely on

			the embedded device tree for all information.

			  The simpleImage is useful for booting systems with

			an unknown firmware interface or for booting from

			a debugger when no firmware is present (such as on

			the Xilinx Virtex platform).  The only assumption that

			simpleImage makes is that RAM is correctly initialized

			and that the MMU is either off or has RAM mapped to

			base address 0.

			  simpleImage also supports inserting special platform

			specific initialization code to the start of the bootup

			sequence.  The virtex405 platform uses this feature to

			ensure that the cache is invalidated before caching

			is enabled.  Platform specific initialization code is

			added as part of the wrapper script and is keyed on

			the image target name.  For example, all

			simpleImage.virtex405-* targets will add the

			virtex405-head.S initialization code (This also means

			that the dts file for virtex405 targets should be

			named (virtex405-<board>.dts).  Search the wrapper

			script for 'virtex405' and see the file

			arch/powerpc/boot/virtex405-head.S for details.

   treeImage.%;		Image format for used with OpenBIOS firmware found

			on some ppc4xx hardware.  This image embeds a device

			tree blob inside the image.

   uImage:		Native image format used by U-Boot.  The uImage target

			does not add any boot code.  It just wraps a compressed

			vmlinux in the uImage data structure.  This image

			requires a version of U-Boot that is able to pass

			a device tree to the kernel at boot.  If using an older

			version of U-Boot, then you need to use a cuImage

			instead.

   zImage.%:		Image format which does not embed a device tree.

			Used by OpenFirmware and other firmware interfaces

			which are able to supply a device tree.  This image

			expects firmware to provide the device tree at boot.

			Typically, if you have general purpose PowerPC

			hardware then you want this image format.

Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,

and cuImage) all generate the device tree blob from a file in the

arch/powerpc/boot/dts/ directory.  The Makefile selects the correct device

tree source based on the name of the target.  Therefore, if the kernel is

built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the

build system will use arch/powerpc/boot/dts/walnut.dts to build

treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build

the simpleImage.virtex405-ml403.

Two special targets called 'zImage' and 'zImage.initrd' also exist.  These

targets build all the default images as selected by the kernel configuration.

Default images are selected by the boot wrapper Makefile

(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable.  Look

at the Makefile to see which default image targets are available.

How it is built

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

arch/powerpc is designed to support multiplatform kernels, which means

that a single vmlinux image can be booted on many different target boards.

It also means that the boot wrapper must be able to wrap for many kinds of

images on a single build.  The design decision was made to not use any

conditional compilation code (#ifdef, etc) in the boot wrapper source code.

All of the boot wrapper pieces are buildable at any time regardless of the

kernel configuration.  Building all the wrapper bits on every kernel build

also ensures that obscure parts of the wrapper are at the very least compile

tested in a large variety of environments.

The wrapper is adapted for different image types at link time by linking in

just the wrapper bits that are appropriate for the image type.  The 'wrapper

script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and

is responsible for selecting the correct wrapper bits for the image type.

The arguments are well documented in the script's comment block, so they

are not repeated here.  However, it is worth mentioning that the script

uses the -p (platform) argument as the main method of deciding which wrapper

bits to compile in.  Look for the large 'case "$platform" in' block in the

middle of the script.  This is also the place where platform specific fixups

can be selected by changing the link order.

In particular, care should be taken when working with cuImages.  cuImage

wrapper bits are very board specific and care should be taken to make sure

the target you are trying to build is supported by the wrapper bits.

* Board Control and Status (BCSR)

Required properties:

 - device_type : Should be "board-control"

 - reg : Offset and length of the register set for the device

Example:

	bcsr@f8000000 {

		device_type = "board-control";

		reg = <f8000000 8000>;

	};

* Freescale on board FPGA

This is the memory-mapped registers for on board FPGA.

Required properities:

- compatible : should be "fsl,fpga-pixis".

- reg : should contain the address and the lenght of the FPPGA register

  set.

Example (MPC8610HPCD):

	board-control@e8000000 {

		compatible = "fsl,fpga-pixis";

		reg = <0xe8000000 32>;

	};

* Freescale Communications Processor Module

NOTE: This is an interim binding, and will likely change slightly,

as more devices are supported.  The QE bindings especially are

incomplete.

* Root CPM node

Properties:

- compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".

- reg : A 48-byte region beginning with CPCR.

Example:

     cpm@119c0 {

	#address-cells = <1>;

	#size-cells = <1>;

	#interrupt-cells = <2>;

	compatible = "fsl,mpc8272-cpm", "fsl,cpm2";

	reg = <119c0 30>;

     }

* Properties common to mulitple CPM/QE devices

- fsl,cpm-command : This value is ORed with the opcode and command flag

                    to specify the device on which a CPM command operates.

- fsl,cpm-brg : Indicates which baud rate generator the device

                is associated with.  If absent, an unused BRG

                should be dynamically allocated.  If zero, the

                device uses an external clock rather than a BRG.

- reg : Unless otherwise specified, the first resource represents the

        scc/fcc/ucc registers, and the second represents the device's

        parameter RAM region (if it has one).

* Multi-User RAM (MURAM)

The multi-user/dual-ported RAM is expressed as a bus under the CPM node.

Ranges must be set up subject to the following restrictions:

- Children's reg nodes must be offsets from the start of all muram, even

  if the user-data area does not begin at zero.

- If multiple range entries are used, the difference between the parent

  address and the child address must be the same in all, so that a single

  mapping can cover them all while maintaining the ability to determine

  CPM-side offsets with pointer subtraction.  It is recommended that

  multiple range entries not be used.

- A child address of zero must be translatable, even if no reg resources

  contain it.

A child "data" node must exist, compatible with "fsl,cpm-muram-data", to

indicate the portion of muram that is usable by the OS for arbitrary

purposes.  The data node may have an arbitrary number of reg resources,

all of which contribute to the allocatable muram pool.

Example, based on mpc8272:

	muram@0 {

		#address-cells = <1>;

		#size-cells = <1>;

		ranges = <0 0 10000>;

		data@0 {

			compatible = "fsl,cpm-muram-data";

			reg = <0 2000 9800 800>;

		};

	};