powerpc/bootwrapper: Add documentation of boot wrapper targets

There have been many questions on and off the mailing list about how exactly the bootwrapper is used for embedded targets. Add some documentation and help text to try and clarify the system. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

powerpc/bootwrapper: Add documentation of boot wrapper targets
There have been many questions on and off the mailing list about how exactly the bootwrapper is used for embedded targets. Add some documentation and help text to try and clarify the system. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Grant Likely
1 parent 94ec359e45
Showing 2 changed files with 155 additions and 1 deletions Side-by-side Diff
Documentation/powerpc/bootwrapper.txt
arch/powerpc/Makefile
+The PowerPC boot wrapper
+------------------------
+Copyright (C) Secret Lab Technologies Ltd.
+
+PowerPC image targets compresses and wraps the kernel image (vmlinux) with
+a boot wrapper to make it usable by the system firmware.  There is no
+standard PowerPC firmware interface, so the boot wrapper is designed to
+be adaptable for each kind of image that needs to be built.
+
+The boot wrapper can be found in the arch/powerpc/boot/ directory.  The
+Makefile in that directory has targets for all the available image types.
+The different image types are used to support all of the various firmware
+interfaces found on PowerPC platforms.  OpenFirmware is the most commonly
+used firmware type on general purpose PowerPC systems from Apple, IBM and
+others.  U-Boot is typically found on embedded PowerPC hardware, but there
+are a handful of other firmware implementations which are also popular.  Each
+firmware interface requires a different image format.
+
+The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
+it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
+image.  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 of
+			U-Boot (for versions that don't understand the device
+			tree).  This image embeds a device tree blob inside
+			the image.  The boot wrapper, kernel and device tree
+			are all embedded inside the U-Boot uImage file format
+			with boot wrapper code that extracts data from the old
+			bd_info structure and loads the data into the device
+			tree before jumping into the kernel.
+			  Because of the series of #ifdefs found in the
+			bd_info structure used in the old U-Boot interfaces,
+			cuImages are platform specific.  Each specific
+			U-Boot platform has a different platform init file
+			which populates the embedded device tree with data
+			from the platform specific bd_info file.  The platform
+			specific cuImage platform init code can be found in
+			arch/powerpc/boot/cuboot.*.c.  Selection of the correct
+			cuImage init code for a specific board can be found in
+			the wrapper structure.
+   dtbImage.%:		Similar to zImage, except device tree blob is embedded
+			inside the image instead of provided by firmware.  The
+			output image file can be either an elf file or a flat
+			binary depending on the platform.
+			  dtbImages are used on systems which do not have an
+			interface for passing a device tree directly.
+			dtbImages are similar to simpleImages except that
+			dtbImages have platform specific code for extracting
+			data from the board firmware, but simpleImages do not
+			talk to the firmware at all.
+			  PlayStation 3 support uses dtbImage.  So do Embedded
+			Planet boards using the PlanetCore firmware.  Board
+			specific initialization code is typically found in a
+			file named arch/powerpc/boot/<platform>.c; but this
+			can be overridden by the wrapper script.
+   simpleImage.%:	Firmware independent compressed image that does not
+			depend on any particular firmware interface and embeds
+			a device tree blob.  This image is a flat binary that
+			can be loaded to any location in RAM and jumped to.
+			Firmware cannot pass any configuration data to the
+			kernel with this image type and it depends entirely on
+			the embedded device tree for all information.
+			  The simpleImage is useful for booting systems with
+			an unknown firmware interface or for booting from
+			a debugger when no firmware is present (such as on
+			the Xilinx Virtex platform).  The only assumption that
+			simpleImage makes is that RAM is correctly initialized
+			and that the MMU is either off or has RAM mapped to
+			base address 0.
+			  simpleImage also supports inserting special platform
+			specific initialization code to the start of the bootup
+			sequence.  The virtex405 platform uses this feature to
+			ensure that the cache is invalidated before caching
+			is enabled.  Platform specific initialization code is
+			added as part of the wrapper script and is keyed on
+			the image target name.  For example, all
+			simpleImage.virtex405-* targets will add the
+			virtex405-head.S initialization code (This also means
+			that the dts file for virtex405 targets should be
+			named (virtex405-<board>.dts).  Search the wrapper
+			script for 'virtex405' and see the file
+			arch/powerpc/boot/virtex405-head.S for details.
+   treeImage.%;		Image format for used with OpenBIOS firmware found
+			on some ppc4xx hardware.  This image embeds a device
+			tree blob inside the image.
+   uImage:		Native image format used by U-Boot.  The uImage target
+			does not add any boot code.  It just wraps a compressed
+			vmlinux in the uImage data structure.  This image
+			requires a version of U-Boot that is able to pass
+			a device tree to the kernel at boot.  If using an older
+			version of U-Boot, then you need to use a cuImage
+			instead.
+   zImage.%:		Image format which does not embed a device tree.
+			Used by OpenFirmware and other firmware interfaces
+			which are able to supply a device tree.  This image
+			expects firmware to provide the device tree at boot.
+			Typically, if you have general purpose PowerPC
+			hardware 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 the
+arch/powerpc/boot/dts/ directory.  The Makefile selects the correct device
+tree source based on the name of the target.  Therefore, if the kernel is
+built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
+build system will use arch/powerpc/boot/dts/walnut.dts to build
+treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
+the simpleImage.virtex405-ml403.
+
+Two special targets called 'zImage' and 'zImage.initrd' also exist.  These
+targets 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.  Look
+at the Makefile to see which default image targets are available.
+
+How it is built
+---------------
+arch/powerpc is designed to support multiplatform kernels, which means
+that 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 of
+images on a single build.  The design decision was made to not use any
+conditional compilation code (#ifdef, etc) in the boot wrapper source code.
+All of the boot wrapper pieces are buildable at any time regardless of the
+kernel configuration.  Building all the wrapper bits on every kernel build
+also ensures that obscure parts of the wrapper are at the very least compile
+tested in a large variety of environments.
+
+The wrapper is adapted for different image types at link time by linking in
+just the wrapper bits that are appropriate for the image type.  The 'wrapper
+script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
+is responsible for selecting the correct wrapper bits for the image type.
+The arguments are well documented in the script's comment block, so they
+are not repeated here.  However, it is worth mentioning that the script
+uses the -p (platform) argument as the main method of deciding which wrapper
+bits to compile in.  Look for the large 'case "$platform" in' block in the
+middle of the script.  This is also the place where platform specific fixups
+can be selected by changing the link order.
+
+In particular, care should be taken when working with cuImages.  cuImage
+wrapper bits are very board specific and care should be taken to make sure
+the target you are trying to build is supported by the wrapper bits.
@@ -163,12 +163,25 @@
 	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
  
 define archhelp
-  @echo '* zImage          - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
+  @echo '* zImage          - Build default images selected by kernel config'
+  @echo '  zImage.*        - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
+  @echo '  uImage          - U-Boot native image format'
+  @echo '  cuImage.<dt>    - Backwards compatible U-Boot image for older'
+  @echo '                    versions which do not support device trees'
+  @echo '  dtbImage.<dt>   - zImage with an embedded device tree blob'
+  @echo '  simpleImage.<dt> - Firmware independent image.'
+  @echo '  treeImage.<dt>  - Support for older IBM 4xx firmware (not U-Boot)'
   @echo '  install         - Install kernel using'
   @echo '                    (your) ~/bin/installkernel or'
   @echo '                    (distribution) /sbin/installkernel or'
   @echo '                    install to $$(INSTALL_PATH) and run lilo'
   @echo '  *_defconfig     - Select default config from arch/$(ARCH)/configs'
+  @echo ''
+  @echo '  Targets with <dt> embed a device tree blob inside the image'
+  @echo '  These targets support board with firmware that does not'
+  @echo '  support passing a device tree directly.  Replace <dt> with the'
+  @echo '  name of a dts file from the arch/$(ARCH)/boot/dts/ directory'
+  @echo '  (minus the .dts extension).'
 endef
  
 install:
	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.
...	...	@@ -163,12 +163,25 @@
163	163	$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
164	164
165	165	define archhelp
166		- @echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
	166	+ @echo '* zImage - Build default images selected by kernel config'
	167	+ @echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
	168	+ @echo ' uImage - U-Boot native image format'
	169	+ @echo ' cuImage.<dt> - Backwards compatible U-Boot image for older'
	170	+ @echo ' versions which do not support device trees'
	171	+ @echo ' dtbImage.<dt> - zImage with an embedded device tree blob'
	172	+ @echo ' simpleImage.<dt> - Firmware independent image.'
	173	+ @echo ' treeImage.<dt> - Support for older IBM 4xx firmware (not U-Boot)'
167	174	@echo ' install - Install kernel using'
168	175	@echo ' (your) ~/bin/installkernel or'
169	176	@echo ' (distribution) /sbin/installkernel or'
170	177	@echo ' install to $$(INSTALL_PATH) and run lilo'
171	178	@echo ' *_defconfig - Select default config from arch/$(ARCH)/configs'
	179	+ @echo ''
	180	+ @echo ' Targets with <dt> embed a device tree blob inside the image'
	181	+ @echo ' These targets support board with firmware that does not'
	182	+ @echo ' support passing a device tree directly. Replace <dt> with the'
	183	+ @echo ' name of a dts file from the arch/$(ARCH)/boot/dts/ directory'
	184	+ @echo ' (minus the .dts extension).'
172	185	endef
173	186
174	187	install: