Lines Matching refs:image
15 general way. Each SoC does what it needs to build an image, often packing or
26 required image layout. It uses this to work out what to place where. The
28 to read an image and extract its constituent parts.
36 place entries at a fixed location in the image, or fit them together with
46 Binman can also support incorporating filesystems in the image if required.
50 to be useful in other image-packaging situations.
57 parts. In many cases the various binaries which go into the image come from
60 in the firmware image, it is built elsewhere.
77 - Provides for a standard image description available in the build and at
79 - SoC-specific image-signing tools can be accomodated
80 - Avoids cluttering the U-Boot build system with image-building code
81 - The image description is automatically available at run-time in U-Boot,
83 - The image description is easily readable (it's a text file in device-tree
92 - image - an output file containing a firmware image
93 - binary - an input binary that goes into the image
99 FIT is U-Boot's official image format. It supports multiple binaries with
108 Binman considers FIT to be one of the binaries it can place in the image.
124 needed an image description file: a device tree, like binman, but in a
129 image types. These can be listed by running 'mkimage -T list'. Examples
134 which it can place in an image. Binman does not replace the mkimage tool or
139 into a final image (binman).
145 Binman aims to replace some of the ad-hoc image creation in the U-Boot
150 1. It uses a custom mksunxiboot tool to build an SPL image called
153 2. It uses mkimage to package U-Boot into a legacy image file (so that it can
156 3. It builds a final output image called u-boot-sunxi-with-spl.bin which
162 case, it would then create the image from the component parts.
174 firmare image.
190 to build an image for a board. The board name is the same name used when
212 The binman node is called 'binman'. An example image description is shown
227 This requests binman to create an image file called u-boot-sunxi-with-spl.bin
229 normal U-Boot Makefile), some 0xff padding, and a U-Boot legacy image. The
234 The binman node describes an image. The sub-nodes describe entries in the
235 image. Each entry represents a region within the overall image. The name of
239 Entries are normally placed into the image sequentially, one after the other.
240 The image size is the total size of all entries. As you can see, you can
244 name. If you want to put the same binary in the image multiple times, you can
250 This sets the position of an entry within the image. The first byte
251 of the image is normally at position 0. If 'pos' is not provided,
253 the image's entry area (normally 0) if there is no previous region.
257 so that the entry starts on an aligned boundary within the image. For
275 other properties). This allows room to be created in the image for
305 Sets the image size in bytes, for example 'size = <0x100000>' for a
306 1MB image.
309 This sets the alignment of the image size. For example, to ensure
310 that the image ends on a 512-byte boundary, use 'align-size = <512>'.
314 This sets the padding before the image entries. The first entry will
318 This sets the padding after the image entries. The padding will be
322 This specifies the pad byte to use when padding in the image. It
326 This specifies the image filename. It defaults to 'image.bin'.
339 Normally only a single image is generated. To create more than one
340 image, put this property in the binman node. For example, this will
361 up so that the image finished at the 4GB boundary. This boolean
362 option can be enabled to support this. The image size must be
363 provided so that binman knows when the image should start. For an
379 u-boot.bin image does not include microcode, no error will
383 Order of image creation
386 Image creation proceeds in the following order, for each entry in the image.
404 size of an entry. The 'current' image position is passed in, and the function
409 the image size. If the image does not have a defined size, the size is set
413 outside the image.
421 7. BuildImage() - builds the image and writes it to a file. This is the final
505 image. The difficulty comes from the wide variety of input types (simple
526 to use device tree (such as a very small SPL image)
527 - Write an image map to a text file
530 - Add an option to decode an image into the constituent binaries
532 which is then placed in the image)
533 - Support building an image for a board (-b) more completely, with a