Many of the existing blobs rely on external binaries which may not be
available. Move them over to use blob_ext to indicate this.
Unfortunately cros-ec-rw cannot use this class because it inherits
another. So set the 'external' value for that class.
While we are here, drop the import of Entry since it is not used (and
pylint3 complains).
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to distinguish between ordinary blobs such as
u-boot.bin and external blobs that cannot be build by the U-Boot build
system. If the external blobs are not available for some reason, then we
know that a value image cannot be built.
Introduce a new 'blob-ext' entry type for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is easier and less error-prone to use super() when the parent type is
needed. Update binman to remove the type names.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As a first step to integrating mkimage into binman, add a new entry type
that feeds data into mkimage for processing and incorporates that output
into the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
FIT (Flat Image Tree) is the main image format used by U-Boot. In some
cases scripts are used to create FITs within the U-Boot build system. This
is not ideal for various reasons:
- Each architecture has its own slightly different script
- There are no tests
- Some are written in shell, some in Python
To help address this, add support for FIT generation to binman. This works
by putting the FIT source directly in the binman definition, with the
ability to adjust parameters, etc. The contents of each FIT image come
from sub-entries of the image, as is normal with binman.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some binary blobs unfortunately obtain their position in the image from
other binary blobs, such as Intel's 'descriptor'. In this case we cannot
rely on packing to work. It is not possible to produce a valid image in
any case, due to the missing blobs.
Allow zero-length overlaps so that this does not cause any problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes it is useful to build an image even though external binaries are
not present. This allows the build system to continue to function without
these files, albeit not producing valid images.
U-Boot does with with ATF (ARM Trusted Firmware) today.
Add a new flag to binman to request this behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Many of the existing blobs rely on external binaries which may not be
available. Move them over to use blob_ext to indicate this.
Unfortunately cros-ec-rw cannot use this class because it inherits
another. So set the 'external' value for that class.
While we are here, drop the import of Entry since it is not used (and
pylint3 complains).
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to distinguish between ordinary blobs such as
u-boot.bin and external blobs that cannot be build by the U-Boot build
system. If the external blobs are not available for some reason, then we
know that a value image cannot be built.
Introduce a new 'blob-ext' entry type for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is easier and less error-prone to use super() when the parent type is
needed. Update binman to remove the type names.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As a first step to integrating mkimage into binman, add a new entry type
that feeds data into mkimage for processing and incorporates that output
into the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present patman sets the python path on startup so that it can access
the libraries it needs. If we convert to use absolute imports this is not
necessary.
Move patman to use absolute imports. This requires changes in tools which
use the patman libraries (which is most of them).
Signed-off-by: Simon Glass <sjg@chromium.org>
At present binman sets the python path on startup so that it can access
the libraries it needs. If we convert to use absolute imports this is not
necessary.
Move binman to use absolute imports. This enables removable of the path
adjusting in Entry also.
Signed-off-by: Simon Glass <sjg@chromium.org>
The suffix should be ".bin" instead of ".dtb" .
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A recent change adjusted the symbol calculation to work on x86 but broke
it for Tegra. In fact this is because they have different needs.
On x86 devices the code is linked to a ROM address and the end-at-4gb
property is used for the image. In this case there is no need to add the
base address of the image, since the base address is already built into
the offset and image-pos properties.
On other devices we must add the base address since the offsets start at
zero.
In addition the base address is currently added to the 'offset' and 'size'
values. It should in fact only be added to 'image-pos', since 'offset' is
relative to its parent and 'size' is not actually an address. This code
should have been adjusted when support for 'image-pos' and 'size' was
added, but it was not.
To correct these problems:
- move the code that handles adding the base address to section.py, which
can check the end-at-4gb property and which property
(offset/size/image-pos) is being read
- add the base address only when needed (only for image-pos and not if the
image uses end-at-4gb)
- add a note to the documentation
- add a separate test to cover x86 behaviour
Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base)
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
This entry is used to hold an Intel FSP-T (Firmware Support Package
Temp-RAM init) binary. Add support for this in binman.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This entry is used to hold an Intel FSP-S (Firmware Support Package
Silicon init) binary. Add support for this in binman.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Intel IFWI (Integrated Firmware Image) is effectively a section with
other entries inside it. Support writing symbol information into entries
within it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for the ProcessContents() method in this entry so that it is
possible to support entries which change after initial creation.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this class reads its entries in the constructor. This is not
how things should be done now. Update it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Intel FSP supports initialising memory early during boot using a binary
blob called 'fspm'. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to access the size of an image in SPL, with
something like:
binman_sym_declare(unsigned long, u_boot_any, size);
...
ulong u_boot_size = binman_sym(ulong, u_boot_any, size);
Add support for this and update the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Entries which include a section and need to obtain its contents call
GetData(), as with any other entry. But the current implementation of this
method in entry_Section requires the size of the section to be known. If
it is unknown, an error is produced, since size is None:
TypeError: can't multiply sequence by non-int of type 'NoneType'
There is no need to know the size in advance since the code can be
adjusted to build up the section piece by piece, instead of patching each
entry into an existing bytearray.
Update the code to handle this and add a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we only support symbols inside binaries which are at the top
level of an image. This restrictions seems unreasonable since more complex
images may want to group binaries within different sections.
Relax the restriction, adding a new _SetupTplElf() helper function.
Also fix a typo in the comment for testTpl().
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this entry does not work correctly when a FIT image is used as
the input. It updates the FIT instead of the output image. The test passed
because the FIT image happened to have the right data already.
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
A Firmware Image Table (FIT) is a data structure defined by Intel which
contains information about various things needed by the SoC, such as
microcode.
Add support for this entry as well as the pointer to it. The contents of
FIT are fixed at present. Future work is needed to support adding
microcode, etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present these two sections of code are linked together into a single
2KB chunk in a single file. Some Intel SoCs like to have a FIT (Firmware
Interface Table) in the ROM and the pointer for this needs to go at
0xffffffc0 which is in the middle of these two sections.
Make use of the new 'reset' entry and change the existing 16-bit entry to
include just the 16-bit data.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present binman has a single entry type for the 16-bit code code needed
to start up an x86 processor. This entry is intended to include both the
reset vector itself as well as the code to move to 32-bit mode.
However this is not very flexible since in some cases other data needs to
be included at the top of the SPI flash, in between these two pieces. For
example Intel requires that a FIT (Firmware Image Table) pointer be placed
0x40 bytes before the end of the ROM.
To deal with this, add a new reset entry for just the reset vector. A
subsequent change will adjust the existing 'start16' entry.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the Intel IFWI entry uses 'replace' without the 'ifwi-' prefix.
This is a fairly generic name which might conflict with the main Entry
base class at some point, if more features are added. Add a prefix.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present if libfdt is not available binman can't do anything much.
Improve the situation a little.
Ideally there should be a test to cover this, but I'm not quite sure how
to fake this.
Signed-off-by: Simon Glass <sjg@chromium.org>
(fixed up missing ReadChildData() enty test)
The image-header currently sets it offset assuming that skip-at-start is
zero. This does not work on x86 where offsets end at 4GB. Add in this
value so that the offset is correct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Some x86 sections have special offsets which currently result in empty
data being returned from the 'extract' command. Fix this by taking account
of the skip-at-start property.
Add a little more debugging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Since the state module holds references to all the device trees used by
binman, it must be updated when the device trees are updated. Add support
for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present binman cannot replace data within a CBFS since it does not
allow rewriting of the files in that CBFS. Implement this by using the
new WriteData() method to handle the case.
Add a header to compressed data so that the amount of compressed data can
be determined without reference to the size of the containing entry. This
allows the entry to be larger that the contents, without causing errors in
decompression. This is necessary to cope with a compressed device tree
being updated in such a way that it shrinks after the entry size is
already set (an obscure case). It is not used with CBFS since it has its
own metadata for this. Increase the number of passes allowed to resolve
the position of entries, to handle this case.
Add a test for this new logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this method assumes that the parent section does not need
to recalculate its position or adjust any metadata it may contain. But
when the entry changes size this may not be true. Also if the parent
section is more than just a container (e.g. it is a CBFS) then the
section may need to regenerate its output.
Add a new WriteChildData() method to sections and call this from the
WriteData() method, to handle this situation.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we simply extract the data directly from entries using the
image_pos information. This happens to work on current entry types, but
cannot work if the entry type encodes the data in some way. Update the
ReadData() method to provide the data by calling a new ReadChildData()
method in the parent. This allows the entry_Section class, or possibly
any other container class, to return the correct data in all cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Intel descriptor must always appear at the start of an (x86) image,
so it is supposed to position itself there always. However there is no
explicit test for this. Add one and fix a bug introduced by the recent
change to adjust Entry to read the node in a separate call.
Signed-off-by: Simon Glass <sjg@chromium.org>
The FMAP is not intended to show the files inside a CBFS. The FMAP can be
used to locate the CBFS itself, but then the CBFS must be read to find out
what is in it.
Update the FMAP to work this way and add some debugging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes entries shrink after packing. As a start towards supporting
this, update the _testing entry to handle the test case.
Signed-off-by: Simon Glass <sjg@chromium.org>
