fix(lx2160a): put cert_create_tbbr.mk in the standard location

The cert_create_tbbr.mk file is generally looked for in the platform
directory. The lx2160a breaks from this convention and stores the

fix(lx2160a): put cert_create_tbbr.mk in the standard location

The cert_create_tbbr.mk file is generally looked for in the platform
directory. The lx2160a breaks from this convention and stores the file
elsewhere, requiring a cludgy `cp` mid way through the make process. The
result is an untracked file when building the platform, which is
undesirable.

Fix this by putting the cert_create_tbbr.mk (and associated source
files) in the plat/ directory, just like we do for juno and stm32mp1.

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

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

fix(nxp-tools): fix2 create_pbl buildroot build

For some unknown reasons I did miss this '+' which does not make
sense when I submitted the former commit. We all did miss
it during codre reviews, so

fix(nxp-tools): fix2 create_pbl buildroot build

For some unknown reasons I did miss this '+' which does not make
sense when I submitted the former commit. We all did miss
it during codre reviews, sorry for the confusion. I do not understand
how it happened, late commits -> stupid issues.

Revert and fix: 634c7d81 fix create_pbl buildroot build
Wall -Werror -pedantic -std=c99 -O2 -DVERSION='"v2.12.0(release):master"' -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -c -o create_pbl.o create_pbl.c
make[3]: Wall: No such file or directory

Change-Id: I1e17e4793061966ce5fa5e0c122914bfaed27952
Signed-off-by: Vincent Jardin <vjardin@free.fr>

show more ...

fix(nxp-tools): fix create_pbl buildroot build

When building with Buildroot environment, the rule to build
the object is not used from the Makefile but from another one with
a higher priority.

It l

fix(nxp-tools): fix create_pbl buildroot build

When building with Buildroot environment, the rule to build
the object is not used from the Makefile but from another one with
a higher priority.

It leads to the following error:
Built fiptool successfully

EL3 Runtime Firmware BL31: offset=0x88, size=0xE401, cmdline="--soc-fw"
Non-Trusted Firmware BL33: offset=0xE489, size=0xD1438, cmdline="--nt-fw"

Wall -Werror -pedantic -std=c99 -O2 -DVERSION='"v2.12.0(release):master"' -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -c -o create_pbl.o create_pbl.c
make[3]: Wall: No such file or directory

Let's be explicit in order to enforce the local rule. There is not .h
file so it should be removed from the dependency list in oder to avoid
such error:
make[3]: *** No rule to make target 'create_pbl.h', needed by 'create_pbl.o'. Stop.

Change-Id: Idec378c5688e332695d805f3fca2800d905a1c74
Signed-off-by: Vincent Jardin <vjardin@free.fr>

show more ...

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

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

fix(tools): update the fiptool and certtool to fix POSIX build

This patch fixes below issue raised:

https://github.com/TrustedFirmware-A/trusted-firmware-a/issues/8
https://github.com/TrustedFirmwa

fix(tools): update the fiptool and certtool to fix POSIX build

This patch fixes below issue raised:

https://github.com/TrustedFirmware-A/trusted-firmware-a/issues/8
https://github.com/TrustedFirmware-A/trusted-firmware-a/issues/9
https://github.com/TrustedFirmware-A/trusted-firmware-a/issues/10

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

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

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