blob: 1aa2459d50ca78b1c25287556341e2a9b17b43e6 [file] [log] [blame]
Simon Glass75ead662021-03-18 20:25:13 +13001.. SPDX-License-Identifier: GPL-2.0+
2.. Copyright (c) 2016 Google, Inc
Simon Glass2574ef62016-11-25 20:15:51 -07003
4Introduction
Simon Glassfa888282021-03-18 20:25:14 +13005============
Simon Glass2574ef62016-11-25 20:15:51 -07006
7Firmware often consists of several components which must be packaged together.
8For example, we may have SPL, U-Boot, a device tree and an environment area
9grouped together and placed in MMC flash. When the system starts, it must be
10able to find these pieces.
11
Simon Glass774b23f2021-03-18 20:25:17 +130012Building firmware should be separate from packaging it. Many of the complexities
13of modern firmware build systems come from trying to do both at once. With
14binman, you build all the pieces that are needed, using whatever assortment of
15projects and build systems are needed, then use binman to stitch everything
16together.
Simon Glass2574ef62016-11-25 20:15:51 -070017
Simon Glass2574ef62016-11-25 20:15:51 -070018
19What it does
20------------
21
22Binman reads your board's device tree and finds a node which describes the
Simon Glass774b23f2021-03-18 20:25:17 +130023required image layout. It uses this to work out what to place where.
24
25Binman provides a mechanism for building images, from simple SPL + U-Boot
26combinations, to more complex arrangements with many parts. It also allows
27users to inspect images, extract and replace binaries within them, repacking if
28needed.
Simon Glass2574ef62016-11-25 20:15:51 -070029
30
31Features
32--------
33
Simon Glass774b23f2021-03-18 20:25:17 +130034Apart from basic padding, alignment and positioning features, Binman supports
35hierarchical images, compression, hashing and dealing with the binary blobs
36which are a sad trend in open-source firmware at present.
Simon Glass2574ef62016-11-25 20:15:51 -070037
Simon Glass774b23f2021-03-18 20:25:17 +130038Executable binaries can access the location of other binaries in an image by
39using special linker symbols (zero-overhead but somewhat limited) or by reading
40the devicetree description of the image.
Simon Glass2574ef62016-11-25 20:15:51 -070041
Simon Glass774b23f2021-03-18 20:25:17 +130042Binman is designed primarily for use with U-Boot and associated binaries such
43as ARM Trusted Firmware, but it is suitable for use with other projects, such
44as Zephyr. Binman also provides facilities useful in Chromium OS, such as CBFS,
45vblocks and and the like.
46
47Binman provides a way to process binaries before they are included, by adding a
48Python plug-in.
Simon Glass2574ef62016-11-25 20:15:51 -070049
50Binman is intended for use with U-Boot but is designed to be general enough
51to be useful in other image-packaging situations.
52
53
54Motivation
55----------
56
Simon Glass774b23f2021-03-18 20:25:17 +130057As mentioned above, packaging of firmware is quite a different task from
58building the various parts. In many cases the various binaries which go into
59the image come from separate build systems. For example, ARM Trusted Firmware
60is used on ARMv8 devices but is not built in the U-Boot tree. If a Linux kernel
61is included in the firmware image, it is built elsewhere.
Simon Glass2574ef62016-11-25 20:15:51 -070062
63It is of course possible to add more and more build rules to the U-Boot
64build system to cover these cases. It can shell out to other Makefiles and
65build scripts. But it seems better to create a clear divide between building
66software and packaging it.
67
68At present this is handled by manual instructions, different for each board,
69on how to create images that will boot. By turning these instructions into a
70standard format, we can support making valid images for any board without
71manual effort, lots of READMEs, etc.
72
73Benefits:
Simon Glass2574ef62016-11-25 20:15:51 -070074
Simon Glass75ead662021-03-18 20:25:13 +130075 - Each binary can have its own build system and tool chain without creating
76 any dependencies between them
77 - Avoids the need for a single-shot build: individual parts can be updated
78 and brought in as needed
79 - Provides for a standard image description available in the build and at
80 run-time
81 - SoC-specific image-signing tools can be accommodated
82 - Avoids cluttering the U-Boot build system with image-building code
83 - The image description is automatically available at run-time in U-Boot,
84 SPL. It can be made available to other software also
85 - The image description is easily readable (it's a text file in device-tree
86 format) and permits flexible packing of binaries
87
Simon Glass2574ef62016-11-25 20:15:51 -070088
89Terminology
90-----------
91
92Binman uses the following terms:
93
94- image - an output file containing a firmware image
95- binary - an input binary that goes into the image
96
97
98Relationship to FIT
99-------------------
100
101FIT is U-Boot's official image format. It supports multiple binaries with
102load / execution addresses, compression. It also supports verification
103through hashing and RSA signatures.
104
105FIT was originally designed to support booting a Linux kernel (with an
106optional ramdisk) and device tree chosen from various options in the FIT.
107Now that U-Boot supports configuration via device tree, it is possible to
108load U-Boot from a FIT, with the device tree chosen by SPL.
109
110Binman considers FIT to be one of the binaries it can place in the image.
111
112Where possible it is best to put as much as possible in the FIT, with binman
113used to deal with cases not covered by FIT. Examples include initial
114execution (since FIT itself does not have an executable header) and dealing
115with device boundaries, such as the read-only/read-write separation in SPI
116flash.
117
118For U-Boot, binman should not be used to create ad-hoc images in place of
119FIT.
120
121
122Relationship to mkimage
123-----------------------
124
125The mkimage tool provides a means to create a FIT. Traditionally it has
126needed an image description file: a device tree, like binman, but in a
127different format. More recently it has started to support a '-f auto' mode
128which can generate that automatically.
129
130More relevant to binman, mkimage also permits creation of many SoC-specific
131image types. These can be listed by running 'mkimage -T list'. Examples
132include 'rksd', the Rockchip SD/MMC boot format. The mkimage tool is often
133called from the U-Boot build system for this reason.
134
135Binman considers the output files created by mkimage to be binary blobs
136which it can place in an image. Binman does not replace the mkimage tool or
Michael Heimpold55c822d2018-08-22 22:01:24 +0200137this purpose. It would be possible in some situations to create a new entry
Simon Glass2574ef62016-11-25 20:15:51 -0700138type for the images in mkimage, but this would not add functionality. It
Michael Heimpold55c822d2018-08-22 22:01:24 +0200139seems better to use the mkimage tool to generate binaries and avoid blurring
Simon Glass2574ef62016-11-25 20:15:51 -0700140the boundaries between building input files (mkimage) and packaging then
141into a final image (binman).
142
Simon Glassfa888282021-03-18 20:25:14 +1300143
144Using binman
145============
Simon Glass2574ef62016-11-25 20:15:51 -0700146
147Example use of binman in U-Boot
148-------------------------------
149
150Binman aims to replace some of the ad-hoc image creation in the U-Boot
151build system.
152
153Consider sunxi. It has the following steps:
154
Simon Glass75ead662021-03-18 20:25:13 +1300155 #. It uses a custom mksunxiboot tool to build an SPL image called
156 sunxi-spl.bin. This should probably move into mkimage.
Simon Glass2574ef62016-11-25 20:15:51 -0700157
Simon Glass75ead662021-03-18 20:25:13 +1300158 #. It uses mkimage to package U-Boot into a legacy image file (so that it can
159 hold the load and execution address) called u-boot.img.
Simon Glass2574ef62016-11-25 20:15:51 -0700160
Simon Glass75ead662021-03-18 20:25:13 +1300161 #. It builds a final output image called u-boot-sunxi-with-spl.bin which
162 consists of sunxi-spl.bin, some padding and u-boot.img.
Simon Glass2574ef62016-11-25 20:15:51 -0700163
164Binman is intended to replace the last step. The U-Boot build system builds
165u-boot.bin and sunxi-spl.bin. Binman can then take over creation of
166sunxi-spl.bin (by calling mksunxiboot, or hopefully one day mkimage). In any
167case, it would then create the image from the component parts.
168
169This simplifies the U-Boot Makefile somewhat, since various pieces of logic
170can be replaced by a call to binman.
171
172
173Example use of binman for x86
174-----------------------------
175
176In most cases x86 images have a lot of binary blobs, 'black-box' code
177provided by Intel which must be run for the platform to work. Typically
178these blobs are not relocatable and must be placed at fixed areas in the
Michael Heimpold55c822d2018-08-22 22:01:24 +0200179firmware image.
Simon Glass2574ef62016-11-25 20:15:51 -0700180
181Currently this is handled by ifdtool, which places microcode, FSP, MRC, VGA
182BIOS, reference code and Intel ME binaries into a u-boot.rom file.
183
184Binman is intended to replace all of this, with ifdtool left to handle only
185the configuration of the Intel-format descriptor.
186
187
188Running binman
189--------------
190
Simon Glass75ead662021-03-18 20:25:13 +1300191First install prerequisites, e.g::
Simon Glass567b6822019-07-08 13:18:35 -0600192
Simon Glass75ead662021-03-18 20:25:13 +1300193 sudo apt-get install python-pyelftools python3-pyelftools lzma-alone \
194 liblz4-tool
Simon Glass567b6822019-07-08 13:18:35 -0600195
Simon Glass75ead662021-03-18 20:25:13 +1300196Type::
Simon Glass2574ef62016-11-25 20:15:51 -0700197
Simon Glass75ead662021-03-18 20:25:13 +1300198 binman build -b <board_name>
Simon Glass2574ef62016-11-25 20:15:51 -0700199
200to build an image for a board. The board name is the same name used when
201configuring U-Boot (e.g. for sandbox_defconfig the board name is 'sandbox').
202Binman assumes that the input files for the build are in ../b/<board_name>.
203
Simon Glass75ead662021-03-18 20:25:13 +1300204Or you can specify this explicitly::
Simon Glass2574ef62016-11-25 20:15:51 -0700205
Simon Glass75ead662021-03-18 20:25:13 +1300206 binman build -I <build_path>
Simon Glass2574ef62016-11-25 20:15:51 -0700207
208where <build_path> is the build directory containing the output of the U-Boot
209build.
210
211(Future work will make this more configurable)
212
213In either case, binman picks up the device tree file (u-boot.dtb) and looks
214for its instructions in the 'binman' node.
215
216Binman has a few other options which you can see by running 'binman -h'.
217
218
Simon Glass4b94ac92017-11-12 21:52:06 -0700219Enabling binman for a board
220---------------------------
221
Simon Glass774b23f2021-03-18 20:25:17 +1300222At present binman is invoked from a rule in the main Makefile. You should be
223able to enable CONFIG_BINMAN to enable this rule.
Simon Glass4b94ac92017-11-12 21:52:06 -0700224
Simon Glass774b23f2021-03-18 20:25:17 +1300225The output file is typically named image.bin and is located in the output
226directory. If input files are needed to you add these to INPUTS-y either in the
227main Makefile or in a config.mk file in your arch subdirectory.
Simon Glass4b94ac92017-11-12 21:52:06 -0700228
229Once binman is executed it will pick up its instructions from a device-tree
230file, typically <soc>-u-boot.dtsi, where <soc> is your CONFIG_SYS_SOC value.
231You can use other, more specific CONFIG options - see 'Automatic .dtsi
232inclusion' below.
233
234
Simon Glassfa888282021-03-18 20:25:14 +1300235Access to binman entry offsets at run time (symbols)
236----------------------------------------------------
237
238Binman assembles images and determines where each entry is placed in the image.
239This information may be useful to U-Boot at run time. For example, in SPL it
240is useful to be able to find the location of U-Boot so that it can be executed
241when SPL is finished.
242
243Binman allows you to declare symbols in the SPL image which are filled in
244with their correct values during the build. For example::
245
246 binman_sym_declare(ulong, u_boot_any, image_pos);
247
248declares a ulong value which will be assigned to the image-pos of any U-Boot
249image (u-boot.bin, u-boot.img, u-boot-nodtb.bin) that is present in the image.
250You can access this value with something like::
251
252 ulong u_boot_offset = binman_sym(ulong, u_boot_any, image_pos);
253
254Thus u_boot_offset will be set to the image-pos of U-Boot in memory, assuming
255that the whole image has been loaded, or is available in flash. You can then
256jump to that address to start U-Boot.
257
258At present this feature is only supported in SPL and TPL. In principle it is
259possible to fill in such symbols in U-Boot proper, as well, but a future C
260library is planned for this instead, to read from the device tree.
261
262As well as image-pos, it is possible to read the size of an entry and its
263offset (which is the start position of the entry within its parent).
264
265A small technical note: Binman automatically adds the base address of the image
266(i.e. __image_copy_start) to the value of the image-pos symbol, so that when the
267image is loaded to its linked address, the value will be correct and actually
268point into the image.
269
270For example, say SPL is at the start of the image and linked to start at address
27180108000. If U-Boot's image-pos is 0x8000 then binman will write an image-pos
272for U-Boot of 80110000 into the SPL binary, since it assumes the image is loaded
273to 80108000, with SPL at 80108000 and U-Boot at 80110000.
274
275For x86 devices (with the end-at-4gb property) this base address is not added
276since it is assumed that images are XIP and the offsets already include the
277address.
278
279
280Access to binman entry offsets at run time (fdt)
281------------------------------------------------
282
283Binman can update the U-Boot FDT to include the final position and size of
284each entry in the images it processes. The option to enable this is -u and it
285causes binman to make sure that the 'offset', 'image-pos' and 'size' properties
286are set correctly for every entry. Since it is not necessary to specify these in
287the image definition, binman calculates the final values and writes these to
288the device tree. These can be used by U-Boot at run-time to find the location
289of each entry.
290
291Alternatively, an FDT map entry can be used to add a special FDT containing
292just the information about the image. This is preceded by a magic string so can
293be located anywhere in the image. An image header (typically at the start or end
294of the image) can be used to point to the FDT map. See fdtmap and image-header
295entries for more information.
296
297
298Map files
299---------
300
301The -m option causes binman to output a .map file for each image that it
302generates. This shows the offset and size of each entry. For example::
303
304 Offset Size Name
305 00000000 00000028 main-section
306 00000000 00000010 section@0
307 00000000 00000004 u-boot
308 00000010 00000010 section@1
309 00000000 00000004 u-boot
310
311This shows a hierarchical image with two sections, each with a single entry. The
312offsets of the sections are absolute hex byte offsets within the image. The
313offsets of the entries are relative to their respective sections. The size of
314each entry is also shown, in bytes (hex). The indentation shows the entries
315nested inside their sections.
316
317
318Passing command-line arguments to entries
319-----------------------------------------
320
321Sometimes it is useful to pass binman the value of an entry property from the
322command line. For example some entries need access to files and it is not
323always convenient to put these filenames in the image definition (device tree).
324
325The-a option supports this::
326
327 -a<prop>=<value>
328
329where::
330
331 <prop> is the property to set
332 <value> is the value to set it to
333
334Not all properties can be provided this way. Only some entries support it,
335typically for filenames.
336
337
Simon Glass2574ef62016-11-25 20:15:51 -0700338Image description format
Simon Glassfa888282021-03-18 20:25:14 +1300339========================
Simon Glass2574ef62016-11-25 20:15:51 -0700340
341The binman node is called 'binman'. An example image description is shown
Simon Glass75ead662021-03-18 20:25:13 +1300342below::
Simon Glass2574ef62016-11-25 20:15:51 -0700343
Simon Glass75ead662021-03-18 20:25:13 +1300344 binman {
345 filename = "u-boot-sunxi-with-spl.bin";
346 pad-byte = <0xff>;
347 blob {
348 filename = "spl/sunxi-spl.bin";
349 };
350 u-boot {
351 offset = <CONFIG_SPL_PAD_TO>;
352 };
353 };
Simon Glass2574ef62016-11-25 20:15:51 -0700354
355
356This requests binman to create an image file called u-boot-sunxi-with-spl.bin
357consisting of a specially formatted SPL (spl/sunxi-spl.bin, built by the
358normal U-Boot Makefile), some 0xff padding, and a U-Boot legacy image. The
359padding comes from the fact that the second binary is placed at
360CONFIG_SPL_PAD_TO. If that line were omitted then the U-Boot binary would
361immediately follow the SPL binary.
362
363The binman node describes an image. The sub-nodes describe entries in the
364image. Each entry represents a region within the overall image. The name of
365the entry (blob, u-boot) tells binman what to put there. For 'blob' we must
366provide a filename. For 'u-boot', binman knows that this means 'u-boot.bin'.
367
368Entries are normally placed into the image sequentially, one after the other.
369The image size is the total size of all entries. As you can see, you can
Simon Glasse8561af2018-08-01 15:22:37 -0600370specify the start offset of an entry using the 'offset' property.
Simon Glass2574ef62016-11-25 20:15:51 -0700371
372Note that due to a device tree requirement, all entries must have a unique
373name. If you want to put the same binary in the image multiple times, you can
374use any unique name, with the 'type' property providing the type.
375
376The attributes supported for entries are described below.
377
Simon Glasse8561af2018-08-01 15:22:37 -0600378offset:
Simon Glass75ead662021-03-18 20:25:13 +1300379 This sets the offset of an entry within the image or section containing
380 it. The first byte of the image is normally at offset 0. If 'offset' is
381 not provided, binman sets it to the end of the previous region, or the
382 start of the image's entry area (normally 0) if there is no previous
383 region.
Simon Glass2574ef62016-11-25 20:15:51 -0700384
385align:
Simon Glass75ead662021-03-18 20:25:13 +1300386 This sets the alignment of the entry. The entry offset is adjusted
387 so that the entry starts on an aligned boundary within the containing
388 section or image. For example 'align = <16>' means that the entry will
389 start on a 16-byte boundary. This may mean that padding is added before
390 the entry. The padding is part of the containing section but is not
391 included in the entry, meaning that an empty space may be created before
392 the entry starts. Alignment should be a power of 2. If 'align' is not
393 provided, no alignment is performed.
Simon Glass2574ef62016-11-25 20:15:51 -0700394
395size:
Simon Glass75ead662021-03-18 20:25:13 +1300396 This sets the size of the entry. The contents will be padded out to
397 this size. If this is not provided, it will be set to the size of the
398 contents.
Simon Glass2574ef62016-11-25 20:15:51 -0700399
400pad-before:
Simon Glass75ead662021-03-18 20:25:13 +1300401 Padding before the contents of the entry. Normally this is 0, meaning
402 that the contents start at the beginning of the entry. This can be used
403 to offset the entry contents a little. While this does not affect the
404 contents of the entry within binman itself (the padding is performed
405 only when its parent section is assembled), the end result will be that
406 the entry starts with the padding bytes, so may grow. Defaults to 0.
Simon Glass2574ef62016-11-25 20:15:51 -0700407
408pad-after:
Simon Glass75ead662021-03-18 20:25:13 +1300409 Padding after the contents of the entry. Normally this is 0, meaning
410 that the entry ends at the last byte of content (unless adjusted by
411 other properties). This allows room to be created in the image for
412 this entry to expand later. While this does not affect the contents of
413 the entry within binman itself (the padding is performed only when its
414 parent section is assembled), the end result will be that the entry ends
415 with the padding bytes, so may grow. Defaults to 0.
Simon Glass2574ef62016-11-25 20:15:51 -0700416
417align-size:
Simon Glass75ead662021-03-18 20:25:13 +1300418 This sets the alignment of the entry size. For example, to ensure
419 that the size of an entry is a multiple of 64 bytes, set this to 64.
420 While this does not affect the contents of the entry within binman
421 itself (the padding is performed only when its parent section is
422 assembled), the end result is that the entry ends with the padding
423 bytes, so may grow. If 'align-size' is not provided, no alignment is
424 performed.
Simon Glass2574ef62016-11-25 20:15:51 -0700425
426align-end:
Simon Glass75ead662021-03-18 20:25:13 +1300427 This sets the alignment of the end of an entry with respect to the
428 containing section. Some entries require that they end on an alignment
429 boundary, regardless of where they start. This does not move the start
430 of the entry, so the contents of the entry will still start at the
431 beginning. But there may be padding at the end. While this does not
432 affect the contents of the entry within binman itself (the padding is
433 performed only when its parent section is assembled), the end result
434 is that the entry ends with the padding bytes, so may grow.
435 If 'align-end' is not provided, no alignment is performed.
Simon Glass2574ef62016-11-25 20:15:51 -0700436
437filename:
Simon Glass75ead662021-03-18 20:25:13 +1300438 For 'blob' types this provides the filename containing the binary to
439 put into the entry. If binman knows about the entry type (like
440 u-boot-bin), then there is no need to specify this.
Simon Glass2574ef62016-11-25 20:15:51 -0700441
442type:
Simon Glass75ead662021-03-18 20:25:13 +1300443 Sets the type of an entry. This defaults to the entry name, but it is
444 possible to use any name, and then add (for example) 'type = "u-boot"'
445 to specify the type.
Simon Glass2574ef62016-11-25 20:15:51 -0700446
Simon Glasse8561af2018-08-01 15:22:37 -0600447offset-unset:
Simon Glass75ead662021-03-18 20:25:13 +1300448 Indicates that the offset of this entry should not be set by placing
449 it immediately after the entry before. Instead, is set by another
450 entry which knows where this entry should go. When this boolean
451 property is present, binman will give an error if another entry does
452 not set the offset (with the GetOffsets() method).
Simon Glass4ba8d502018-06-01 09:38:17 -0600453
Simon Glass9dcc8612018-08-01 15:22:42 -0600454image-pos:
Simon Glass75ead662021-03-18 20:25:13 +1300455 This cannot be set on entry (or at least it is ignored if it is), but
456 with the -u option, binman will set it to the absolute image position
457 for each entry. This makes it easy to find out exactly where the entry
458 ended up in the image, regardless of parent sections, etc.
Simon Glass9dcc8612018-08-01 15:22:42 -0600459
Simon Glassfa79a812018-09-14 04:57:29 -0600460expand-size:
Simon Glass75ead662021-03-18 20:25:13 +1300461 Expand the size of this entry to fit available space. This space is only
462 limited by the size of the image/section and the position of the next
463 entry.
Simon Glass2574ef62016-11-25 20:15:51 -0700464
Simon Glassaa2fcf92019-07-08 14:25:30 -0600465compress:
Simon Glass75ead662021-03-18 20:25:13 +1300466 Sets the compression algortihm to use (for blobs only). See the entry
467 documentation for details.
Simon Glassaa2fcf92019-07-08 14:25:30 -0600468
Simon Glassa820af72020-09-06 10:39:09 -0600469missing-msg:
Simon Glass75ead662021-03-18 20:25:13 +1300470 Sets the tag of the message to show if this entry is missing. This is
471 used for external blobs. When they are missing it is helpful to show
472 information about what needs to be fixed. See missing-blob-help for the
473 message for each tag.
Simon Glassa820af72020-09-06 10:39:09 -0600474
Simon Glass7098b7f2021-03-21 18:24:30 +1300475no-expanded:
476 By default binman substitutes entries with expanded versions if available,
477 so that a `u-boot` entry type turns into `u-boot-expanded`, for example. The
478 `--no-expanded` command-line option disables this globally. The
479 `no-expanded` property disables this just for a single entry. Put the
480 `no-expanded` boolean property in the node to select this behaviour.
481
Simon Glass80045812018-09-14 04:57:30 -0600482The attributes supported for images and sections are described below. Several
483are similar to those for entries.
Simon Glass2574ef62016-11-25 20:15:51 -0700484
485size:
Simon Glass75ead662021-03-18 20:25:13 +1300486 Sets the image size in bytes, for example 'size = <0x100000>' for a
487 1MB image.
Simon Glass2574ef62016-11-25 20:15:51 -0700488
Simon Glasseb023b32019-04-25 21:58:39 -0600489offset:
Simon Glass75ead662021-03-18 20:25:13 +1300490 This is similar to 'offset' in entries, setting the offset of a section
491 within the image or section containing it. The first byte of the section
492 is normally at offset 0. If 'offset' is not provided, binman sets it to
493 the end of the previous region, or the start of the image's entry area
494 (normally 0) if there is no previous region.
Simon Glasseb023b32019-04-25 21:58:39 -0600495
Simon Glass2574ef62016-11-25 20:15:51 -0700496align-size:
Simon Glass75ead662021-03-18 20:25:13 +1300497 This sets the alignment of the image size. For example, to ensure
498 that the image ends on a 512-byte boundary, use 'align-size = <512>'.
499 If 'align-size' is not provided, no alignment is performed.
Simon Glass2574ef62016-11-25 20:15:51 -0700500
501pad-before:
Simon Glass75ead662021-03-18 20:25:13 +1300502 This sets the padding before the image entries. The first entry will
503 be positioned after the padding. This defaults to 0.
Simon Glass2574ef62016-11-25 20:15:51 -0700504
505pad-after:
Simon Glass75ead662021-03-18 20:25:13 +1300506 This sets the padding after the image entries. The padding will be
507 placed after the last entry. This defaults to 0.
Simon Glass2574ef62016-11-25 20:15:51 -0700508
509pad-byte:
Simon Glass75ead662021-03-18 20:25:13 +1300510 This specifies the pad byte to use when padding in the image. It
511 defaults to 0. To use 0xff, you would add 'pad-byte = <0xff>'.
Simon Glass2574ef62016-11-25 20:15:51 -0700512
513filename:
Simon Glass75ead662021-03-18 20:25:13 +1300514 This specifies the image filename. It defaults to 'image.bin'.
Simon Glass2574ef62016-11-25 20:15:51 -0700515
Simon Glasse8561af2018-08-01 15:22:37 -0600516sort-by-offset:
Simon Glass75ead662021-03-18 20:25:13 +1300517 This causes binman to reorder the entries as needed to make sure they
518 are in increasing positional order. This can be used when your entry
519 order may not match the positional order. A common situation is where
520 the 'offset' properties are set by CONFIG options, so their ordering is
521 not known a priori.
Simon Glass2574ef62016-11-25 20:15:51 -0700522
Simon Glass75ead662021-03-18 20:25:13 +1300523 This is a boolean property so needs no value. To enable it, add a
524 line 'sort-by-offset;' to your description.
Simon Glass2574ef62016-11-25 20:15:51 -0700525
526multiple-images:
Simon Glass75ead662021-03-18 20:25:13 +1300527 Normally only a single image is generated. To create more than one
528 image, put this property in the binman node. For example, this will
529 create image1.bin containing u-boot.bin, and image2.bin containing
530 both spl/u-boot-spl.bin and u-boot.bin::
Simon Glass2574ef62016-11-25 20:15:51 -0700531
Simon Glass75ead662021-03-18 20:25:13 +1300532 binman {
533 multiple-images;
534 image1 {
535 u-boot {
536 };
537 };
Simon Glass2574ef62016-11-25 20:15:51 -0700538
Simon Glass75ead662021-03-18 20:25:13 +1300539 image2 {
540 spl {
541 };
542 u-boot {
543 };
544 };
545 };
Simon Glass2574ef62016-11-25 20:15:51 -0700546
547end-at-4gb:
Simon Glass75ead662021-03-18 20:25:13 +1300548 For x86 machines the ROM offsets start just before 4GB and extend
549 up so that the image finished at the 4GB boundary. This boolean
550 option can be enabled to support this. The image size must be
551 provided so that binman knows when the image should start. For an
552 8MB ROM, the offset of the first entry would be 0xfff80000 with
553 this option, instead of 0 without this option.
Simon Glass2574ef62016-11-25 20:15:51 -0700554
Jagdish Gediya0fb978c2018-09-03 21:35:07 +0530555skip-at-start:
Simon Glass75ead662021-03-18 20:25:13 +1300556 This property specifies the entry offset of the first entry.
Jagdish Gediya0fb978c2018-09-03 21:35:07 +0530557
Simon Glass75ead662021-03-18 20:25:13 +1300558 For PowerPC mpc85xx based CPU, CONFIG_SYS_TEXT_BASE is the entry
559 offset of the first entry. It can be 0xeff40000 or 0xfff40000 for
560 nor flash boot, 0x201000 for sd boot etc.
Jagdish Gediya0fb978c2018-09-03 21:35:07 +0530561
Simon Glass75ead662021-03-18 20:25:13 +1300562 'end-at-4gb' property is not applicable where CONFIG_SYS_TEXT_BASE +
563 Image size != 4gb.
Simon Glass2574ef62016-11-25 20:15:51 -0700564
Simon Glassf427c5f2021-03-21 18:24:33 +1300565align-default:
566 Specifies the default alignment for entries in this section, if they do
567 not specify an alignment. Note that this only applies to top-level entries
568 in the section (direct subentries), not any subentries of those entries.
569 This means that each section must specify its own default alignment, if
570 required.
571
Simon Glass2574ef62016-11-25 20:15:51 -0700572Examples of the above options can be found in the tests. See the
573tools/binman/test directory.
574
Simon Glasse76a3e62018-06-01 09:38:11 -0600575It is possible to have the same binary appear multiple times in the image,
576either by using a unit number suffix (u-boot@0, u-boot@1) or by using a
577different name for each and specifying the type with the 'type' attribute.
578
Simon Glass2574ef62016-11-25 20:15:51 -0700579
Michael Heimpold55c822d2018-08-22 22:01:24 +0200580Sections and hierachical images
Simon Glassa91e1152018-06-01 09:38:16 -0600581-------------------------------
582
583Sometimes it is convenient to split an image into several pieces, each of which
584contains its own set of binaries. An example is a flash device where part of
585the image is read-only and part is read-write. We can set up sections for each
586of these, and place binaries in them independently. The image is still produced
587as a single output file.
588
589This feature provides a way of creating hierarchical images. For example here
Simon Glass1e324002018-06-01 09:38:19 -0600590is an example image with two copies of U-Boot. One is read-only (ro), intended
591to be written only in the factory. Another is read-write (rw), so that it can be
Simon Glassa91e1152018-06-01 09:38:16 -0600592upgraded in the field. The sizes are fixed so that the ro/rw boundary is known
Simon Glass75ead662021-03-18 20:25:13 +1300593and can be programmed::
Simon Glassa91e1152018-06-01 09:38:16 -0600594
Simon Glass75ead662021-03-18 20:25:13 +1300595 binman {
596 section@0 {
597 read-only;
598 name-prefix = "ro-";
599 size = <0x100000>;
600 u-boot {
601 };
602 };
603 section@1 {
604 name-prefix = "rw-";
605 size = <0x100000>;
606 u-boot {
607 };
608 };
609 };
Simon Glassa91e1152018-06-01 09:38:16 -0600610
611This image could be placed into a SPI flash chip, with the protection boundary
612set at 1MB.
613
614A few special properties are provided for sections:
615
616read-only:
Simon Glass75ead662021-03-18 20:25:13 +1300617 Indicates that this section is read-only. This has no impact on binman's
618 operation, but his property can be read at run time.
Simon Glassa91e1152018-06-01 09:38:16 -0600619
Simon Glass3b78d532018-06-01 09:38:21 -0600620name-prefix:
Simon Glass75ead662021-03-18 20:25:13 +1300621 This string is prepended to all the names of the binaries in the
622 section. In the example above, the 'u-boot' binaries which actually be
623 renamed to 'ro-u-boot' and 'rw-u-boot'. This can be useful to
624 distinguish binaries with otherwise identical names.
Simon Glass3b78d532018-06-01 09:38:21 -0600625
Simon Glassa91e1152018-06-01 09:38:16 -0600626
Simon Glassfb30e292019-07-20 12:23:51 -0600627Image Properties
628----------------
629
630Image nodes act like sections but also have a few extra properties:
631
632filename:
Simon Glass75ead662021-03-18 20:25:13 +1300633 Output filename for the image. This defaults to image.bin (or in the
634 case of multiple images <nodename>.bin where <nodename> is the name of
635 the image node.
Simon Glassfb30e292019-07-20 12:23:51 -0600636
637allow-repack:
Simon Glass75ead662021-03-18 20:25:13 +1300638 Create an image that can be repacked. With this option it is possible
639 to change anything in the image after it is created, including updating
640 the position and size of image components. By default this is not
641 permitted since it is not possibly to know whether this might violate a
642 constraint in the image description. For example, if a section has to
643 increase in size to hold a larger binary, that might cause the section
644 to fall out of its allow region (e.g. read-only portion of flash).
Simon Glassfb30e292019-07-20 12:23:51 -0600645
Simon Glass75ead662021-03-18 20:25:13 +1300646 Adding this property causes the original offset and size values in the
647 image description to be stored in the FDT and fdtmap.
Simon Glassfb30e292019-07-20 12:23:51 -0600648
649
Simon Glassfa888282021-03-18 20:25:14 +1300650Hashing Entries
651---------------
652
653It is possible to ask binman to hash the contents of an entry and write that
654value back to the device-tree node. For example::
655
656 binman {
657 u-boot {
658 hash {
659 algo = "sha256";
660 };
661 };
662 };
663
664Here, a new 'value' property will be written to the 'hash' node containing
665the hash of the 'u-boot' entry. Only SHA256 is supported at present. Whole
666sections can be hased if desired, by adding the 'hash' node to the section.
667
668The has value can be chcked at runtime by hashing the data actually read and
669comparing this has to the value in the device tree.
670
671
672Expanded entries
673----------------
674
675Binman automatically replaces 'u-boot' with an expanded version of that, i.e.
676'u-boot-expanded'. This means that when you write::
677
678 u-boot {
679 };
680
681you actually get::
682
683 u-boot {
684 type = "u-boot-expanded';
685 };
686
687which in turn expands to::
688
689 u-boot {
690 type = "section";
691
692 u-boot-nodtb {
693 };
694
695 u-boot-dtb {
696 };
697 };
698
699U-Boot's various phase binaries actually comprise two or three pieces.
700For example, u-boot.bin has the executable followed by a devicetree.
701
702With binman we want to be able to update that devicetree with full image
703information so that it is accessible to the executable. This is tricky
704if it is not clear where the devicetree starts.
705
706The above feature ensures that the devicetree is clearly separated from the
707U-Boot executable and can be updated separately by binman as needed. It can be
708disabled with the --no-expanded flag if required.
709
710The same applies for u-boot-spl and u-boot-spl. In those cases, the expansion
711includes the BSS padding, so for example::
712
713 spl {
714 type = "u-boot-spl"
715 };
716
717you actually get::
718
719 spl {
720 type = "u-boot-expanded';
721 };
722
723which in turn expands to::
724
725 spl {
726 type = "section";
727
728 u-boot-spl-nodtb {
729 };
730
731 u-boot-spl-bss-pad {
732 };
733
734 u-boot-spl-dtb {
735 };
736 };
737
738Of course we should not expand SPL if it has no devicetree. Also if the BSS
739padding is not needed (because BSS is in RAM as with CONFIG_SPL_SEPARATE_BSS),
740the 'u-boot-spl-bss-pad' subnode should not be created. The use of the expaned
741entry type is controlled by the UseExpanded() method. In the SPL case it checks
742the 'spl-dtb' entry arg, which is 'y' or '1' if SPL has a devicetree.
743
744For the BSS case, a 'spl-bss-pad' entry arg controls whether it is present. All
745entry args are provided by the U-Boot Makefile.
746
747
748Compression
749-----------
750
751Binman support compression for 'blob' entries (those of type 'blob' and
752derivatives). To enable this for an entry, add a 'compress' property::
753
754 blob {
755 filename = "datafile";
756 compress = "lz4";
757 };
758
759The entry will then contain the compressed data, using the 'lz4' compression
760algorithm. Currently this is the only one that is supported. The uncompressed
761size is written to the node in an 'uncomp-size' property, if -u is used.
762
763Compression is also supported for sections. In that case the entire section is
764compressed in one block, including all its contents. This means that accessing
765an entry from the section required decompressing the entire section. Also, the
766size of a section indicates the space that it consumes in its parent section
767(and typically the image). With compression, the section may contain more data,
768and the uncomp-size property indicates that, as above. The contents of the
769section is compressed first, before any padding is added. This ensures that the
770padding itself is not compressed, which would be a waste of time.
771
772
773Automatic .dtsi inclusion
774-------------------------
775
776It is sometimes inconvenient to add a 'binman' node to the .dts file for each
777board. This can be done by using #include to bring in a common file. Another
778approach supported by the U-Boot build system is to automatically include
779a common header. You can then put the binman node (and anything else that is
780specific to U-Boot, such as u-boot,dm-pre-reloc properies) in that header
781file.
782
783Binman will search for the following files in arch/<arch>/dts::
784
785 <dts>-u-boot.dtsi where <dts> is the base name of the .dts file
786 <CONFIG_SYS_SOC>-u-boot.dtsi
787 <CONFIG_SYS_CPU>-u-boot.dtsi
788 <CONFIG_SYS_VENDOR>-u-boot.dtsi
789 u-boot.dtsi
790
791U-Boot will only use the first one that it finds. If you need to include a
792more general file you can do that from the more specific file using #include.
793If you are having trouble figuring out what is going on, you can uncomment
794the 'warning' line in scripts/Makefile.lib to see what it has found::
795
796 # Uncomment for debugging
797 # This shows all the files that were considered and the one that we chose.
798 # u_boot_dtsi_options_debug = $(u_boot_dtsi_options_raw)
799
800
Simon Glass7a61c6b2018-07-17 13:25:37 -0600801Entry Documentation
Simon Glass774b23f2021-03-18 20:25:17 +1300802===================
Simon Glass7a61c6b2018-07-17 13:25:37 -0600803
804For details on the various entry types supported by binman and how to use them,
Simon Glass774b23f2021-03-18 20:25:17 +1300805see entries.rst which is generated from the source code using:
806
807 binman entry-docs >tools/binman/entries.rst
Simon Glass7a61c6b2018-07-17 13:25:37 -0600808
Simon Glass774b23f2021-03-18 20:25:17 +1300809.. toctree::
810 :maxdepth: 2
Simon Glass7a61c6b2018-07-17 13:25:37 -0600811
Simon Glass774b23f2021-03-18 20:25:17 +1300812 entries
813
Simon Glassfa888282021-03-18 20:25:14 +1300814
815Managing images
816===============
Simon Glass7a61c6b2018-07-17 13:25:37 -0600817
Simon Glassb2fd11d2019-07-08 14:25:48 -0600818Listing images
819--------------
820
821It is possible to list the entries in an existing firmware image created by
Simon Glass75ead662021-03-18 20:25:13 +1300822binman, provided that there is an 'fdtmap' entry in the image. For example::
Simon Glassb2fd11d2019-07-08 14:25:48 -0600823
824 $ binman ls -i image.bin
825 Name Image-pos Size Entry-type Offset Uncomp-size
826 ----------------------------------------------------------------------
827 main-section c00 section 0
828 u-boot 0 4 u-boot 0
829 section 5fc section 4
830 cbfs 100 400 cbfs 0
831 u-boot 138 4 u-boot 38
832 u-boot-dtb 180 108 u-boot-dtb 80 3b5
833 u-boot-dtb 500 1ff u-boot-dtb 400 3b5
834 fdtmap 6fc 381 fdtmap 6fc
835 image-header bf8 8 image-header bf8
836
837This shows the hierarchy of the image, the position, size and type of each
838entry, the offset of each entry within its parent and the uncompressed size if
839the entry is compressed.
840
Simon Glass75ead662021-03-18 20:25:13 +1300841It is also possible to list just some files in an image, e.g.::
Simon Glassb2fd11d2019-07-08 14:25:48 -0600842
843 $ binman ls -i image.bin section/cbfs
844 Name Image-pos Size Entry-type Offset Uncomp-size
845 --------------------------------------------------------------------
846 cbfs 100 400 cbfs 0
847 u-boot 138 4 u-boot 38
848 u-boot-dtb 180 108 u-boot-dtb 80 3b5
849
Simon Glass75ead662021-03-18 20:25:13 +1300850or with wildcards::
Simon Glassb2fd11d2019-07-08 14:25:48 -0600851
852 $ binman ls -i image.bin "*cb*" "*head*"
853 Name Image-pos Size Entry-type Offset Uncomp-size
854 ----------------------------------------------------------------------
855 cbfs 100 400 cbfs 0
856 u-boot 138 4 u-boot 38
857 u-boot-dtb 180 108 u-boot-dtb 80 3b5
858 image-header bf8 8 image-header bf8
859
860
Simon Glass980a2842019-07-08 14:25:52 -0600861Extracting files from images
862----------------------------
863
864You can extract files from an existing firmware image created by binman,
Simon Glass75ead662021-03-18 20:25:13 +1300865provided that there is an 'fdtmap' entry in the image. For example::
Simon Glass980a2842019-07-08 14:25:52 -0600866
867 $ binman extract -i image.bin section/cbfs/u-boot
868
869which will write the uncompressed contents of that entry to the file 'u-boot' in
870the current directory. You can also extract to a particular file, in this case
Simon Glass75ead662021-03-18 20:25:13 +1300871u-boot.bin::
Simon Glass980a2842019-07-08 14:25:52 -0600872
873 $ binman extract -i image.bin section/cbfs/u-boot -f u-boot.bin
874
875It is possible to extract all files into a destination directory, which will
Simon Glass75ead662021-03-18 20:25:13 +1300876put files in subdirectories matching the entry hierarchy::
Simon Glass980a2842019-07-08 14:25:52 -0600877
878 $ binman extract -i image.bin -O outdir
879
Simon Glass75ead662021-03-18 20:25:13 +1300880or just a selection::
Simon Glass980a2842019-07-08 14:25:52 -0600881
882 $ binman extract -i image.bin "*u-boot*" -O outdir
883
884
Simon Glass072959a2019-07-20 12:23:50 -0600885Replacing files in an image
886---------------------------
887
888You can replace files in an existing firmware image created by binman, provided
889that there is an 'fdtmap' entry in the image. For example:
890
891 $ binman replace -i image.bin section/cbfs/u-boot
892
893which will write the contents of the file 'u-boot' from the current directory
Simon Glass30033c22019-07-20 12:24:15 -0600894to the that entry, compressing if necessary. If the entry size changes, you must
895add the 'allow-repack' property to the original image before generating it (see
896above), otherwise you will get an error.
Simon Glass072959a2019-07-20 12:23:50 -0600897
Simon Glass75ead662021-03-18 20:25:13 +1300898You can also use a particular file, in this case u-boot.bin::
Simon Glass30033c22019-07-20 12:24:15 -0600899
900 $ binman replace -i image.bin section/cbfs/u-boot -f u-boot.bin
901
902It is possible to replace all files from a source directory which uses the same
Simon Glass75ead662021-03-18 20:25:13 +1300903hierarchy as the entries::
Simon Glass30033c22019-07-20 12:24:15 -0600904
905 $ binman replace -i image.bin -I indir
906
907Files that are missing will generate a warning.
908
Simon Glass75ead662021-03-18 20:25:13 +1300909You can also replace just a selection of entries::
Simon Glass30033c22019-07-20 12:24:15 -0600910
911 $ binman replace -i image.bin "*u-boot*" -I indir
912
Simon Glass072959a2019-07-20 12:23:50 -0600913
Simon Glass233a26a92019-07-08 14:25:49 -0600914Logging
915-------
916
917Binman normally operates silently unless there is an error, in which case it
918just displays the error. The -D/--debug option can be used to create a full
Simon Glasscaa5f182021-02-06 09:57:28 -0700919backtrace when errors occur. You can use BINMAN_DEBUG=1 when building to select
920this.
Simon Glass233a26a92019-07-08 14:25:49 -0600921
922Internally binman logs some output while it is running. This can be displayed
923by increasing the -v/--verbosity from the default of 1:
924
925 0: silent
926 1: warnings only
927 2: notices (important messages)
928 3: info about major operations
929 4: detailed information about each operation
930 5: debug (all output)
931
Simon Glasscaa5f182021-02-06 09:57:28 -0700932You can use BINMAN_VERBOSE=5 (for example) when building to select this.
Simon Glass233a26a92019-07-08 14:25:49 -0600933
Simon Glass72232452016-11-25 20:15:53 -0700934
Simon Glassfa888282021-03-18 20:25:14 +1300935Technical details
936=================
Simon Glass72232452016-11-25 20:15:53 -0700937
Simon Glass2574ef62016-11-25 20:15:51 -0700938Order of image creation
939-----------------------
940
941Image creation proceeds in the following order, for each entry in the image.
942
Simon Glasse22f8fa2018-07-06 10:27:41 -06009431. AddMissingProperties() - binman can add calculated values to the device
Simon Glasse8561af2018-08-01 15:22:37 -0600944tree as part of its processing, for example the offset and size of each
Simon Glasse22f8fa2018-07-06 10:27:41 -0600945entry. This method adds any properties associated with this, expanding the
946device tree as needed. These properties can have placeholder values which are
947set later by SetCalculatedProperties(). By that stage the size of sections
948cannot be changed (since it would cause the images to need to be repacked),
949but the correct values can be inserted.
950
9512. ProcessFdt() - process the device tree information as required by the
Simon Glass92307732018-07-06 10:27:40 -0600952particular entry. This may involve adding or deleting properties. If the
953processing is complete, this method should return True. If the processing
954cannot complete because it needs the ProcessFdt() method of another entry to
955run first, this method should return False, in which case it will be called
956again later.
957
Simon Glasse22f8fa2018-07-06 10:27:41 -06009583. GetEntryContents() - the contents of each entry are obtained, normally by
Simon Glass2574ef62016-11-25 20:15:51 -0700959reading from a file. This calls the Entry.ObtainContents() to read the
960contents. The default version of Entry.ObtainContents() calls
961Entry.GetDefaultFilename() and then reads that file. So a common mechanism
962to select a file to read is to override that function in the subclass. The
963functions must return True when they have read the contents. Binman will
964retry calling the functions a few times if False is returned, allowing
965dependencies between the contents of different entries.
966
Simon Glasse8561af2018-08-01 15:22:37 -06009674. GetEntryOffsets() - calls Entry.GetOffsets() for each entry. This can
Simon Glass2574ef62016-11-25 20:15:51 -0700968return a dict containing entries that need updating. The key should be the
Simon Glasse8561af2018-08-01 15:22:37 -0600969entry name and the value is a tuple (offset, size). This allows an entry to
970provide the offset and size for other entries. The default implementation
971of GetEntryOffsets() returns {}.
Simon Glass2574ef62016-11-25 20:15:51 -0700972
Simon Glasse8561af2018-08-01 15:22:37 -06009735. PackEntries() - calls Entry.Pack() which figures out the offset and
974size of an entry. The 'current' image offset is passed in, and the function
975returns the offset immediately after the entry being packed. The default
Simon Glass2574ef62016-11-25 20:15:51 -0700976implementation of Pack() is usually sufficient.
977
Simon Glass2d9570d2020-10-26 17:40:22 -0600978Note: for sections, this also checks that the entries do not overlap, nor extend
979outside the section. If the section does not have a defined size, the size is
980set large enough to hold all the entries.
Simon Glass2574ef62016-11-25 20:15:51 -0700981
Simon Glass2d9570d2020-10-26 17:40:22 -06009826. SetImagePos() - sets the image position of every entry. This is the absolute
Simon Glass4b05b2d2019-07-20 12:23:52 -0600983position 'image-pos', as opposed to 'offset' which is relative to the containing
984section. This must be done after all offsets are known, which is why it is quite
985late in the ordering.
986
Simon Glass2d9570d2020-10-26 17:40:22 -06009877. SetCalculatedProperties() - update any calculated properties in the device
Simon Glasse8561af2018-08-01 15:22:37 -0600988tree. This sets the correct 'offset' and 'size' vaues, for example.
Simon Glasse22f8fa2018-07-06 10:27:41 -0600989
Simon Glass2d9570d2020-10-26 17:40:22 -06009908. ProcessEntryContents() - this calls Entry.ProcessContents() on each entry.
Simon Glass2574ef62016-11-25 20:15:51 -0700991The default implementatoin does nothing. This can be overriden to adjust the
992contents of an entry in some way. For example, it would be possible to create
993an entry containing a hash of the contents of some other entries. At this
Simon Glasse61b6f62019-07-08 14:25:37 -0600994stage the offset and size of entries should not be adjusted unless absolutely
995necessary, since it requires a repack (going back to PackEntries()).
Simon Glass2574ef62016-11-25 20:15:51 -0700996
Simon Glass2d9570d2020-10-26 17:40:22 -06009979. ResetForPack() - if the ProcessEntryContents() step failed, in that an entry
Simon Glass4b05b2d2019-07-20 12:23:52 -0600998has changed its size, then there is no alternative but to go back to step 5 and
999try again, repacking the entries with the updated size. ResetForPack() removes
1000the fixed offset/size values added by binman, so that the packing can start from
1001scratch.
1002
Simon Glass2d9570d2020-10-26 17:40:22 -0600100310. WriteSymbols() - write the value of symbols into the U-Boot SPL binary.
Simon Glasse8561af2018-08-01 15:22:37 -06001004See 'Access to binman entry offsets at run time' below for a description of
Simon Glass29dae672018-07-06 10:27:39 -06001005what happens in this stage.
Simon Glassbe83bc72017-11-13 18:55:05 -07001006
Simon Glass2d9570d2020-10-26 17:40:22 -0600100711. BuildImage() - builds the image and writes it to a file
Simon Glass4b05b2d2019-07-20 12:23:52 -06001008
Simon Glass2d9570d2020-10-26 17:40:22 -0600100912. WriteMap() - writes a text file containing a map of the image. This is the
Simon Glass4b05b2d2019-07-20 12:23:52 -06001010final step.
Simon Glass2574ef62016-11-25 20:15:51 -07001011
1012
Simon Glass6244fa42019-07-08 13:18:28 -06001013External tools
1014--------------
1015
1016Binman can make use of external command-line tools to handle processing of
1017entry contents or to generate entry contents. These tools are executed using
1018the 'tools' module's Run() method. The tools generally must exist on the PATH,
1019but the --toolpath option can be used to specify additional search paths to
1020use. This option can be specified multiple times to add more than one path.
1021
Alper Nebi Yasakfb4e5382020-09-06 14:46:07 +03001022For some compile tools binman will use the versions specified by commonly-used
1023environment variables like CC and HOSTCC for the C compiler, based on whether
1024the tool's output will be used for the target or for the host machine. If those
1025aren't given, it will also try to derive target-specific versions from the
1026CROSS_COMPILE environment variable during a cross-compilation.
1027
Simon Glass6244fa42019-07-08 13:18:28 -06001028
Simon Glass52debad2016-11-25 20:15:59 -07001029Code coverage
1030-------------
1031
1032Binman is a critical tool and is designed to be very testable. Entry
Simon Glassf46732a2019-07-08 14:25:29 -06001033implementations target 100% test coverage. Run 'binman test -T' to check this.
Simon Glass52debad2016-11-25 20:15:59 -07001034
Simon Glass75ead662021-03-18 20:25:13 +13001035To enable Python test coverage on Debian-type distributions (e.g. Ubuntu)::
Simon Glass52debad2016-11-25 20:15:59 -07001036
Simon Glassa16dd6e2019-07-08 13:18:26 -06001037 $ sudo apt-get install python-coverage python3-coverage python-pytest
Simon Glass52debad2016-11-25 20:15:59 -07001038
1039
Simon Glass1aeb7512019-05-17 22:00:52 -06001040Concurrent tests
1041----------------
1042
1043Binman tries to run tests concurrently. This means that the tests make use of
1044all available CPUs to run.
1045
Simon Glass75ead662021-03-18 20:25:13 +13001046 To enable this::
Simon Glass1aeb7512019-05-17 22:00:52 -06001047
1048 $ sudo apt-get install python-subunit python3-subunit
1049
1050Use '-P 1' to disable this. It is automatically disabled when code coverage is
1051being used (-T) since they are incompatible.
1052
1053
Simon Glass1c420c92019-07-08 13:18:49 -06001054Debugging tests
1055---------------
1056
1057Sometimes when debugging tests it is useful to keep the input and output
1058directories so they can be examined later. Use -X or --test-preserve-dirs for
1059this.
1060
1061
Alper Nebi Yasakfb4e5382020-09-06 14:46:07 +03001062Running tests on non-x86 architectures
1063--------------------------------------
1064
1065Binman's tests have been written under the assumption that they'll be run on a
1066x86-like host and there hasn't been an attempt to make them portable yet.
1067However, it's possible to run the tests by cross-compiling to x86.
1068
Simon Glass75ead662021-03-18 20:25:13 +13001069To install an x86 cross-compiler on Debian-type distributions (e.g. Ubuntu)::
Alper Nebi Yasakfb4e5382020-09-06 14:46:07 +03001070
1071 $ sudo apt-get install gcc-x86-64-linux-gnu
1072
Simon Glass75ead662021-03-18 20:25:13 +13001073Then, you can run the tests under cross-compilation::
Alper Nebi Yasakfb4e5382020-09-06 14:46:07 +03001074
1075 $ CROSS_COMPILE=x86_64-linux-gnu- binman test -T
1076
1077You can also use gcc-i686-linux-gnu similar to the above.
1078
1079
Simon Glassfa888282021-03-18 20:25:14 +13001080Writing new entries and debugging
1081---------------------------------
Simon Glass2574ef62016-11-25 20:15:51 -07001082
1083The behaviour of entries is defined by the Entry class. All other entries are
1084a subclass of this. An important subclass is Entry_blob which takes binary
1085data from a file and places it in the entry. In fact most entry types are
1086subclasses of Entry_blob.
1087
1088Each entry type is a separate file in the tools/binman/etype directory. Each
1089file contains a class called Entry_<type> where <type> is the entry type.
1090New entry types can be supported by adding new files in that directory.
1091These will automatically be detected by binman when needed.
1092
1093Entry properties are documented in entry.py. The entry subclasses are free
1094to change the values of properties to support special behaviour. For example,
1095when Entry_blob loads a file, it sets content_size to the size of the file.
1096Entry classes can adjust other entries. For example, an entry that knows
Simon Glasse8561af2018-08-01 15:22:37 -06001097where other entries should be positioned can set up those entries' offsets
Simon Glass2574ef62016-11-25 20:15:51 -07001098so they don't need to be set in the binman decription. It can also adjust
1099entry contents.
1100
1101Most of the time such essoteric behaviour is not needed, but it can be
1102essential for complex images.
1103
Simon Glassade2ef62017-12-24 12:12:07 -07001104If you need to specify a particular device-tree compiler to use, you can define
1105the DTC environment variable. This can be useful when the system dtc is too
1106old.
1107
Simon Glasse64a0922018-11-06 15:21:31 -07001108To enable a full backtrace and other debugging features in binman, pass
Simon Glass75ead662021-03-18 20:25:13 +13001109BINMAN_DEBUG=1 to your build::
Simon Glasse64a0922018-11-06 15:21:31 -07001110
Bin Menga089c412019-10-02 19:07:29 -07001111 make qemu-x86_defconfig
Simon Glasse64a0922018-11-06 15:21:31 -07001112 make BINMAN_DEBUG=1
1113
Simon Glass03b1d8f2019-09-25 08:11:11 -06001114To enable verbose logging from binman, base BINMAN_VERBOSE to your build, which
Simon Glass75ead662021-03-18 20:25:13 +13001115adds a -v<level> option to the call to binman::
Simon Glass03b1d8f2019-09-25 08:11:11 -06001116
Bin Menga089c412019-10-02 19:07:29 -07001117 make qemu-x86_defconfig
Simon Glass03b1d8f2019-09-25 08:11:11 -06001118 make BINMAN_VERBOSE=5
1119
Simon Glass2574ef62016-11-25 20:15:51 -07001120
1121History / Credits
1122-----------------
1123
1124Binman takes a lot of inspiration from a Chrome OS tool called
1125'cros_bundle_firmware', which I wrote some years ago. That tool was based on
1126a reasonably simple and sound design but has expanded greatly over the
1127years. In particular its handling of x86 images is convoluted.
1128
Simon Glass1e324002018-06-01 09:38:19 -06001129Quite a few lessons have been learned which are hopefully applied here.
Simon Glass2574ef62016-11-25 20:15:51 -07001130
1131
1132Design notes
1133------------
1134
1135On the face of it, a tool to create firmware images should be fairly simple:
1136just find all the input binaries and place them at the right place in the
1137image. The difficulty comes from the wide variety of input types (simple
1138flat binaries containing code, packaged data with various headers), packing
1139requirments (alignment, spacing, device boundaries) and other required
1140features such as hierarchical images.
1141
1142The design challenge is to make it easy to create simple images, while
1143allowing the more complex cases to be supported. For example, for most
1144images we don't much care exactly where each binary ends up, so we should
1145not have to specify that unnecessarily.
1146
1147New entry types should aim to provide simple usage where possible. If new
1148core features are needed, they can be added in the Entry base class.
1149
1150
1151To do
1152-----
1153
1154Some ideas:
Simon Glass75ead662021-03-18 20:25:13 +13001155
Simon Glass2574ef62016-11-25 20:15:51 -07001156- Use of-platdata to make the information available to code that is unable
Simon Glass774b23f2021-03-18 20:25:17 +13001157 to use device tree (such as a very small SPL image). For now, limited info is
1158 available via linker symbols
Simon Glass2574ef62016-11-25 20:15:51 -07001159- Allow easy building of images by specifying just the board name
Simon Glass2574ef62016-11-25 20:15:51 -07001160- Support building an image for a board (-b) more completely, with a
1161 configurable build directory
Simon Glass8100a8e2019-07-20 12:24:02 -06001162- Detect invalid properties in nodes
1163- Sort the fdtmap by offset
Simon Glass01ab2292021-01-06 21:35:12 -07001164- Output temporary files to a different directory
Simon Glass2574ef62016-11-25 20:15:51 -07001165
1166--
1167Simon Glass <sjg@chromium.org>
11687/7/2016