Lines Matching refs:the
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
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
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:
25 U-Boot (for versions that don't understand the device
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,
36 which populates the embedded device tree with data
37 from the platform specific bd_info file. The platform
39 arch/powerpc/boot/cuboot.*.c. Selection of the correct
41 the wrapper structure.
43 inside the image instead of provided by firmware. The
45 binary depending on the platform.
50 data from the board firmware, but simpleImages do not
51 talk to the firmware at all.
53 Planet boards using the PlanetCore firmware. Board
56 can be overridden by the wrapper script.
61 Firmware cannot pass any configuration data to the
63 the embedded device tree for all information.
67 the Xilinx Virtex platform). The only assumption that
69 and that the MMU is either off or has RAM mapped to
72 specific initialization code to the start of the bootup
74 ensure that the cache is invalidated before caching
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
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
86 tree blob inside the image.
89 vmlinux in the uImage data structure. This image
91 a device tree to the kernel at boot. If using an older
97 expects firmware to provide the device tree at boot.
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
108 the simpleImage.virtex405-ml403.
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.
120 It also means that the boot wrapper must be able to wrap for many kinds of
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
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.
141 the target you are trying to build is supported by the wrapper bits.