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