Merge pull request #1115 from jeenu-arm/tsp-mt

TSP: Support multi-threading CPUs on FVP

TSP: Support multi-threading CPUs on FVP

Commit 11ad8f208db42f7729b0ce2bd16c631c293e665c added supporting
multi-threaded CPUs on FVP platform, including modifications for
calculating CPU IDs. This p

TSP: Support multi-threading CPUs on FVP

Commit 11ad8f208db42f7729b0ce2bd16c631c293e665c added supporting
multi-threaded CPUs on FVP platform, including modifications for
calculating CPU IDs. This patch imports the strong definition of the
same CPU ID calculation on FVP platform for TSP.

Without this patch, TSP on FVP was using the default CPU ID calculation,
which would end up being wrong on CPUs with multi-threading.

Change-Id: If67fd492dfce1f57224c9e693988c4b0f89a9a9a
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

Merge pull request #1107 from geesun/qx/add_ecdsa_support

Add support for TBBR using ECDSA keys in ARM platforms

Merge pull request #1114 from vchong/updt_docs

hikey*: Update docs

hikey*: Update docs

Signed-off-by: Victor Chong <victor.chong@linaro.org>

Merge pull request #1111 from douglas-raillard-arm/dr/fix_uniphier_xlat_include

Uniphier: fix xlat tables lib inclusion

Uniphier: fix xlat tables lib inclusion

Uses the xlat tables library's Makefile instead of directly including
the source files in the Uniphier platform port.

Change-Id: I27294dd71bbf9bf3e82973c7532

Uniphier: fix xlat tables lib inclusion

Uses the xlat tables library's Makefile instead of directly including
the source files in the Uniphier platform port.

Change-Id: I27294dd71bbf9bf3e82973c75324652b037e5bce
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

show more ...

Merge pull request #1110 from masahir0y/xlat

Fix MAP_REGION for GCC 4.9

xlat: remove cast in MAP_REGION to get back building with GCC 4.9

Since commit 769d65da778b ("xlat: Use MAP_REGION macro as compatibility
layer"), building with GCC 4.9 fails.

CC plat/arm/bo

xlat: remove cast in MAP_REGION to get back building with GCC 4.9

Since commit 769d65da778b ("xlat: Use MAP_REGION macro as compatibility
layer"), building with GCC 4.9 fails.

CC plat/arm/board/fvp/fvp_common.c
plat/arm/board/fvp/fvp_common.c:60:2: error: initializer element is not constant
ARM_MAP_SHARED_RAM,
^
plat/arm/board/fvp/fvp_common.c:60:2: error: (near initialization for 'plat_arm_mmap[0]')
make: *** [Makefile:535: build/fvp/release/bl1/fvp_common.o] Error 1

Taking into account that MAP_REGION(_FLAT) is widely used in array
initializers, do not use cast.

Fixes: 769d65da778b ("xlat: Use MAP_REGION macro as compatibility layer")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge pull request #1108 from sandrine-bailleux-arm/sb/fvp-utils-def

FVP: Include utils_def.h instead of utils.h

Merge pull request #1105 from antonio-nino-diaz-arm/an/epd1-bit

Set TCR_EL1.EPD1 bit to 1

Merge pull request #1106 from antonio-nino-diaz-arm/an/bit-macro

Fix type of `unsigned long` constants

mem_protect: Add DRAM2 to the list of mem protected ranges

On ARM platforms, the maximum size of the address space is limited
to 32-bits as defined in arm_def.h. In order to access DRAM2, which
is d

mem_protect: Add DRAM2 to the list of mem protected ranges

On ARM platforms, the maximum size of the address space is limited
to 32-bits as defined in arm_def.h. In order to access DRAM2, which
is defined beyond the 32-bit address space, the maximum address space
is increased to 36-bits in AArch64. It is possible to increase the
virtual space for AArch32, but it is more difficult and not supported
for now.

NOTE - the actual maximum memory address space is platform dependent
and is checked at run-time by querying the PARange field in the
ID_AA64MMFR0_EL1 register.

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

show more ...

mem_protect: Add mem_protect support in Juno and FVP for DRAM1

mem_protect needs some kind of non-volatile memory because it has
to remember its state across reset and power down events.
The most su

mem_protect: Add mem_protect support in Juno and FVP for DRAM1

mem_protect needs some kind of non-volatile memory because it has
to remember its state across reset and power down events.
The most suitable electronic part for this feature is a NVRAM
which should be only accesible from the secure world. Juno and
FVP lack such hardware and for this reason the MEM_PROTECT
functionality is implemented with Flash EEPROM memory on both
boards, even though this memory is accesible from the non-secure
world. This is done only to show a full implementation of
these PSCI features, but an actual system shouldn't use a
non-secure NVRAM to implement it.

The EL3 runtime software will write the mem_protect flag and BL2
will read and clear the memory ranges if enabled. It is done in
BL2 because it reduces the time that TF needs access to the full
non-secure memory.

The memory layout of both boards is defined using macros which
take different values in Juno and FVP platforms. Generic platform
helpers are added that use the platform specific macros to generate
a mem_region_t that is valid for the platform.

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

show more ...

Add mem_region utility functions

This commit introduces a new type (mem_region_t) used to describe
memory regions and it adds two utility functions:

- clear_mem_regions: This function clears (writ

Add mem_region utility functions

This commit introduces a new type (mem_region_t) used to describe
memory regions and it adds two utility functions:

- clear_mem_regions: This function clears (write 0) to a set
of regions described with an array of mem_region_t.

- mem_region_in_array_chk This function checks if a
region is covered by some of the regions described
with an array of mem_region_t.

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

show more ...

mem_protect: Add mem_protect API

This patch adds the generic code that links the psci smc handler
with the platform function that implements the mem_protect and
mem_check_range functionalities. Thes

mem_protect: Add mem_protect API

This patch adds the generic code that links the psci smc handler
with the platform function that implements the mem_protect and
mem_check_range functionalities. These functions are optional
APIs added in PSCI v1.1 (ARM DEN022D).

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

show more ...

Dynamic selection of ECDSA or RSA

Add new option rsa+ecdsa for TF_MBEDTLS_KEY_ALG, which selects
rsa or ecdsa depending on the certificate used.

Change-Id: I08d9e99bdbba361ed2ec5624248dc382c750ad47

Dynamic selection of ECDSA or RSA

Add new option rsa+ecdsa for TF_MBEDTLS_KEY_ALG, which selects
rsa or ecdsa depending on the certificate used.

Change-Id: I08d9e99bdbba361ed2ec5624248dc382c750ad47
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

show more ...

Add support for TBBR using ECDSA keys in ARM platforms

- fixed compile error when KEY_ALG=ecdsa
- add new option ecdsa for TF_MBEDTLS_KEY_ALG
- add new option devel_ecdsa for ARM_ROTPK_L

Add support for TBBR using ECDSA keys in ARM platforms

- fixed compile error when KEY_ALG=ecdsa
- add new option ecdsa for TF_MBEDTLS_KEY_ALG
- add new option devel_ecdsa for ARM_ROTPK_LOCATION
- add ecdsa key at plat/arm/board/common/rotpk/
- reduce the mbedtls heap memory size to 13k

Change-Id: I3f7a6170af93fdbaaa7bf2fffb4680a9f6113c13
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

show more ...

plat/arm : update BL size macros to give BL1 and BL2 more space for TBB

For Trusted Board Boot, BL1 RW section and BL2 need more space to
support the ECDSA algorithm. Specifically, PLAT_ARM_MAX_BL1_

plat/arm : update BL size macros to give BL1 and BL2 more space for TBB

For Trusted Board Boot, BL1 RW section and BL2 need more space to
support the ECDSA algorithm. Specifically, PLAT_ARM_MAX_BL1_RW_SIZE
is increased on ARM platforms.

And on the Juno platform:
- BL2 size, PLAT_ARM_MAX_BL2_SIZE is increased.
- SCP_BL2 is loaded into the space defined by BL31_BASE ->
BL31_RW_BASE. In order to maintain the same size space for
SCP_BL2,PLAT_ARM_MAX_BL31_SIZE is increased.

Change-Id: I379083f918b40ab1c765da4e71780d89f0058040
Co-Authored-By: David Cunado <david.cunado@arm.com>
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

show more ...

FVP: Include utils_def.h instead of utils.h

platform_def.h doesn't need all the definitions in utils.h,
the ones in utils_def.h are enough. This patch is related
to the changes introduced by commit

FVP: Include utils_def.h instead of utils.h

platform_def.h doesn't need all the definitions in utils.h,
the ones in utils_def.h are enough. This patch is related
to the changes introduced by commit 53d9c9c85b.

Change-Id: I4b2ff237a2d7fe07a7230e0e49b44b3fc2ca8abe
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

show more ...

Fix type of `unsigned long` constants

The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
AArch64. This is inconsistent and that's why we avoid using it as per
the Coding Guidelin

Fix type of `unsigned long` constants

The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
AArch64. This is inconsistent and that's why we avoid using it as per
the Coding Guidelines. This patch changes all `UL` occurrences to `U`
or `ULL` depending on the context so that the size of the constant is
clear.

This problem affected the macro `BIT(nr)`. As long as this macro is used
to fill fields of registers, that's not a problem, since all registers
are 32 bit wide in AArch32 and 64 bit wide in AArch64. However, if the
macro is used to fill the fields of a 64-bit integer, it won't be able
to set the upper 32 bits in AArch32.

By changing the type of this macro to `unsigned long long` the behaviour
is always the same regardless of the architecture, as this type is
64-bit wide in both cases.

Some Tegra platform files have been modified by this patch.

Change-Id: I918264c03e7d691a931f0d1018df25a2796cc221
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Set TCR_EL1.EPD1 bit to 1

In the S-EL1&0 translation regime we aren't using the higher VA range,
whose translation table base address is held in TTBR1_EL1. The bit
TCR_EL1.EPD1 can be used to disabl

Set TCR_EL1.EPD1 bit to 1

In the S-EL1&0 translation regime we aren't using the higher VA range,
whose translation table base address is held in TTBR1_EL1. The bit
TCR_EL1.EPD1 can be used to disable translations using TTBR1_EL1, but
the code wasn't setting it to 1. Additionally, other fields in TCR1_EL1
associated with the higher VA range (TBI1, TG1, SH1, ORGN1, IRGN1 and
A1) weren't set correctly as they were left as 0. In particular, 0 is a
reserved value for TG1. Also, TBBR1_EL1 was not explicitly set and its
reset value is UNKNOWN.

Therefore memory accesses to the higher VA range would result in
unpredictable behaviour as a translation table walk would be attempted
using an UNKNOWN value in TTBR1_EL1.

On the FVP and Juno platforms accessing the higher VA range resulted in
a translation fault, but this may not always be the case on all
platforms.

This patch sets the bit TCR_EL1.EPD1 to 1 so that any kind of
unpredictable behaviour is prevented.

This bug only affects the AArch64 version of the code, the AArch32
version sets this bit to 1 as expected.

Change-Id: I481c000deda5bc33a475631301767b9e0474a303
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

xlat: simplify mmap_add_region_check parameters (#1101)

Use a mmap_region_t as parameter instead of getting a parameter for each
structure member. This reduces the scope of changes when adding memb

xlat: simplify mmap_add_region_check parameters (#1101)

Use a mmap_region_t as parameter instead of getting a parameter for each
structure member. This reduces the scope of changes when adding members
to mmap_region_t.

Also align on the convention of using mm_cursor as a variable name for
the currently inspected region when iterating on the region array.

Change-Id: If40bc4351b56c64b214e60dda27276d11ce9dbb3
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

show more ...

Makefile: Add ability to build dtb

This is a revamp of the original approach in:
https://github.com/ARM-software/arm-trusted-firmware/pull/747

Current build system has no means to automatically gen

Makefile: Add ability to build dtb

This is a revamp of the original approach in:
https://github.com/ARM-software/arm-trusted-firmware/pull/747

Current build system has no means to automatically generate dtbs from
dts, instead, stores the dtbs in the fdts/ folder. While this makes
perfect sense for many reference platforms, this becomes a minor
breakage in development flow for newer platforms.

However, this can be solved by providing a rule for the dtbs while
building the ATF binaries by purely describing which dts sources we
need.

For example, with this change, we will now be able to describe the
dtbs we need for the platform in the corresponding platform.mk file:
FDT_SOURCES += fdts/abc.dts

This should be able to generate the abc.dtb appropriately.

Since device trees are specification of hardware, we don't tie the rule
to any specific BL, instead a generic rule is introduced.

Further, this approach allows us to generate appropriate dtbs which may be
need to be regenerated when a common dtsi gets updated, by just
restricting changes to the dtsi alone, instead of synchronizing all the
dtbs as well.

If dtc is not available in default paths, but is available in an
alternate location, it can be chosen by overriding the DTC variable
such as 'make DTC=~/dtc/dtc ....`

NOTE: dtbs are built only with the explicit make dtbs command. The rule
is only available if the platform defines a FDT_SOURCES variable.

Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

show more ...

Merge pull request #1099 from douglas-raillard-arm/dr/fix_mm_copy

xlat: fix mm copy when adding a region