]> git.proxmox.com Git - mirror_ubuntu-hirsute-kernel.git/blame - Documentation/powerpc/bootwrapper.rst
Merge tag 'nfs-for-5.7-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
[mirror_ubuntu-hirsute-kernel.git] / Documentation / powerpc / bootwrapper.rst
CommitLineData
4d2e26a3 1========================
70bf0333 2The PowerPC boot wrapper
4d2e26a3
MCC
3========================
4
70bf0333
GL
5Copyright (C) Secret Lab Technologies Ltd.
6
7PowerPC image targets compresses and wraps the kernel image (vmlinux) with
8a boot wrapper to make it usable by the system firmware. There is no
9standard PowerPC firmware interface, so the boot wrapper is designed to
10be adaptable for each kind of image that needs to be built.
11
12The boot wrapper can be found in the arch/powerpc/boot/ directory. The
13Makefile in that directory has targets for all the available image types.
14The different image types are used to support all of the various firmware
15interfaces found on PowerPC platforms. OpenFirmware is the most commonly
16used firmware type on general purpose PowerPC systems from Apple, IBM and
17others. U-Boot is typically found on embedded PowerPC hardware, but there
18are a handful of other firmware implementations which are also popular. Each
19firmware interface requires a different image format.
20
21The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
22it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
23image. The details of the build system is discussed in the next section.
24Currently, the following image format targets exist:
25
4d2e26a3 26 ==================== ========================================================
70bf0333
GL
27 cuImage.%: Backwards compatible uImage for older version of
28 U-Boot (for versions that don't understand the device
29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
31 are all embedded inside the U-Boot uImage file format
32 with boot wrapper code that extracts data from the old
33 bd_info structure and loads the data into the device
34 tree before jumping into the kernel.
4d2e26a3
MCC
35
36 Because of the series of #ifdefs found in the
70bf0333
GL
37 bd_info structure used in the old U-Boot interfaces,
38 cuImages are platform specific. Each specific
39 U-Boot platform has a different platform init file
40 which populates the embedded device tree with data
41 from the platform specific bd_info file. The platform
42 specific cuImage platform init code can be found in
4d2e26a3 43 `arch/powerpc/boot/cuboot.*.c`. Selection of the correct
70bf0333
GL
44 cuImage init code for a specific board can be found in
45 the wrapper structure.
4d2e26a3 46
70bf0333
GL
47 dtbImage.%: Similar to zImage, except device tree blob is embedded
48 inside the image instead of provided by firmware. The
49 output image file can be either an elf file or a flat
50 binary depending on the platform.
4d2e26a3
MCC
51
52 dtbImages are used on systems which do not have an
70bf0333
GL
53 interface for passing a device tree directly.
54 dtbImages are similar to simpleImages except that
55 dtbImages have platform specific code for extracting
56 data from the board firmware, but simpleImages do not
57 talk to the firmware at all.
4d2e26a3
MCC
58
59 PlayStation 3 support uses dtbImage. So do Embedded
70bf0333
GL
60 Planet boards using the PlanetCore firmware. Board
61 specific initialization code is typically found in a
62 file named arch/powerpc/boot/<platform>.c; but this
63 can be overridden by the wrapper script.
4d2e26a3 64
70bf0333
GL
65 simpleImage.%: Firmware independent compressed image that does not
66 depend on any particular firmware interface and embeds
67 a device tree blob. This image is a flat binary that
68 can be loaded to any location in RAM and jumped to.
69 Firmware cannot pass any configuration data to the
70 kernel with this image type and it depends entirely on
71 the embedded device tree for all information.
4d2e26a3
MCC
72
73 The simpleImage is useful for booting systems with
70bf0333
GL
74 an unknown firmware interface or for booting from
75 a debugger when no firmware is present (such as on
76 the Xilinx Virtex platform). The only assumption that
77 simpleImage makes is that RAM is correctly initialized
78 and that the MMU is either off or has RAM mapped to
79 base address 0.
4d2e26a3
MCC
80
81 simpleImage also supports inserting special platform
70bf0333
GL
82 specific initialization code to the start of the bootup
83 sequence. The virtex405 platform uses this feature to
84 ensure that the cache is invalidated before caching
85 is enabled. Platform specific initialization code is
86 added as part of the wrapper script and is keyed on
87 the image target name. For example, all
88 simpleImage.virtex405-* targets will add the
89 virtex405-head.S initialization code (This also means
90 that the dts file for virtex405 targets should be
91 named (virtex405-<board>.dts). Search the wrapper
92 script for 'virtex405' and see the file
93 arch/powerpc/boot/virtex405-head.S for details.
4d2e26a3 94
70bf0333
GL
95 treeImage.%; Image format for used with OpenBIOS firmware found
96 on some ppc4xx hardware. This image embeds a device
97 tree blob inside the image.
4d2e26a3 98
70bf0333
GL
99 uImage: Native image format used by U-Boot. The uImage target
100 does not add any boot code. It just wraps a compressed
101 vmlinux in the uImage data structure. This image
102 requires a version of U-Boot that is able to pass
103 a device tree to the kernel at boot. If using an older
104 version of U-Boot, then you need to use a cuImage
105 instead.
4d2e26a3 106
70bf0333
GL
107 zImage.%: Image format which does not embed a device tree.
108 Used by OpenFirmware and other firmware interfaces
109 which are able to supply a device tree. This image
110 expects firmware to provide the device tree at boot.
111 Typically, if you have general purpose PowerPC
112 hardware then you want this image format.
4d2e26a3 113 ==================== ========================================================
70bf0333
GL
114
115Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
116and cuImage) all generate the device tree blob from a file in the
117arch/powerpc/boot/dts/ directory. The Makefile selects the correct device
118tree source based on the name of the target. Therefore, if the kernel is
119built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
120build system will use arch/powerpc/boot/dts/walnut.dts to build
121treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
122the simpleImage.virtex405-ml403.
123
124Two special targets called 'zImage' and 'zImage.initrd' also exist. These
125targets build all the default images as selected by the kernel configuration.
126Default images are selected by the boot wrapper Makefile
127(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look
128at the Makefile to see which default image targets are available.
129
130How it is built
131---------------
132arch/powerpc is designed to support multiplatform kernels, which means
133that a single vmlinux image can be booted on many different target boards.
134It also means that the boot wrapper must be able to wrap for many kinds of
135images on a single build. The design decision was made to not use any
136conditional compilation code (#ifdef, etc) in the boot wrapper source code.
137All of the boot wrapper pieces are buildable at any time regardless of the
138kernel configuration. Building all the wrapper bits on every kernel build
139also ensures that obscure parts of the wrapper are at the very least compile
140tested in a large variety of environments.
141
142The wrapper is adapted for different image types at link time by linking in
143just the wrapper bits that are appropriate for the image type. The 'wrapper
144script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
145is responsible for selecting the correct wrapper bits for the image type.
146The arguments are well documented in the script's comment block, so they
147are not repeated here. However, it is worth mentioning that the script
148uses the -p (platform) argument as the main method of deciding which wrapper
149bits to compile in. Look for the large 'case "$platform" in' block in the
150middle of the script. This is also the place where platform specific fixups
151can be selected by changing the link order.
152
153In particular, care should be taken when working with cuImages. cuImage
154wrapper bits are very board specific and care should be taken to make sure
155the target you are trying to build is supported by the wrapper bits.