About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / powerpc / bootwrapper.txt




Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:04 EST.

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.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.