It is quite unlikely that this number will ever change and, if it
does need to change, we should have a good reason to do so. It
seems that this comment is now redundant.
Change-Id: I409c764080748e338e9bc5606bbdcc475213fb6e
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
Commit 033648652f ("Make TF UUID RFC 4122 compliant") changed the scanf
parsing string to handle endianness correctly.
However that changed the number of items sscanf handles, without
adjusting the sanity check just below.
Increase the expected return value from 11 to 16 to let fiptool handle
UUIDs given as blob parameters correctly again.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
All identifiers, regardless of use, that start with two underscores are
reserved. This means they can't be used in header guards.
The style that this project is now to use the full name of the file in
capital letters followed by 'H'. For example, for a file called
"uart_example.h", the header guard is UART_EXAMPLE_H.
The exceptions are files that are imported from other projects:
- CryptoCell driver
- dt-bindings folders
- zlib headers
Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
HOSTCC should be used in any of the tools inside the tools/ directory
instead of CC. That way it is possible to override both values from the
command line when building the Trusted Firmware and the tools at the
same time. Also, use HOSTCCFLAGS instead of CFLAGS.
Also, instead of printing the strings CC and LD in the console during
the compilation of the tools, HOSTCC and HOSTLD have to be used for
clarity. This is how it is done in other projects like U-Boot or Linux.
Change-Id: Icd6f74c31eb74cdd1c353583399ab19e173e293e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
A compatibility script has been provided for about 2 years. Users should
have migrated to fiptool by now so remove the compat script.
Change-Id: I643e0c40a9e3fb428bad3be04a82cb431aad74dc
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
RFC4122 defines that fields are stored in network order (big endian),
but TF-A stores them in machine order (little endian by default in TF-A).
We cannot change the future UUIDs that are already generated, but we can store
all the bytes using arrays and modify fiptool to generate the UUIDs with
the correct byte order.
Change-Id: I97be2d3168d91f4dee7ccfafc533ea55ff33e46f
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
This patch implements support for adding dynamic configurations for
BL31 (soc_fw_config), BL32 (tos_fw_config) and BL33 (nt_fw_config). The
necessary cert tool support and changes to default chain of trust are made
for these configs.
Change-Id: I25f266277b5b5501a196d2f2f79639d838794518
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Free desc->image->buffer before freeing desc->image. We make sure that
the desc->image is non-null before attempting this.
Change-Id: I35c5674629a41d7cf1a78b7b41ca4b930d0fb688
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
This patch updates the `fiptool` and `cert_create` for the
`hw_config` and `tb_fw_config` dynamic configuration files.
The necessary UUIDs and OIDs are assigned to these files and
the `cert_create` is updated to generate appropriate hashes
and include them in the "Trusted Boot FW Certificate". The
`fiptool` is updated to allow the configs to be specified
via cmdline and included in the generated FIP.
Change-Id: I940e751a49621ae681d14e162aa1f5697eb0cb15
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Commit 880b9e8b4c (Add padding at the end
of the last entry) added code using toc_entry pointer, whose memory is
already freed via variable buf. This causes enormous padding on openSUSE.
Free the memory buffer only after padding is done.
Signed-off-by: Andreas Färber <afaerber@suse.de>
This patch adds padding bytes at the end of the last image in the
fip to be able to transfer by DMA the last image.
Change-Id: I8c6f07dee389cb3d1dc919936d9d52841d7e5723
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
Signed-off-by: David Cunado <david.cunado@arm.com>
Updates are required to enable the fiptool utility to be built on a
Windows platform. This change modifies the source files to enable
building with Visual Studio (detected via preprocessor settings).
The primary changes are:
1. Provide an implementation of the getopt_long function. This does
not exist in the Visual Studio CRT libraries because Windows
commands normally use '/' not '-' as an option indicator.
2. Redirect some function names to match those supported by the
Visual Studio libraries (when building with Visual Studio).
2. Modify a structure name (stat) to match that provided
by the Visual Studio libraries (_stat).
Note - this change does not provide makefile updates. It only modifies
the sources to enable the fiptool to be built from a Visual
Studio project. In normal use the presence of FIPTOOL.EXE is
enough to satisfy the make requirements. A makefile change may
be derived from the Visual Studio command line information at
some point in the future.
Change-Id: I3ade77ea140246af3c030920b3f97c070087f111
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
In order to compile the source of Fiptool using Visual Studio a number
of adjustments are required to the source. This commit modifies the
source with changes that will be required, but makes no functional
modification. The intent is to allow confirmation that the GCC build
is unaffected.
Change-Id: I4055bd941c646dd0a1aa2e24b940a1db3bf629ce
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Unix does not distinguish binary and text modes.
On Windows the 'b' flag (e.g. "rb" instead of "r") is used to
indicate that files should be opened in binary mode.
This has no impact on Unix, but is needed on Windows to avoid
end-of-line issues.
Change-Id: I69424c55735d5d563d36c50bedd6357b8e05137e
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Since Trusted OS firmware may have extra images, need to
assign new uuid and image id for them.
The TBBR chain of trust has been extended to add support
for the new images within the existing Trusted OS firmware
content certificate.
Change-Id: I678dac7ba1137e85c5779b05e0c4331134c10e06
Signed-off-by: Summer Qin <summer.qin@arm.com>
This fix modifies the order of system includes to meet the ARM TF coding
standard whilst retaining header groupings.
Change-Id: Ib91968f8e2cac9e96033d73d3ad9d0a2ae228b13
Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>
All local headers in tools/fiptool are included by #include "..."
notation instead of #include <...>, so there is no need to add the
local directory to to the header search path.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This fix modifies the order of system includes to meet the ARM TF coding
standard. There are some exceptions in order to retain header groupings,
minimise changes to imported headers, and where there are headers within
the #if and #ifndef statements.
Change-Id: I65085a142ba6a83792b26efb47df1329153f1624
Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>
When V is set from the command line, the value is passed to the tools'
Makefiles as well.
Change-Id: I91a1f66de5c1ae6f36b6c9f0a9bd550d4a30f092
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Tools are built using the compiler specified in `HOSTCC` instead of
reusing the `CC` variable. By default, gcc is used.
Change-Id: I83636a375c61f4804b4e80784db9d061fe20af87
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Some header files need to be shared between TF and host programs.
For fiptool, two headers are copied to the tools/fiptool directory,
but it looks clumsy.
This commit introduces a new directory, include/tools_share, which
collects headers that should be shared between TF and host programs.
This will clarify the interface exposed to host tools. We should
add new headers to this directory only when we really need to do so.
For clarification, I inserted a blank line between headers from the
include/ directory (#include <...>) and ones from a local directory
(#include "..." ).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.
NOTE: Files that have been imported by FreeBSD have not been modified.
[0]: https://spdx.org/
Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
An alignment value of 0x4000 is much easier to type than 16384,
so enhance get_image_align() to recognize a 0x prefix for hexadecimals.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Currently, fiptool uses two linked lists. One to chain together all
the images and one for all the image descriptors. Initially this was
done because not all images had a corresponding image descriptor.
This was the case for unknown images which existed in the FIP but
there was no descriptor in the builtin table for them. When support
for the --blob option came in, we started building descriptors for the
unknown images on the fly. As a result every image now has a
corresponding image descriptor and therefore it is no longer necessary
to keep track of them separately.
To simplify the design, maintain only a single linked list of image
descriptors. An image descriptor contains a pointer to the
corresponding image. If the pointer is NULL, then the descriptor is
skipped in all the operations. This approach simplifies the traversal
code and avoids redundant lookups.
The linked list of image descriptors is populated based on the
`toc_entries` array. This means that the order of the images in the
FIP file remains the same across add/remove or create/update
operations. This is true for all standard images (those specified in
`toc_entries`) but not for those specified via the --blob option.
Change-Id: Ic29a263c86c8f1efdad322b430368c7623782e2d
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
We should follow the Linux coding style, which is clearly stated in
the docs/user-guide.mk:
When making changes to the source for submission to the project,
the source must be in compliance with the Linux style guide
and Documentation/process/coding-style.rst of Linux Kernel says:
The limit on the length of lines is 80 columns and this is a
strongly preferred limit.
[ snip ]
However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them.
The strings for printf() are user-visible, and can exceed the 80
column limit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The strings in usage functions are sent to stdout by printf(),
but some new lines are sent to stderr by fputc(..., stderr).
This inconsistency will break the usage format when users re-direct
stdout or stderr. Just use printf() for consistency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The current fiptool packs all the images without any padding between
them. So, the offset to each image has no alignment. This is not
efficient, for example, when the FIP is read from a block-oriented
device.
For example, (e)MMC is accessed by block-addressing. The block size
is 512 byte. So, the best case is each image is aligned by 512 byte
since the DMA engine can transfer the whole of the image to its load
address directly. The worst case is the offset does not have even
DMA-capable alignment (this is where we stand now). In this case,
we need to transfer every block to a bounce buffer, then do memcpy()
from the bounce buffer to our final destination. At least, this
should work with the abstraction by the block I/O layer, but the
CPU-intervention for the whole data transfer makes it really slow.
This commit adds a new option --align to the fiptool. This option,
if given, requests the tool to align each component in the FIP file
by the specified byte. Also, add a new Make option FIP_ALIGN for
easier access to this feature; users can give something like
FIP_ALIGN=512 from the command line, or add "FIP_ALIGN := 512" to
their platform.mk file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The struct image has "uuid" and "size" to memorize the field values
they had in the TOC entry. So, parse_fip() copies them from struct
fip_toc_entry to struct image, then pack_images() copies them back
to struct fip_toc_entry.
The next commit (support --align option) will require to save the
"offset" field as well. This makes me realize that struct image
can embed struct fip_toc_entry.
This commit will allow the "flags" field to persevere the "update"
command. At this moment, the "flags" is not used in a useful way.
(Yet, platforms can save their own parameters in the flags field.)
It makes sense to save it unless users explicitly replace the image.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We need not handle the image_head as a special case. Just use
a double-pointer to simplify the traverse.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
lookup_image(_desc)_from_uuid() traverses the linked list, so it
is not efficient. We just want to make sure *p points to NULL here.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Commit e0f083a09b ("fiptool: Prepare ground for expanding the set
of images at runtime") introduced another side effect; the "update"
command now changes the image order in the FIP.
Let's say you have an FIP with BL2, BL31, BL32, BL33. If you update
for example, BL32 with the "update" command, you will get a new FIP
with BL2, BL31, BL33, BL32, in this order.
It happens like this; remove_image() removes the old image from the
linked list, add_image() adds the new image at the tail of the list,
then images are packed in the new order. Prior to that commit,
images were updated by replace_image(), but it was deleted by the
re-work. Revive replace_image() that is re-implemented to work with
the linked list.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The conditional
if (desc != NULL)
...
is always true here because we assert it 6 lines above:
assert(desc != NULL);
Remove the if-conditional and concatenate the printf() calls.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This line should check the existence of the input file, but it is
actually checking the output file. When -o option is given to the
"update" command, the outfile is unlikely to exist, then parse_fip()
is skipped and an empty FIP file is output. This is wrong behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The "make fip" shows the content of the generated FIP at the end of
the build. (This is shown by "fiptool info" command.)
Prior to commit e0f083a09b ("fiptool: Prepare ground for expanding
the set of images at runtime"), the last part of the build log of
make CROSS_COMPILE=aarch64-linux-gnu- BL33=../u-boot/u-boot.bin fip
was like follows:
Trusted Boot Firmware BL2: offset=0xB0, size=0x4188, cmdline="--tb-fw"
EL3 Runtime Firmware BL31: offset=0x4238, size=0x6090, cmdline="--soc-fw"
Non-Trusted Firmware BL33: offset=0xA2C8, size=0x58B51, cmdline="--nt-fw"
With that commit, now it is displayed like follows:
Non-Trusted Firmware BL33: offset=0xB0, size=0x58B51, cmdline="--nt-fw"
EL3 Runtime Firmware BL31: offset=0x58C01, size=0x6090, cmdline="--soc-fw"
Trusted Boot Firmware BL2: offset=0x5EC91, size=0x4188, cmdline="--tb-fw"
You will notice two differences:
- the contents are displayed in BL33, BL31, BL2 order
- the offset values are wrong
The latter is more serious, and means "fiptool info" is broken.
Another interesting change is "fiptool update" every time reverses
the image order. For example, if you input FIP with BL2, BL31, BL33
in this order, the command will pack BL33, BL31, BL2 into FIP, in
this order. Of course, the order of components is not a big deal
except that users will have poor impression about this.
The root cause is in the implementation of add_image(); the
image_head points to the last added image. For example, if you call
add_image() for BL2, BL31, BL33 in this order, the resulted image
chain is:
image_head -> BL33 -> BL31 -> BL2
Then, they are processed from the image_head in "for" loops:
for (image = image_head; image != NULL; image = image->next) {
This means images are handled in Last-In First-Out manner.
Interestingly, "fiptool create" is still correct because
add_image_desc() also reverses the descriptor order and the command
works as before due to the double reverse.
The implementation of add_image() is efficient, but it made the
situation too complicated.
Let's make image_head point to the first added image. This will
add_image() inefficient because every call of add_image() follows
the ->next chain to get the tail. We can solve it by adopting a
nicer linked list structure, but I am not doing as far as that
because we handle only limited number of images anyway.
Do likewise for add_image_desc().
Fixes: e0f083a09b ("fiptool: Prepare ground for expanding the set of images at runtime")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We often want to zero out allocated memory.
My main motivation for this commit is to set image::next and
image_desc::next to NULL automatically in the next commit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
An image descriptor contains an action and an argument. The action
indicates the intended operation, as requested by the user. It can be
pack, unpack or remove. Factor out setting those fields to a separate
function to minimize code duplication across the various commands that
modify these fields.
Change-Id: I1682958e8e83c4884e435cff6d0833c67726461f
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Previously, fiptool only understood a fixed set of images as
specified in tbbr_config.c. It preserved unknown images during
the update, unpack and remove operations but it was not possible to
explicitly refer to one of those unknown images.
Add a new --blob option to create/update/unpack/remove images that
are not known at compile time. This is accomplished by specifying
the UUID and filename pair as shown below:
$ ./fiptool create --blob uuid=01234567-89ab-cdef-0123-456789abcdef,file=foo.bin fip.bin
$ ./fiptool info fip.bin
01234567-89ab-cdef-0123-456789abcdef: offset=0x60, size=0x1AA68
FixesARM-software/tf-issues#420
Change-Id: Iaac2504b9a4252289c09e73d29645cbe240f3a82
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
To allow operating on images with unknown UUIDs, fiptool needs to
be able to track an arbitrary amount of images and not be limited
to the set of images described by the builtin table.
Convert the table to a list to accommodate this scenario.
Change-Id: I0e6d738eece7795d74fc72d165a3098f223d4414
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Additionally, remove the -o option for the create command
as it is not supported.
Change-Id: I27993a6fc5e3b0b9710e2ec5322e4296bc87d0df
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
The `toc_entry` and `image` data structures had a cyclic
relationship. This patch removes the explicit dependencies and introduces
functions to link them via the UUID.
This change highlights the intent of the code better and makes it more
flexible for future enhancements.
Change-Id: I0c3dd7bfda2a631a3827c8ba4831849c500affe9
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Paul Beesley
Andre Przywara
Antonio Nino Diaz
dp-arm
Roberto Vargas
Soby Mathew
Jonathan Wright
Andreas Färber
Evan Lloyd
Summer Qin
Isla Mitchell
Masahiro Yamada