| xj | b04a402 | 2021-11-25 15:01:52 +0800 | [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. |