| Grant Likely | 70bf033 | 2008-06-25 13:14:36 -0700 | [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. |