Kyle Swenson | 8d8f654 | 2021-03-15 11:02:55 -0600 | [diff] [blame] | 1 | The PowerPC boot wrapper |
| 2 | ------------------------ |
| 3 | Copyright (C) Secret Lab Technologies Ltd. |
| 4 | |
| 5 | PowerPC image targets compresses and wraps the kernel image (vmlinux) with |
| 6 | a boot wrapper to make it usable by the system firmware. There is no |
| 7 | standard PowerPC firmware interface, so the boot wrapper is designed to |
| 8 | be adaptable for each kind of image that needs to be built. |
| 9 | |
| 10 | The boot wrapper can be found in the arch/powerpc/boot/ directory. The |
| 11 | Makefile in that directory has targets for all the available image types. |
| 12 | The different image types are used to support all of the various firmware |
| 13 | interfaces found on PowerPC platforms. OpenFirmware is the most commonly |
| 14 | used firmware type on general purpose PowerPC systems from Apple, IBM and |
| 15 | others. U-Boot is typically found on embedded PowerPC hardware, but there |
| 16 | are a handful of other firmware implementations which are also popular. Each |
| 17 | firmware interface requires a different image format. |
| 18 | |
| 19 | The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and |
| 20 | it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target |
| 21 | image. The details of the build system is discussed in the next section. |
| 22 | Currently, 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 | |
| 101 | Image types which embed a device tree blob (simpleImage, dtbImage, treeImage, |
| 102 | and cuImage) all generate the device tree blob from a file in the |
| 103 | arch/powerpc/boot/dts/ directory. The Makefile selects the correct device |
| 104 | tree source based on the name of the target. Therefore, if the kernel is |
| 105 | built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the |
| 106 | build system will use arch/powerpc/boot/dts/walnut.dts to build |
| 107 | treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build |
| 108 | the simpleImage.virtex405-ml403. |
| 109 | |
| 110 | Two special targets called 'zImage' and 'zImage.initrd' also exist. These |
| 111 | targets build all the default images as selected by the kernel configuration. |
| 112 | Default images are selected by the boot wrapper Makefile |
| 113 | (arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look |
| 114 | at the Makefile to see which default image targets are available. |
| 115 | |
| 116 | How it is built |
| 117 | --------------- |
| 118 | arch/powerpc is designed to support multiplatform kernels, which means |
| 119 | that a single vmlinux image can be booted on many different target boards. |
| 120 | It also means that the boot wrapper must be able to wrap for many kinds of |
| 121 | images on a single build. The design decision was made to not use any |
| 122 | conditional compilation code (#ifdef, etc) in the boot wrapper source code. |
| 123 | All of the boot wrapper pieces are buildable at any time regardless of the |
| 124 | kernel configuration. Building all the wrapper bits on every kernel build |
| 125 | also ensures that obscure parts of the wrapper are at the very least compile |
| 126 | tested in a large variety of environments. |
| 127 | |
| 128 | The wrapper is adapted for different image types at link time by linking in |
| 129 | just the wrapper bits that are appropriate for the image type. The 'wrapper |
| 130 | script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and |
| 131 | is responsible for selecting the correct wrapper bits for the image type. |
| 132 | The arguments are well documented in the script's comment block, so they |
| 133 | are not repeated here. However, it is worth mentioning that the script |
| 134 | uses the -p (platform) argument as the main method of deciding which wrapper |
| 135 | bits to compile in. Look for the large 'case "$platform" in' block in the |
| 136 | middle of the script. This is also the place where platform specific fixups |
| 137 | can be selected by changing the link order. |
| 138 | |
| 139 | In particular, care should be taken when working with cuImages. cuImage |
| 140 | wrapper bits are very board specific and care should be taken to make sure |
| 141 | the target you are trying to build is supported by the wrapper bits. |