bootwrapper.txt 7.6 KB

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