Merge changes from topic "bk/multibuild" into integration

* changes:
fix(lx2160a): put cert_create_tbbr.mk in the standard location
feat(build): put crttool in the build directory
feat(build):

Merge changes from topic "bk/multibuild" into integration

* changes:
fix(lx2160a): put cert_create_tbbr.mk in the standard location
feat(build): put crttool in the build directory
feat(build): put enctool in the build directory
feat(build): put fiptool in the build directory
build(marvell): avoid using recursive expansion for BLE_INCLUDES

show more ...

feat(build): put crttool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Leave
a symli

feat(build): put crttool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Leave
a symlink for the final binary in case someone depends on it.

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

show more ...

Merge "build: remove Windows compatibility layer" into integration

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulat

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.

This change removes the remainder of the OS compatibility layer
entirely, and migrates the build system over to explicitly relying on a
POSIX environment.

Change-Id: I8fb60d998162422e958009afd17eab826e3bc39b
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 Ida537d4c,Ieda75bba into integration

* changes:
build(encrypt-fw): don't generate `build_msg.c`
build(cert-create): don't generate `build_msg.c`

build(cert-create): don't generate `build_msg.c`

This change avoids generating a build message source file on the shell,
instead using the `__DATE__` and `__TIME__` macros directly.

Change-Id: Ieda

build(cert-create): don't generate `build_msg.c`

This change avoids generating a build message source file on the shell,
instead using the `__DATE__` and `__TIME__` macros directly.

Change-Id: Ieda75bbac174847c716701bce8dd10b8e9975902
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 "build: use new toolchain variables for tools" into integration

Merge "build: refactor toolchain detection" into integration

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by the toolchain refactor patch. These variables should be
equivalent to the values that they're replacing.

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

show more ...

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default to

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default tools, identify the tools in use, and configure
toolchain flags.

To do this, we introduce three new concepts in this change:

- Toolchain identifiers,
- Tool class identifiers, and
- Tool identifiers.

Toolchain identifiers identify a configurable chain of tools targeting
one platform/machine/architecture. Today, these are:

- The host machine, which receives the `host` identifier,
- The AArch32 architecture, which receives the `aarch32` identifier, and
- The AArch64 architecture, which receivs the `aarch64` identifier.

The tools in a toolchain may come from different vendors, and are not
necessarily expected to come from one single toolchain distribution. In
most cases it is perfectly valid to mix tools from different toolchain
distributions, with some exceptions (notably, link-time optimization
generally requires the compiler and the linker to be aligned).

Tool class identifiers identify a class (or "role") of a tool. C
compilers, assemblers and linkers are all examples of tool classes.

Tool identifiers identify a specific tool recognized and supported by
the build system. Every tool that can make up a part of a toolchain must
receive a tool identifier.

These new identifiers can be used to retrieve information about the
toolchain in a more standardized fashion.

For example, logic in a Makefile that should only execute when the C
compiler is GNU GCC can now check the tool identifier for the C compiler
in the relevant toolchain:

ifeq ($($(ARCH)-cc-id),gnu-gcc)
...
endif

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

show more ...

Merge "build(tools): avoid unnecessary link" into integration

build(tools): avoid unnecessary link

In their respective makefiles, cert_create, encrypt_fw and fiptool
depend on the --openssl phony target as a prerequisite. This forces
those tools to be re-linke

build(tools): avoid unnecessary link

In their respective makefiles, cert_create, encrypt_fw and fiptool
depend on the --openssl phony target as a prerequisite. This forces
those tools to be re-linked each time.

Move the dependencies on the --openssl target from the tools to their
makefiles all targets, to avoid unnecessary linking while preserving the
OpenSSL version printing done in the --openssl targets when in debug.

Fixes: cf2dd17ddda2 ("refactor(security): add OpenSSL 1.x compatibility")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Change-Id: I98a3ab30f36dffc253cecaaf3a57d2712522135d

show more ...

Merge "refactor(security): add OpenSSL 1.x compatibility" into integration

refactor(security): add OpenSSL 1.x compatibility

When updated to work with OpenSSL 3.0, the host tools lost their
compatibility with previous versions (1.x) of OpenSSL. This is
mainly due to the fa

refactor(security): add OpenSSL 1.x compatibility

When updated to work with OpenSSL 3.0, the host tools lost their
compatibility with previous versions (1.x) of OpenSSL. This is
mainly due to the fact that 1.x APIs became deprecated in 3.0 and
therefore their use cause compiling errors. In addition, updating
for a newer version of OpenSSL meant improving the stability
against security threats. However, although version 1.1.1 is
now deprecated, it still receives security updates, so it would
not imply major security issues to keep compatibility with it too.

This patch adds backwards compatibility with OpenSSL 1.x versions
by adding back 1.x API code. It defines a macro USING_OPENSSL3,
which will select the appropriate OpenSSL API version depending on
the OpenSSL library path chosen (which is determined by the
already-existing OPENSSL_DIR variable).

In addition, cleanup items were packed in functions and moved to
the proper modules in order to make the code more maintainable and
legible.

Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com>
Change-Id: I8deceb5e419edc73277792861882404790ccd33c

show more ...

Merge changes from topic "lw/cca_cot" into integration

* changes:
feat(arm): retrieve the right ROTPK for cca
feat(arm): add support for cca CoT
feat(arm): provide some swd rotpk files
build

Merge changes from topic "lw/cca_cot" into integration

* changes:
feat(arm): retrieve the right ROTPK for cca
feat(arm): add support for cca CoT
feat(arm): provide some swd rotpk files
build(tbbr): drive cert_create changes for cca CoT
refactor(arm): add cca CoT certificates to fconf
feat(fiptool): add cca, core_swd, plat cert in FIP
feat(cert_create): define the cca chain of trust
feat(cca): introduce new "cca" chain of trust
build(changelog): add new scope for CCA
refactor(fvp): increase bl2 size when bl31 in DRAM

show more ...

feat(cert_create): define the cca chain of trust

Selection of the cca chain of trust is done through the COT build
option:

> make COT=cca

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.

feat(cert_create): define the cca chain of trust

Selection of the cca chain of trust is done through the COT build
option:

> make COT=cca

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

show more ...

Merge "refactor(security): upgrade tools to OpenSSL 3.0" into integration

refactor(security): upgrade tools to OpenSSL 3.0

Host tools cert_tool and encrypt_fw refactored to be fully
compatible with OpenSSL v3.0.

Changes were made following the OpenSSL 3.0 migration guide

refactor(security): upgrade tools to OpenSSL 3.0

Host tools cert_tool and encrypt_fw refactored to be fully
compatible with OpenSSL v3.0.

Changes were made following the OpenSSL 3.0 migration guide:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html
In some cases, those changes are straightforward and only
a small modification on the types or API calls was needed
(e.g.: replacing BN_pseudo_rand() with BN_rand(). Both identical
since v1.1.0).
The use of low level APIs is now deprecated. In some cases,
the new API provides a simplified solution for our goals and
therefore the code was simplified accordingly (e.g.: generating
RSA keys through EVP_RSA_gen() without the need of handling the
exponent). However, in some cases, a more
sophisticated approach was necessary, as the use of a context
object was required (e.g.: when retrieving the digest value from
an SHA file).

Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com>
Change-Id: I978e8578fe7ab3e71307450ebe7e7812fbcaedb6

show more ...

Merge changes I500ddbe9,I9c10dac9,I53bfff85,I06f7594d,I24bff8d4, ... into integration

* changes:
nxp lx2160a-aqds: new plat based on soc lx2160a
NXP lx2160a-rdb: new plat based on SoC lx2160a

Merge changes I500ddbe9,I9c10dac9,I53bfff85,I06f7594d,I24bff8d4, ... into integration

* changes:
nxp lx2160a-aqds: new plat based on soc lx2160a
NXP lx2160a-rdb: new plat based on SoC lx2160a
nxp lx2162aqds: new plat based on soc lx2160a
nxp: errata handling at soc level for lx2160a
nxp: make file for loading additional ddr image
nxp: adding support of soc lx2160a
nxp: deflt hdr files for soc & their platforms
nxp: platform files for bl2 and bl31 setup
nxp: warm reset support to retain ddr content
nxp: nv storage api on platforms
nxp: supports two mode of trusted board boot
nxp: fip-handler for additional fip_fuse.bin
nxp: fip-handler for additional ddr-fip.bin
nxp: image loader for loading fip image
nxp: svp & sip smc handling
nxp: psci platform functions used by lib/psci
nxp: helper function used by plat & common code
nxp: add data handler used by bl31
nxp: adding the driver.mk file
nxp-tool: for creating pbl file from bl2
nxp: adding the smmu driver
nxp: cot using nxp internal and mbedtls
nxp:driver for crypto h/w accelerator caam
nxp:add driver support for sd and emmc
nxp:add qspi driver
nxp: add flexspi driver support
nxp: adding gic apis for nxp soc
nxp: gpio driver support
nxp: added csu driver
nxp: driver pmu for nxp soc
nxp: ddr driver enablement for nxp layerscape soc
nxp: i2c driver support.
NXP: Driver for NXP Security Monitor
NXP: SFP driver support for NXP SoC
NXP: Interconnect API based on ARM CCN-CCI driver
NXP: TZC API to configure ddr region
NXP: Timer API added to enable ARM generic timer
nxp: add dcfg driver
nxp:add console driver for nxp platform
tools: add mechanism to allow platform specific image UUID
tbbr-cot: conditional definition for the macro
tbbr-cot: fix the issue of compiling time define
cert_create: updated tool for platform defined certs, keys & extensions
tbbr-tools: enable override TRUSTED_KEY_CERT

show more ...

cert_create: updated tool for platform defined certs, keys & extensions

Changes to 'tools/cert_create' folder, to include platform defined
certificates, keys, and extensions.

NXP SoC lx2160a : base

cert_create: updated tool for platform defined certs, keys & extensions

Changes to 'tools/cert_create' folder, to include platform defined
certificates, keys, and extensions.

NXP SoC lx2160a : based platforms requires additional
FIP DDR to be loaded before initializing the DDR.

To enable chain of trust on these platforms, FIP DDR
image needs to be authenticated, additionally.

Platform specific folder 'tools/nxp/cert_create_helper'
is added to support platform specific macros and definitions.

Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Change-Id: I4752a30a9ff3aa1d403e9babe3a07ba0e6b2bf8f

show more ...

Merge "tools: don't clean when building" into integration