Documentation/powerpc/bootwrapper.rst

   1 ========================
   2 The PowerPC boot wrapper
   3 ========================
   4
   5 Copyright (C) Secret Lab Technologies Ltd.
   6
   7 PowerPC image targets compresses and wraps the kernel image (vmlinux) with
   8 a boot wrapper to make it usable by the system firmware.  There is no
   9 standard PowerPC firmware interface, so the boot wrapper is designed to
  10 be adaptable for each kind of image that needs to be built.
  11
  12 The boot wrapper can be found in the arch/powerpc/boot/ directory.  The
  13 Makefile in that directory has targets for all the available image types.
  14 The different image types are used to support all of the various firmware
  15 interfaces found on PowerPC platforms.  OpenFirmware is the most commonly
  16 used firmware type on general purpose PowerPC systems from Apple, IBM and
  17 others.  U-Boot is typically found on embedded PowerPC hardware, but there
  18 are a handful of other firmware implementations which are also popular.  Each
  19 firmware interface requires a different image format.
  20
  21 The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
  22 it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
  23 image.  The details of the build system is discussed in the next section.
  24 Currently, 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                         The simpleImage is useful for booting systems with
  74                         an unknown firmware interface or for booting from
  75                         a debugger when no firmware is present (such as on
  76                         the Xilinx Virtex platform).  The only assumption that
  77                         simpleImage makes is that RAM is correctly initialized
  78                         and that the MMU is either off or has RAM mapped to
  79                         base address 0.
  80
  81                         simpleImage also supports inserting special platform
  82                         specific initialization code to the start of the bootup
  83                         sequence.  The virtex405 platform uses this feature to
  84                         ensure that the cache is invalidated before caching
  85                         is enabled.  Platform specific initialization code is
  86                         added as part of the wrapper script and is keyed on
  87                         the image target name.  For example, all
  88                         simpleImage.virtex405-* targets will add the
  89                         virtex405-head.S initialization code (This also means
  90                         that the dts file for virtex405 targets should be
  91                         named (virtex405-<board>.dts).  Search the wrapper
  92                         script for 'virtex405' and see the file
  93                         arch/powerpc/boot/virtex405-head.S for details.
  94
  95    treeImage.%;         Image format for used with OpenBIOS firmware found
  96                         on some ppc4xx hardware.  This image embeds a device
  97                         tree blob inside the image.
  98
  99    uImage:              Native image format used by U-Boot.  The uImage target
 100                         does not add any boot code.  It just wraps a compressed
 101                         vmlinux in the uImage data structure.  This image
 102                         requires a version of U-Boot that is able to pass
 103                         a device tree to the kernel at boot.  If using an older
 104                         version of U-Boot, then you need to use a cuImage
 105                         instead.
 106
 107    zImage.%:            Image format which does not embed a device tree.
 108                         Used by OpenFirmware and other firmware interfaces
 109                         which are able to supply a device tree.  This image
 110                         expects firmware to provide the device tree at boot.
 111                         Typically, if you have general purpose PowerPC
 112                         hardware then you want this image format.
 113    ==================== ========================================================
 114
 115 Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
 116 and cuImage) all generate the device tree blob from a file in the
 117 arch/powerpc/boot/dts/ directory.  The Makefile selects the correct device
 118 tree source based on the name of the target.  Therefore, if the kernel is
 119 built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
 120 build system will use arch/powerpc/boot/dts/walnut.dts to build
 121 treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
 122 the simpleImage.virtex405-ml403.
 123
 124 Two special targets called 'zImage' and 'zImage.initrd' also exist.  These
 125 targets build all the default images as selected by the kernel configuration.
 126 Default images are selected by the boot wrapper Makefile
 127 (arch/powerpc/boot/Makefile) by adding targets to the $image-y variable.  Look
 128 at the Makefile to see which default image targets are available.
 129
 130 How it is built
 131 ---------------
 132 arch/powerpc is designed to support multiplatform kernels, which means
 133 that a single vmlinux image can be booted on many different target boards.
 134 It also means that the boot wrapper must be able to wrap for many kinds of
 135 images on a single build.  The design decision was made to not use any
 136 conditional compilation code (#ifdef, etc) in the boot wrapper source code.
 137 All of the boot wrapper pieces are buildable at any time regardless of the
 138 kernel configuration.  Building all the wrapper bits on every kernel build
 139 also ensures that obscure parts of the wrapper are at the very least compile
 140 tested in a large variety of environments.
 141
 142 The wrapper is adapted for different image types at link time by linking in
 143 just the wrapper bits that are appropriate for the image type.  The 'wrapper
 144 script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
 145 is responsible for selecting the correct wrapper bits for the image type.
 146 The arguments are well documented in the script's comment block, so they
 147 are not repeated here.  However, it is worth mentioning that the script
 148 uses the -p (platform) argument as the main method of deciding which wrapper
 149 bits to compile in.  Look for the large 'case "$platform" in' block in the
 150 middle of the script.  This is also the place where platform specific fixups
 151 can be selected by changing the link order.
 152
 153 In particular, care should be taken when working with cuImages.  cuImage
 154 wrapper bits are very board specific and care should be taken to make sure
 155 the target you are trying to build is supported by the wrapper bits.