feat(build): set CRYPTO_SUPPORT macro per BL

Moving the setting of CRYPTO_SUPPORT from the main Makefile to
individual component makefiles using the new build macro
make_defines for each BL-specific

feat(build): set CRYPTO_SUPPORT macro per BL

Moving the setting of CRYPTO_SUPPORT from the main Makefile to
individual component makefiles using the new build macro
make_defines for each BL-specific CPPFLAGS.

Rework romlib build command to use CRYPTO_LIB to determine mbedtls need
instead of CRYPTO_SUPPORT. If CRYPTO_SUPPORT is set for any component,
then CRYPTO_LIB will be filled, romlib can use this instead.

Add a convenience makefile macro for setting CRYPTO_SUPPORT from
component specific makefiles, have components call the macro based on
whether authenication verification (NEED_AUTH) and/or hash calculation
(NEED_HASH) is required for the specific boot stage.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I7e81fede74fb9c04694b022e8eebed460616565c

show more ...

refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

$(OBJS): %.o: %.s
...

These behave similarly, but have some subtle differences. The former
defines a rule "for any target matching %.o where there is not a more
specific rule", whereas the latter defines a rule "for these targets,
which match %.o".

Where possible it is better to use a static pattern rule as it reduces
the rule space that Make needs to search.

Change-Id: Ifba4f44bcecf4e74980c31347e192cdf1e42003e
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

feat(romlib): add PSA Crypto ROMLIB support

Adding PSA Crypto MBedTLS specific jump table to allow use of ROMLIB, to
be included when PSA_CRYPTO=1 and enabled.

Signed-off-by: Lauren Wehrmeister <la

feat(romlib): add PSA Crypto ROMLIB support

Adding PSA Crypto MBedTLS specific jump table to allow use of ROMLIB, to
be included when PSA_CRYPTO=1 and enabled.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Iff7f0e3c5cba6b89f1732f6c80d3060498e3675d

show more ...

fix(romlib): romlib build without MbedTLS

The ROMLIB build currently has a strong dependency on MbedTLS. This
patch has been introduced to remove this dependency, making it more
flexible.

Change-Id

fix(romlib): romlib build without MbedTLS

The ROMLIB build currently has a strong dependency on MbedTLS. This
patch has been introduced to remove this dependency, making it more
flexible.

Change-Id: If8c4cc7cf557687f40b235a4b8f931cfb70943fd
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

chore(romlib): remove unused jmptbl.i file

Remove the unused jmptbl.i file. The ROMLIB Makefile expects
platforms to provide the jmptbl according to their requirements.

Change-Id: I2784eaca5061aa77

chore(romlib): remove unused jmptbl.i file

Remove the unused jmptbl.i file. The ROMLIB Makefile expects
platforms to provide the jmptbl according to their requirements.

Change-Id: I2784eaca5061aa77fdd99f7b2b5ef5a1145475e9
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

build: use full paths for generated libraries

This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that a

build: use full paths for generated libraries

This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that are generated, rather than their phony target aliases
and `-lX` link flags.

The goal of this is to clean up Make's view of the dependencies between
files, avoiding phony targets (which do not honour timestamps) making
their way into intermediate dependencies.

Change-Id: I96d655fcd94dc259ffa6e8970b2be7b8c7e11123
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "fix(romlib): prevent race condition on the build directory" into integration

fix(romlib): prevent race condition on the build directory

When building with many cores (-j64), there's a good chance that the
rule to make the build directory is getting executed at the same time

fix(romlib): prevent race condition on the build directory

When building with many cores (-j64), there's a good chance that the
rule to make the build directory is getting executed at the same time as
the rule for romlib.ldflags. On my machine, the former is slower,
resulting in romlib_generator.py not being able to write the file as the
directory doesn't exist yet.

Add an explicit dependency on the build directory for the target.
This ensures that we have a build directory before we start putting
stuff in it.

Change-Id: I120b0dc66c692c759ab1046c735be405b41db87c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

build: fix grouped targets on Make <= 4.2

Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are

build: fix grouped targets on Make <= 4.2

Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are built simultaneously, rather than independently.

For example, without grouped targets the following rule may be executed
twice:

a.txt b.txt:
touch a.txt b.txt

# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# touch a.txt b.txt

In this example, both `a.txt` and `b.txt` are touched twice, when the
rule should only be executed once. Instead, this rule can use a grouped
target:

a.txt b.txt &:
touch a.txt b.txt

# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# remake: 'b.txt' is up to date.

In this case, both `a.txt` and `b.txt` are created once only, as Make
now knows that the recipe will create both files.

Note that pattern rules with multiple targets always behave this way.

Previously, we assumed that the grouped target feature was available,
but on systems still packaging Make 4.2, most prominently Ubuntu 20.04,
this is not the case. This change adds a check to ensure that we do not
use grouped targets if they are unavailable.

Change-Id: Ifd9da35421ae11468d7a25d3cbc76f6036921749
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used

build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used for the build at the initialization of the build
system.

This incurs a large cost to the build every time - for every toolchain
that has been requested by the current makefile, we try to identify each
tool in the list of known tool classes, even if that tool doesn't
actually see any use.

For the clean and check-like targets we worked around this by disabling
most of the toolchains if we detect these targets, but this is
inflexible and not very reliable, and it still means that when building
normal targets we are incurring that cost for all tools whether they are
used or not.

This change instead modifies the toolchain detection framework to only
initialize a tool for a given toolchain when it is first used. This does
mean that we can no longer warn about an incorrectly-configured
toolchain at the beginning of build system invocation, but it has the
advantage of substantially reducing build time and the complexity of
*using* the framework (at the cost of an increase in complexity in the
framework itself).

Change-Id: I7f3d06b2eb58c1b26a846791a13b0037f32c8013
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes from topic "romlib-fixes" into integration

* changes:
fix(romlib): wrap indirectly included functions
fix(arm): remove duplicate jumptable entry

fix(romlib): wrap indirectly included functions

The problem that this resolves is a bit involved; the following
must be met at the same time for some function <to_be_wrapped>:

* to_be_wrapped must

fix(romlib): wrap indirectly included functions

The problem that this resolves is a bit involved; the following
must be met at the same time for some function <to_be_wrapped>:

* to_be_wrapped must be specified as part of the romlib
* to_be_wrapped must _not_ be referenced by any translation unit
in TF-A
* to_be_wrapped must be referenced by a translation unit in a
dependent library, mbedtls for example.

Under these circumstances, to_be_wrapped will not be wrapped, and
will instead reference its original definition while simultaneously
residing in romlib.

This is a side effect of two issues with romlib prior to this patch:

1 to_be_wrapped is expected to wrap by duplicating its definition.
This causes any condition that links against both the base and
wrapper functions to be a link error (duplicate symbol definition).
2 to_be_wrapped is in its own translation unit
This causes the wrappers to be used by TF-A in an as needed.

The duplicate function definitions can be worked around using the
linker's `--wrap` flag, which redirects all references to a symbol
to resolve to `__wrap_<symbol>` and the original symbol to be
available as `__real_<symbol>`. Most of the changes handle creating
this arguments and passing them to the linker.

Further, once you use the linker's wrap, you will encounter another
issue: if TF-A does not use a function, its wrapper is not present.
This causes link issues when a library and not TF-A uses the wrapper.
Note that this issue would have been resolved previously by ignoring
the wrapper and using the base definition.

This further issue is worked around by concatenating the assembly for
all of the wrappers into a single translation unit. It's possible to
work around this issue in a few other ways, including reordering the
libraries passed to the linker to place libwrapper.a last or grouping
the libraries so that symbols from later libraries may be resolved
with prior libraries.

I chose the translation unit concatenation approach as it revealed
that a jumptable has duplicate symbols within it.

Change-Id: Ie57b5ae69bde2fc8705bdc7a93fae3ddb5341ed9
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>

show more ...

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We cur

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We currently use several macros to generate rules to create directories
upon dependence, which is a significant amount of code and a lot of
redundancy. The rule introduced by this change represents a catch-all:
any rule dependency on a path ending in a forward slash is automatically
created.

Now, rules can rely on an unordered dependency (`|`) on `$$(@D)/` which,
when secondary expansion is enabled, expands to the directory of the
target being built, e.g.:

build/main.o: main.c | $$(@D)/ # automatically creates `build/`

Change-Id: I7e554efa2ac850e779bb302fd9c7fbb239886c9f
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...