+# SPDX-License-Identifier: GPL-2.0+
# Copyright (c) 2016 Google, Inc
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
Introduction
------------
Binman has a few other options which you can see by running 'binman -h'.
+Enabling binman for a board
+---------------------------
+
+At present binman is invoked from a rule in the main Makefile. Typically you
+will have a rule like:
+
+ifneq ($(CONFIG_ARCH_<something>),)
+u-boot-<your_suffix>.bin: <input_file_1> <input_file_2> checkbinman FORCE
+ $(call if_changed,binman)
+endif
+
+This assumes that u-boot-<your_suffix>.bin is a target, and is the final file
+that you need to produce. You can make it a target by adding it to ALL-y
+either in the main Makefile or in a config.mk file in your arch subdirectory.
+
+Once binman is executed it will pick up its instructions from a device-tree
+file, typically <soc>-u-boot.dtsi, where <soc> is your CONFIG_SYS_SOC value.
+You can use other, more specific CONFIG options - see 'Automatic .dtsi
+inclusion' below.
+
+
Image description format
------------------------
align-end:
This sets the alignment of the end of an entry. Some entries require
that they end on an alignment boundary, regardless of where they
- start. If 'align-end' is not provided, no alignment is performed.
-
- Note: This is not yet implemented in binman.
+ start. This does not move the start of the entry, so the contents of
+ the entry will still start at the beginning. But there may be padding
+ at the end. If 'align-end' is not provided, no alignment is performed.
filename:
For 'blob' types this provides the filename containing the binary to
possible to use any name, and then add (for example) 'type = "u-boot"'
to specify the type.
+pos-unset:
+ Indicates that the position of this entry should not be set by placing
+ it immediately after the entry before. Instead, is set by another
+ entry which knows where this entry should go. When this boolean
+ property is present, binman will give an error if another entry does
+ not set the position (with the GetPositions() method).
+
The attributes supported for images are described below. Several are similar
to those for entries.
Examples of the above options can be found in the tests. See the
tools/binman/test directory.
+It is possible to have the same binary appear multiple times in the image,
+either by using a unit number suffix (u-boot@0, u-boot@1) or by using a
+different name for each and specifying the type with the 'type' attribute.
+
+
+Sections and hiearchical images
+-------------------------------
+
+Sometimes it is convenient to split an image into several pieces, each of which
+contains its own set of binaries. An example is a flash device where part of
+the image is read-only and part is read-write. We can set up sections for each
+of these, and place binaries in them independently. The image is still produced
+as a single output file.
+
+This feature provides a way of creating hierarchical images. For example here
+is an example image with two copies of U-Boot. One is read-only (ro), intended
+to be written only in the factory. Another is read-write (rw), so that it can be
+upgraded in the field. The sizes are fixed so that the ro/rw boundary is known
+and can be programmed:
+
+ binman {
+ section@0 {
+ read-only;
+ name-prefix = "ro-";
+ size = <0x100000>;
+ u-boot {
+ };
+ };
+ section@1 {
+ name-prefix = "rw-";
+ size = <0x100000>;
+ u-boot {
+ };
+ };
+ };
+
+This image could be placed into a SPI flash chip, with the protection boundary
+set at 1MB.
+
+A few special properties are provided for sections:
+
+read-only:
+ Indicates that this section is read-only. This has no impact on binman's
+ operation, but his property can be read at run time.
+
+name-prefix:
+ This string is prepended to all the names of the binaries in the
+ section. In the example above, the 'u-boot' binaries which actually be
+ renamed to 'ro-u-boot' and 'rw-u-boot'. This can be useful to
+ distinguish binaries with otherwise identical names.
+
Special properties
------------------
Image creation proceeds in the following order, for each entry in the image.
-1. GetEntryContents() - the contents of each entry are obtained, normally by
+1. AddMissingProperties() - binman can add calculated values to the device
+tree as part of its processing, for example the position and size of each
+entry. This method adds any properties associated with this, expanding the
+device tree as needed. These properties can have placeholder values which are
+set later by SetCalculatedProperties(). By that stage the size of sections
+cannot be changed (since it would cause the images to need to be repacked),
+but the correct values can be inserted.
+
+2. ProcessFdt() - process the device tree information as required by the
+particular entry. This may involve adding or deleting properties. If the
+processing is complete, this method should return True. If the processing
+cannot complete because it needs the ProcessFdt() method of another entry to
+run first, this method should return False, in which case it will be called
+again later.
+
+3. GetEntryContents() - the contents of each entry are obtained, normally by
reading from a file. This calls the Entry.ObtainContents() to read the
contents. The default version of Entry.ObtainContents() calls
Entry.GetDefaultFilename() and then reads that file. So a common mechanism
retry calling the functions a few times if False is returned, allowing
dependencies between the contents of different entries.
-2. GetEntryPositions() - calls Entry.GetPositions() for each entry. This can
+4. GetEntryPositions() - calls Entry.GetPositions() for each entry. This can
return a dict containing entries that need updating. The key should be the
entry name and the value is a tuple (pos, size). This allows an entry to
provide the position and size for other entries. The default implementation
of GetEntryPositions() returns {}.
-3. PackEntries() - calls Entry.Pack() which figures out the position and
+5. PackEntries() - calls Entry.Pack() which figures out the position and
size of an entry. The 'current' image position is passed in, and the function
returns the position immediately after the entry being packed. The default
implementation of Pack() is usually sufficient.
-4. CheckSize() - checks that the contents of all the entries fits within
+6. CheckSize() - checks that the contents of all the entries fits within
the image size. If the image does not have a defined size, the size is set
large enough to hold all the entries.
-5. CheckEntries() - checks that the entries do not overlap, nor extend
+7. CheckEntries() - checks that the entries do not overlap, nor extend
outside the image.
-6. ProcessEntryContents() - this calls Entry.ProcessContents() on each entry.
+8. SetCalculatedProperties() - update any calculated properties in the device
+tree. This sets the correct 'pos' and 'size' vaues, for example.
+
+9. ProcessEntryContents() - this calls Entry.ProcessContents() on each entry.
The default implementatoin does nothing. This can be overriden to adjust the
contents of an entry in some way. For example, it would be possible to create
an entry containing a hash of the contents of some other entries. At this
stage the position and size of entries should not be adjusted.
-7. BuildImage() - builds the image and writes it to a file. This is the final
+10. WriteSymbols() - write the value of symbols into the U-Boot SPL binary.
+See 'Access to binman entry positions at run time' below for a description of
+what happens in this stage.
+
+11. BuildImage() - builds the image and writes it to a file. This is the final
step.
the 'warning' line in scripts/Makefile.lib to see what it has found:
# Uncomment for debugging
- # $(warning binman_dtsi_options: $(binman_dtsi_options))
+ # This shows all the files that were considered and the one that we chose.
+ # u_boot_dtsi_options_debug = $(u_boot_dtsi_options_raw)
+
+
+Access to binman entry positions at run time
+--------------------------------------------
+
+Binman assembles images and determines where each entry is placed in the image.
+This information may be useful to U-Boot at run time. For example, in SPL it
+is useful to be able to find the location of U-Boot so that it can be executed
+when SPL is finished.
+
+Binman allows you to declare symbols in the SPL image which are filled in
+with their correct values during the build. For example:
+
+ binman_sym_declare(ulong, u_boot_any, pos);
+
+declares a ulong value which will be assigned to the position of any U-Boot
+image (u-boot.bin, u-boot.img, u-boot-nodtb.bin) that is present in the image.
+You can access this value with something like:
+
+ ulong u_boot_pos = binman_sym(ulong, u_boot_any, pos);
+
+Thus u_boot_pos will be set to the position of U-Boot in memory, assuming that
+the whole image has been loaded, or is available in flash. You can then jump to
+that address to start U-Boot.
+
+At present this feature is only supported in SPL. In principle it is possible
+to fill in such symbols in U-Boot proper, as well.
+
+
+Map files
+---------
+
+The -m option causes binman to output a .map file for each image that it
+generates. This shows the position and size of each entry. For example:
+
+ Position Size Name
+ 00000000 00000010 section@0
+ 00000000 00000004 u-boot
+ 00000010 00000010 section@1
+ 00000000 00000004 u-boot
+
+This shows a hierarchical image with two sections, each with a single entry. The
+positions of the sections are absolute hex byte offsets within the image. The
+positions of the entries are relative to their respective sections. The size of
+each entry is also shown, in bytes (hex). The indentation shows the entries
+nested inside their sections.
Code coverage
To enable Python test coverage on Debian-type distributions (e.g. Ubuntu):
- $ sudo apt-get install python-pip python-pytest
- $ sudo pip install coverage
+ $ sudo apt-get install python-coverage python-pytest
Advanced Features / Technical docs
Most of the time such essoteric behaviour is not needed, but it can be
essential for complex images.
+If you need to specify a particular device-tree compiler to use, you can define
+the DTC environment variable. This can be useful when the system dtc is too
+old.
+
History / Credits
-----------------
a reasonably simple and sound design but has expanded greatly over the
years. In particular its handling of x86 images is convoluted.
-Quite a few lessons have been learned which are hopefully be applied here.
+Quite a few lessons have been learned which are hopefully applied here.
Design notes
Some ideas:
- Fill out the device tree to include the final position and size of each
- entry (since the input file may not always specify these)
+ entry (since the input file may not always specify these). See also
+ 'Access to binman entry positions at run time' above
- Use of-platdata to make the information available to code that is unable
to use device tree (such as a very small SPL image)
-- Write an image map to a text file
- Allow easy building of images by specifying just the board name
- Produce a full Python binding for libfdt (for upstream)
- Add an option to decode an image into the constituent binaries
-- Suppoort hierarchical images (packing of binaries into another binary
- which is then placed in the image)
- Support building an image for a board (-b) more completely, with a
configurable build directory
- Consider making binman work with buildman, although if it is used in the
Makefile, this will be automatic
-- Implement align-end
--
Simon Glass <sjg@chromium.org>
projects / u-boot / blobdiff