Linux Audio

Check our new training course

Loading...
Note: File does not exist in v6.13.7.
  1The PowerPC boot wrapper
  2------------------------
  3Copyright (C) Secret Lab Technologies Ltd.
  4
  5PowerPC image targets compresses and wraps the kernel image (vmlinux) with
  6a boot wrapper to make it usable by the system firmware.  There is no
  7standard PowerPC firmware interface, so the boot wrapper is designed to
  8be adaptable for each kind of image that needs to be built.
  9
 10The boot wrapper can be found in the arch/powerpc/boot/ directory.  The
 11Makefile in that directory has targets for all the available image types.
 12The different image types are used to support all of the various firmware
 13interfaces found on PowerPC platforms.  OpenFirmware is the most commonly
 14used firmware type on general purpose PowerPC systems from Apple, IBM and
 15others.  U-Boot is typically found on embedded PowerPC hardware, but there
 16are a handful of other firmware implementations which are also popular.  Each
 17firmware interface requires a different image format.
 18
 19The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
 20it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
 21image.  The details of the build system is discussed in the next section.
 22Currently, the following image format targets exist:
 23
 24   cuImage.%:		Backwards compatible uImage for older version of
 25			U-Boot (for versions that don't understand the device
 26			tree).  This image embeds a device tree blob inside
 27			the image.  The boot wrapper, kernel and device tree
 28			are all embedded inside the U-Boot uImage file format
 29			with boot wrapper code that extracts data from the old
 30			bd_info structure and loads the data into the device
 31			tree before jumping into the kernel.
 32			  Because of the series of #ifdefs found in the
 33			bd_info structure used in the old U-Boot interfaces,
 34			cuImages are platform specific.  Each specific
 35			U-Boot platform has a different platform init file
 36			which populates the embedded device tree with data
 37			from the platform specific bd_info file.  The platform
 38			specific cuImage platform init code can be found in
 39			arch/powerpc/boot/cuboot.*.c.  Selection of the correct
 40			cuImage init code for a specific board can be found in
 41			the wrapper structure.
 42   dtbImage.%:		Similar to zImage, except device tree blob is embedded
 43			inside the image instead of provided by firmware.  The
 44			output image file can be either an elf file or a flat
 45			binary depending on the platform.
 46			  dtbImages are used on systems which do not have an
 47			interface for passing a device tree directly.
 48			dtbImages are similar to simpleImages except that
 49			dtbImages have platform specific code for extracting
 50			data from the board firmware, but simpleImages do not
 51			talk to the firmware at all.
 52			  PlayStation 3 support uses dtbImage.  So do Embedded
 53			Planet boards using the PlanetCore firmware.  Board
 54			specific initialization code is typically found in a
 55			file named arch/powerpc/boot/<platform>.c; but this
 56			can be overridden by the wrapper script.
 57   simpleImage.%:	Firmware independent compressed image that does not
 58			depend on any particular firmware interface and embeds
 59			a device tree blob.  This image is a flat binary that
 60			can be loaded to any location in RAM and jumped to.
 61			Firmware cannot pass any configuration data to the
 62			kernel with this image type and it depends entirely on
 63			the embedded device tree for all information.
 64			  The simpleImage is useful for booting systems with
 65			an unknown firmware interface or for booting from
 66			a debugger when no firmware is present (such as on
 67			the Xilinx Virtex platform).  The only assumption that
 68			simpleImage makes is that RAM is correctly initialized
 69			and that the MMU is either off or has RAM mapped to
 70			base address 0.
 71			  simpleImage also supports inserting special platform
 72			specific initialization code to the start of the bootup
 73			sequence.  The virtex405 platform uses this feature to
 74			ensure that the cache is invalidated before caching
 75			is enabled.  Platform specific initialization code is
 76			added as part of the wrapper script and is keyed on
 77			the image target name.  For example, all
 78			simpleImage.virtex405-* targets will add the
 79			virtex405-head.S initialization code (This also means
 80			that the dts file for virtex405 targets should be
 81			named (virtex405-<board>.dts).  Search the wrapper
 82			script for 'virtex405' and see the file
 83			arch/powerpc/boot/virtex405-head.S for details.
 84   treeImage.%;		Image format for used with OpenBIOS firmware found
 85			on some ppc4xx hardware.  This image embeds a device
 86			tree blob inside the image.
 87   uImage:		Native image format used by U-Boot.  The uImage target
 88			does not add any boot code.  It just wraps a compressed
 89			vmlinux in the uImage data structure.  This image
 90			requires a version of U-Boot that is able to pass
 91			a device tree to the kernel at boot.  If using an older
 92			version of U-Boot, then you need to use a cuImage
 93			instead.
 94   zImage.%:		Image format which does not embed a device tree.
 95			Used by OpenFirmware and other firmware interfaces
 96			which are able to supply a device tree.  This image
 97			expects firmware to provide the device tree at boot.
 98			Typically, if you have general purpose PowerPC
 99			hardware then you want this image format.
100
101Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
102and cuImage) all generate the device tree blob from a file in the
103arch/powerpc/boot/dts/ directory.  The Makefile selects the correct device
104tree source based on the name of the target.  Therefore, if the kernel is
105built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
106build system will use arch/powerpc/boot/dts/walnut.dts to build
107treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
108the simpleImage.virtex405-ml403.
109
110Two special targets called 'zImage' and 'zImage.initrd' also exist.  These
111targets build all the default images as selected by the kernel configuration.
112Default images are selected by the boot wrapper Makefile
113(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable.  Look
114at the Makefile to see which default image targets are available.
115
116How it is built
117---------------
118arch/powerpc is designed to support multiplatform kernels, which means
119that a single vmlinux image can be booted on many different target boards.
120It also means that the boot wrapper must be able to wrap for many kinds of
121images on a single build.  The design decision was made to not use any
122conditional compilation code (#ifdef, etc) in the boot wrapper source code.
123All of the boot wrapper pieces are buildable at any time regardless of the
124kernel configuration.  Building all the wrapper bits on every kernel build
125also ensures that obscure parts of the wrapper are at the very least compile
126tested in a large variety of environments.
127
128The wrapper is adapted for different image types at link time by linking in
129just the wrapper bits that are appropriate for the image type.  The 'wrapper
130script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
131is responsible for selecting the correct wrapper bits for the image type.
132The arguments are well documented in the script's comment block, so they
133are not repeated here.  However, it is worth mentioning that the script
134uses the -p (platform) argument as the main method of deciding which wrapper
135bits to compile in.  Look for the large 'case "$platform" in' block in the
136middle of the script.  This is also the place where platform specific fixups
137can be selected by changing the link order.
138
139In particular, care should be taken when working with cuImages.  cuImage
140wrapper bits are very board specific and care should be taken to make sure
141the target you are trying to build is supported by the wrapper bits.