Build: remove third argument of CERT_ADD_CMD_OPT

The third argument was given "true" by images, but it was moved
to TOOL_ADD_PAYLOAD. No more caller of CERT_ADD_CMD_OPT uses this.
So, the third arg

Build: remove third argument of CERT_ADD_CMD_OPT

The third argument was given "true" by images, but it was moved
to TOOL_ADD_PAYLOAD. No more caller of CERT_ADD_CMD_OPT uses this.
So, the third argument is always empty. Remove it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: rename FIP_ADD_IMG to TOOL_ADD_IMG

Now FIP_ADD_IMG takes care of both fiptool and cert_create
symmetrically. Rename it so that it matches the behavior.

Signed-off-by: Masahiro Yamada <yamad

Build: rename FIP_ADD_IMG to TOOL_ADD_IMG

Now FIP_ADD_IMG takes care of both fiptool and cert_create
symmetrically. Rename it so that it matches the behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: rename FIP_ADD_PAYLOAD to TOOL_ADD_PAYLOAD

Now FIP_ADD_PAYLOAD takes care of both fiptool and cert_create
symmetrically. Rename it so that it matches the behavior.

Signed-off-by: Masahiro Y

Build: rename FIP_ADD_PAYLOAD to TOOL_ADD_PAYLOAD

Now FIP_ADD_PAYLOAD takes care of both fiptool and cert_create
symmetrically. Rename it so that it matches the behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: move cert_create arguments and dependency to FIP_ADD_PAYLOAD

The fiptool and cert_create use the same command options for images.
It is pretty easy to handle both in the same, symmetrical way

Build: move cert_create arguments and dependency to FIP_ADD_PAYLOAD

The fiptool and cert_create use the same command options for images.
It is pretty easy to handle both in the same, symmetrical way.

Move CRT_ARGS and CRT_DEPS to FIP_ADD_PAYLOAD. This refactoring makes
sense because FIP_ADD_PAYLOAD is called from MAKE_BL (when building
images from source), and from FIP_ADD_IMG (when including external
images). (FIP_ADD_PAYLOAD will be renamed later on since it now
caters to both fiptool and cert_create).

We can delete CERT_ADD_CMD_OPT for images in tbbr.mk. It still
needs to call CERT_ADD_CMD_OPT directly for certificates.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: rip off unneeded $(eval ...) from buid macros

The callers of these macros are supposed to use $(eval $(call, ...)).
The $(eval ...) on the callee side is unneeded.

Signed-off-by: Masahiro Ya

Build: rip off unneeded $(eval ...) from buid macros

The callers of these macros are supposed to use $(eval $(call, ...)).
The $(eval ...) on the callee side is unneeded.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: merge build macros between FIP_ and FWU_FIP_

The build system supports generating two FIP images, fip and fwu_fip.
Accordingly, we have similar build macros.

FIP_ADD_PAYLOAD <--> FWU_F

Build: merge build macros between FIP_ and FWU_FIP_

The build system supports generating two FIP images, fip and fwu_fip.
Accordingly, we have similar build macros.

FIP_ADD_PAYLOAD <--> FWU_FIP_ADD_PAYLOAD
CERT_ADD_CMD_OPT <--> FWU_CERT_ADD_CMD_OPT
FIP_ADD_IMG <--> FWU_FIP_ADD_IMG

The duplicated code increases the maintenance burden. Also, the build
rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from
source files, but we want to put it in fwu_fip. We can not do it in a
single macro call since the current MAKE_BL does not support fwu_fip.

To refactor those in a clean way is to support one more argument to
specify the FIP prefix. If it is empty, the images are targeted to
fip, whereas if the argument is "FWU_", targeted to fwu_fip.

The build macros prefixed with FWU_ go away.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: squash MAKE_TOOL_ARGS into MAKE_BL

Now, MAKE_TOOL_ARGS is only called from MAKE_BL. Squash it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Build: check if specified external image exists

check_* targets check if the required option are given, but do not
check the validity of the argument. If the specified file does not
exist, let the

Build: check if specified external image exists

check_* targets check if the required option are given, but do not
check the validity of the argument. If the specified file does not
exist, let the build fail immediately instead of passing the invalid
file path to tools.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge pull request #1193 from jwerner-chromium/JW_coreboot

New console API and coreboot support [v4]

Add platform-independent coreboot support library

This patch adds the foundation for a platform-independent coreboot
support library that can be shared by all platforms that boot BL31 from
coreboot

Add platform-independent coreboot support library

This patch adds the foundation for a platform-independent coreboot
support library that can be shared by all platforms that boot BL31 from
coreboot (acting as BL2). It adds code to parse the "coreboot table", a
data structure that coreboot uses to communicate different kinds of
information to later-stage firmware and certain OS drivers.

As a first small use case for this information, allow platforms to
access the serial console configuration used by coreboot, removing the
need to hardcode base address and divisors and allowing Trusted Firmware
to benefit from coreboot's user configuration (e.g. which UART to pick
and which baud rate to use).

Change-Id: I2bfb39cd2609ce6640b844ab68df6c9ae3f28e9e
Signed-off-by: Julius Werner <jwerner@chromium.org>

show more ...

Merge pull request #1200 from robertovargas-arm/bl2-el3

Add BL2_AT_EL3 build option

bl2-el3: Don't include BL2 in fip for BL2 at EL3

It is better to not include BL2 in FIP when using `BL2 at EL3` as
platforms using this config would not have the capability to parse the
FIP format i

bl2-el3: Don't include BL2 in fip for BL2 at EL3

It is better to not include BL2 in FIP when using `BL2 at EL3` as
platforms using this config would not have the capability to parse the
FIP format in Boot ROM and BL2 needs to be loaded independently. This
patch does the required changes for the same.

Change-Id: Iad285c247b3440e2d827fef97c3dd81f5c09cabc
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

show more ...

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
stages without need for BL1. This is not currently possible because
BL2 executes at S-EL1 and cannot jump straight to EL3.

Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

show more ...

Build: specify check_* targets as .PHONY

check_* targets just check necessary command line argument, not
build any images. They should be specified as .PHONY.

Signed-off-by: Masahiro Yamada <yamad

Build: specify check_* targets as .PHONY

check_* targets just check necessary command line argument, not
build any images. They should be specified as .PHONY.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Build: update comment lines for macros

Commit 8f0617ef9e46 ("Apply TBBR naming convention to the fip_create
options") changed fiptool command options. We often forget to update
documentation.

Sign

Build: update comment lines for macros

Commit 8f0617ef9e46 ("Apply TBBR naming convention to the fip_create
options") changed fiptool command options. We often forget to update
documentation.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge pull request #1104 from nmenon/dtb_build-v2

Makefile: Add ability to build dtb (v2)

Add new function-pointer-based console API

This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to w

Add new function-pointer-based console API

This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to well-known function names (like console_core_init),
consoles now provide a register function (e.g. console_16550_register())
that will hook them into the list of active consoles. All console
operations will be dispatched to all consoles currently in the list.

The new API will be selected by the build-time option MULTI_CONSOLE_API,
which defaults to ${ERROR_DEPRECATED} for now. The old console API code
will be retained to stay backwards-compatible to older platforms, but
should no longer be used for any newly added platforms and can hopefully
be removed at some point in the future.

The new console API is intended to be used for both normal (bootup) and
crash use cases, freeing platforms of the need to set up the crash
console separately. Consoles can be individually configured to be active
active at boot (until first handoff to EL2), at runtime (after first
handoff to EL2), and/or after a crash. Console drivers should set a sane
default upon registration that can be overridden with the
console_set_scope() call. Code to hook up the crash reporting mechanism
to this framework will be added with a later patch.

This patch only affects AArch64, but the new API could easily be ported
to AArch32 as well if desired.

Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
Signed-off-by: Julius Werner <jwerner@chromium.org>

show more ...

Merge pull request #1178 from davidcunado-arm/dc/enable_sve

Enable SVE for Non-secure world

Merge pull request #1168 from matt2048/master

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

Enable SVE for Non-secure world

This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
to one EL3 will check to see if the Scalable Vector Extension (SVE) is
implemented when entering

Enable SVE for Non-secure world

This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
to one EL3 will check to see if the Scalable Vector Extension (SVE) is
implemented when entering and exiting the Non-secure world.

If SVE is implemented, EL3 will do the following:

- Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.

- Exit from Non-secure world: SIMD, FP and SVE functionality is
disabled. As SIMD and FP registers are part of the SVE Z-registers
then any use of SIMD / FP functionality would corrupt the SVE
registers.

The build option default is 1. The SVE functionality is only supported
on AArch64 and so the build option is set to zero when the target
archiecture is AArch32.

This build option is not compatible with the CTX_INCLUDE_FPREGS - an
assert will be raised on platforms where SVE is implemented and both
ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.

Also note this change prevents secure world use of FP&SIMD registers on
SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
such platforms unless ENABLE_SVE_FOR_NS is set to 0.

Additionally, on the first entry into the Non-secure world the SVE
functionality is enabled and the SVE Z-register length is set to the
maximum size allowed by the architecture. This includes the use case
where EL2 is implemented but not used.

Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
Signed-off-by: David Cunado <david.cunado@arm.com>

show more ...

ARM platforms: Fixup AArch32 builds

This patch fixes a couple of issues for AArch32 builds on ARM reference
platforms :

1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and

ARM platforms: Fixup AArch32 builds

This patch fixes a couple of issues for AArch32 builds on ARM reference
platforms :

1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
the BL31 memory is empty when built for AArch32. Hence this patch allocates
BL32 to the memory region occupied by BL31 for AArch32 builds.

As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
be used to control the load address of BL32 in AArch32 mode which was
never the intention of the macro anyway.

2. A static assert is added to sp_min linker script to check that the progbits
are within the bounds expected when overlaid with other images.

3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
involved when building Juno for AArch32 mode, the build option SPD needed to
specifed. This patch corrects this and also updates the documentation in the
user-guide.

4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
a result the previous assumption that BL31 must be always present is removed
and the certificates for BL31 is only generated if `NEED_BL31` is defined.

Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

show more ...

Implement support for the Activity Monitor Unit on Cortex A75

The Cortex A75 has 5 AMU counters. The first three counters are fixed
and the remaining two are programmable.

A new build option is in

Implement support for the Activity Monitor Unit on Cortex A75

The Cortex A75 has 5 AMU counters. The first three counters are fixed
and the remaining two are programmable.

A new build option is introduced, `ENABLE_AMU`. When set, the fixed
counters will be enabled for use by lower ELs. The programmable
counters are currently disabled.

Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

show more ...

Merge pull request #1145 from etienne-lms/rfc-armv7-2

Support ARMv7 architectures

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

This patch replaces the macro ASM_ASSERTION with the macro
ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor
related files. There is

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

This patch replaces the macro ASM_ASSERTION with the macro
ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor
related files. There is build error when ASM_ASSERTION is set
to 1 and ENABLE_ASSERTIONS is set to 0 because function
asm_assert in common/aarch32/debug.S is defined in the macro
ENABLE_ASSERTIONS but is called with the macro ASM_ASSERTION.

There is also the indication to use ENABLE_ASSERTIONS but not
ASM_ASSERTION in the Makefile.

Signed-off-by: Matt Ma <matt.ma@spreadtrum.com>

show more ...

Merge pull request #1165 from geesun/qx/support-sha512

Add support sha512 for hash algorithm