Merge changes from topic "comp_build_macro" into integration

* changes:
feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT
feat(build): set CRYPTO_SUPPORT macro per BL
feat(build): create defi

Merge changes from topic "comp_build_macro" into integration

* changes:
feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT
feat(build): set CRYPTO_SUPPORT macro per BL
feat(build): create define macro to be used by BL

show more ...

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 ...

Merge "refactor(build): avoid implicit pattern rules" into integration

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 ...

Merge "feat(romlib): add PSA Crypto ROMLIB support" into integration

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 ...

Merge "fix(romlib): romlib build without MbedTLS" into integration

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 ...

Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated li

Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated libraries

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

Merge "build: fix grouped targets on Make <= 4.2" 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 ...

Merge changes from topic "dynamic-toolchain" into integration

* changes:
build: allow multiple toolchain defaults
build: determine toolchain tools dynamically

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 ...

Merge "build: consolidate directory creation rules" into integration

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 ...

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing facilities to utilities

show more ...

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables are boolean values determining
whether the build system has been configured to run silently or
verbosely respectively (i.e. with `--silent` or `V=1`).

These two modes cannot be used together - if `silent` is truthy then
`verbose` is always falsy. As such:

make --silent V=1

... results in a silent build.

In addition to these boolean variables, we also introduce two new
variables - `s` and `q` - for use in rule recipes to conditionally
suppress the output of commands.

When building silently, `s` expands to a value which disables the
command that follows, and `q` expands to a value which supppresses
echoing of the command:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed but not echoed'

When building verbosely, `s` expands to a value which disables the
command that follows, and `q` expands to nothing:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed and echoed'

In all other cases, both `s` and `q` expand to a value which suppresses
echoing of the command that follows:

$(s)echo 'This command is executed but not echoed'
$(q)echo 'This command is executed but not echoed'

The `s` variable is predominantly useful for `echo` commands, where you
always want to suppress echoing of the command itself, whilst `q` is
more useful for all other commands.

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

show more ...

Merge changes from topics "ck/tf-a-build-fixes", "ck/tf-a-romlib-build-fixes" into integration

* changes:
build(romlib): don't timestamp generated wrappers
build(romlib): de-duplicate ROMLib wra

Merge changes from topics "ck/tf-a-build-fixes", "ck/tf-a-romlib-build-fixes" into integration

* changes:
build(romlib): don't timestamp generated wrappers
build(romlib): de-duplicate ROMLib wrapper sources
fix(build): fix incorrectly-escaped armlink preprocessor definitions

show more ...

build(romlib): don't timestamp generated wrappers

The Makefile rule for the libwrappers object files places a dependency
on a timestamp file. This timestamp file is created by the recipe that
genera

build(romlib): don't timestamp generated wrappers

The Makefile rule for the libwrappers object files places a dependency
on a timestamp file. This timestamp file is created by the recipe that
generates the libwrappers sources, and was presumably introduced to
indicate to Make that all of the source files are generated
simultaneously by that rule.

Instead, we can use a grouped target rule, which uses `&:` instead of
`:`. This communicates to Make that all of the targets listed are
generated at once.

To demonstrate, the following two Makefile rules differ in their
behaviour:

a.x b.x c.x: # targets may be updated independently
... # generate a.x, b.x and c.x

a.x b.x c.x &: # all targets are updated at once
... # generate a.x, b.x and c.x

While both recipes do generate all three files, only the second rule
communicates this fact to Make. As such, Make can reason that if one of
the files is up to date then all of them are, and avoid re-running the
rule for any generated file that it has not already run it for.

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

show more ...

build(romlib): de-duplicate ROMLib wrapper sources

The `romlib_generator.py` script may generate duplicate wrapper sources,
which is undesirable when using them to generate Makefile rules as Make
wi

build(romlib): de-duplicate ROMLib wrapper sources

The `romlib_generator.py` script may generate duplicate wrapper sources,
which is undesirable when using them to generate Makefile rules as Make
will warn about duplicated targets.

This change sorts the wrapper sources returned from this script, which
has the effect of also de-duplicating them.

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

show more ...