The PowerPC boot wrapper

Copyright (C) Secret Lab Technologies Ltd.

PowerPC image targets compresses and wraps the kernel image (vmlinux) witha boot wrapper to make it usable by the system firmware. There is nostandard PowerPC firmware interface, so the boot wrapper is designed tobe adaptable for each kind of image that needs to be built.

The boot wrapper can be found in the arch/powerpc/boot/ directory. TheMakefile in that directory has targets for all the available image types.The different image types are used to support all of the various firmwareinterfaces found on PowerPC platforms. OpenFirmware is the most commonlyused firmware type on general purpose PowerPC systems from Apple, IBM andothers. U-Boot is typically found on embedded PowerPC hardware, but thereare a handful of other firmware implementations which are also popular. Eachfirmware interface requires a different image format.

The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile andit uses the wrapper script (arch/powerpc/boot/wrapper) to generate targetimage. The details of the build system is discussed in the next section.Currently, the following image format targets exist:

cuImage.%:

Backwards compatible uImage for older version ofU-Boot (for versions that don’t understand the devicetree). This image embeds a device tree blob insidethe image. The boot wrapper, kernel and device treeare all embedded inside the U-Boot uImage file formatwith boot wrapper code that extracts data from the oldbd_info structure and loads the data into the devicetree before jumping into the kernel.

Because of the series of #ifdefs found in thebd_info structure used in the old U-Boot interfaces,cuImages are platform specific. Each specificU-Boot platform has a different platform init filewhich populates the embedded device tree with datafrom the platform specific bd_info file. The platformspecific cuImage platform init code can be found inarch/powerpc/boot/cuboot.*.c. Selection of the correctcuImage init code for a specific board can be found inthe wrapper structure.

dtbImage.%:

Similar to zImage, except device tree blob is embeddedinside the image instead of provided by firmware. Theoutput image file can be either an elf file or a flatbinary depending on the platform.

dtbImages are used on systems which do not have aninterface for passing a device tree directly.dtbImages are similar to simpleImages except thatdtbImages have platform specific code for extractingdata from the board firmware, but simpleImages do nottalk to the firmware at all.

PlayStation 3 support uses dtbImage. So do EmbeddedPlanet boards using the PlanetCore firmware. Boardspecific initialization code is typically found in afile named arch/powerpc/boot/<platform>.c; but thiscan be overridden by the wrapper script.

simpleImage.%:

Firmware independent compressed image that does notdepend on any particular firmware interface and embedsa device tree blob. This image is a flat binary thatcan be loaded to any location in RAM and jumped to.Firmware cannot pass any configuration data to thekernel with this image type and it depends entirely onthe embedded device tree for all information.

treeImage.%;

Image format for used with OpenBIOS firmware foundon some ppc4xx hardware. This image embeds a devicetree blob inside the image.

uImage:

Native image format used by U-Boot. The uImage targetdoes not add any boot code. It just wraps a compressedvmlinux in the uImage data structure. This imagerequires a version of U-Boot that is able to passa device tree to the kernel at boot. If using an olderversion of U-Boot, then you need to use a cuImageinstead.

zImage.%:

Image format which does not embed a device tree.Used by OpenFirmware and other firmware interfaceswhich are able to supply a device tree. This imageexpects firmware to provide the device tree at boot.Typically, if you have general purpose PowerPChardware then you want this image format.

Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,and cuImage) all generate the device tree blob from a file in thearch/powerpc/boot/dts/ directory. The Makefile selects the correct devicetree source based on the name of the target. Therefore, if the kernel isbuilt with ‘make treeImage.walnut’, then the build system will usearch/powerpc/boot/dts/walnut.dts to build treeImage.walnut.

Two special targets called ‘zImage’ and ‘zImage.initrd’ also exist. Thesetargets build all the default images as selected by the kernel configuration.Default images are selected by the boot wrapper Makefile(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Lookat the Makefile to see which default image targets are available.

How it is built

arch/powerpc is designed to support multiplatform kernels, which meansthat a single vmlinux image can be booted on many different target boards.It also means that the boot wrapper must be able to wrap for many kinds ofimages on a single build. The design decision was made to not use anyconditional compilation code (#ifdef, etc) in the boot wrapper source code.All of the boot wrapper pieces are buildable at any time regardless of thekernel configuration. Building all the wrapper bits on every kernel buildalso ensures that obscure parts of the wrapper are at the very least compiletested in a large variety of environments.

The wrapper is adapted for different image types at link time by linking injust the wrapper bits that are appropriate for the image type. The ‘wrapperscript’ (found in arch/powerpc/boot/wrapper) is called by the Makefile andis responsible for selecting the correct wrapper bits for the image type.The arguments are well documented in the script’s comment block, so theyare not repeated here. However, it is worth mentioning that the scriptuses the -p (platform) argument as the main method of deciding which wrapperbits to compile in. Look for the large ‘case “$platform” in’ block in themiddle of the script. This is also the place where platform specific fixupscan be selected by changing the link order.

In particular, care should be taken when working with cuImages. cuImagewrapper bits are very board specific and care should be taken to make surethe target you are trying to build is supported by the wrapper bits.