GitLab

When TF-A is built with RESET_TO_BL31=1 option, BL31 is the
first image to be run and should have all the memory allocated
to it except for the memory reserved for Shared RAM at the start
of Trusted SRAM.
This patch fixes FVP BL31 load address and its image size for
RESET_TO_BL31=1 option. BL31 startup address should be set to
0x400_1000 and its maximum image size to the size of Trusted SRAM
minus the first 4KB of shared memory.
Loading BL31 at 0x0402_0000 as it is currently stated in
'\docs\plat\arm\fvp\index.rst' causes EL3 exception when the
image size gets increased (i.e. building with LOG_LEVEL=50)
but doesn't exceed 0x3B000 not causing build error.

Change-Id: Ie450baaf247f1577112f8d143b24e76c39d33e91
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>

Adding support for generating a semi-random number required for
enabling building TF-A with stack protector support.
TF-A for corstone-700 may now be built using ENABLE_STACK_PROTECTOR=all

Change-Id: I03e1be1a8d4e4a822cf286f3b9ad4da4337ca765
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>

Change-Id: I011256ca60672a00b711c3f5725211be64bbc2b2
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Forced hash generation used to always generate hash via RSA encryption.
This patch changes encryption based on ARM_ROTPK_LOCATION.
Also removes setting KEY_ALG based on ARM_ROTPL_LOCATION - there is no
relation between these two.
Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
Change-Id: Id727d2ed06176a243719fd0adfa0cae26c325005

This patch adds support to the build system to include support for the SPM
dispatcher when the SPD configuration option is spmd.
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
Change-Id: Ic1ae50ecd7403fcbcf1d318abdbd6ebdc642f732

This patch reserves and maps the Trusted DRAM for SPM core execution.
It also configures the TrustZone address space controller to run BL31
in secure DRAM.
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
Change-Id: I7e1bb3bbc61a0fec6a9cb595964ff553620c21dc

This patch repurposes the TOS FW configuration file as the manifest for
the SPM core component which will reside at the secure EL adjacent to
EL3. The SPM dispatcher component will use the manifest to determine how
the core component must be initialised. Routines and data structure to
parse the manifest have also been added.
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb

Add the initial board support for RD-Daniel Config-M platform.

Change-Id: I36df16c745bfe4bc817e275ad4722e5de57733cd
Signed-off-by: Jagadeesh Ujja <jagadeesh.ujja@arm.com>
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>

RD-E1-Edge platform consists of two clusters with eight CPUs each and
two processing elements (PE) per CPU. Commit a9fbf13e

 (plat/arm/sgi:
move topology information to board folder) defined the RD-E1-Edge
topology tree to have two clusters with eight CPUs each but PE per CPU
entries were not added. This patch fixes the topology tree accordingly.

Change-Id: I7f97f0013be60e5d51c214fce3962e246bae8a0b
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

In preparation for adding support for Reference Design platforms
which have different base addresses for GIC Distributor or
Redistributor, move GIC related base addresses to individual platform
definition files.

Change-Id: Iecf52b4392a30b86905e1cd047c0ff87d59d0191
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

Introduce macro 'CSS_SGI_CHIP_COUNT' to allow Arm CSS platforms with
multi-chip support to define number of chiplets on the platform. By
default, this flag is set to 1 and does not affect the existing single
chip platforms.

For multi-chip platforms, override the default value of
CSS_SGI_CHIP_COUNT with the number of chiplets supported on the
platform. As an example, the command below sets the number of chiplets
to two on the RD-N1-Edge multi-chip platform:

export CROSS_COMPILE=<path-to-cross-compiler>
make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all

Change-Id: If364dc36bd34b30cc356f74b3e97633933e6c8ee
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

Include multi-chip-mode parameter in HW_CONFIG dts to let next stage of
boot firmware know about the multi-chip operation mode.

Change-Id: Ic7535c2280fd57180ad14aa0ae277cf0c4d1337b
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

RD-N1-Edge based platforms can operate in dual-chip configuration
wherein two rdn1edge SoCs are connected through a high speed coherent
CCIX link.

This patch adds a function to check if the RD-N1-Edge platform is
operating in multi-chip mode by reading the SID register's NODE_ID
value. If operating in multi-chip mode, initialize GIC-600 multi-chip
operation by overriding the default GICR frames with array of GICR
frames and setting the chip 0 as routing table owner.

The address space of the second RD-N1-Edge chip (chip 1) starts from the
address 4TB. So increase the physical and virtual address space size to
43 bits to accommodate the multi-chip configuration. If the multi-chip
mode configuration is detected, dynamically add mmap entry for the
peripherals memory region of the second RD-N1-Edge SoC. This is required
to let the BL31 platform setup stage to configure the devices in the
second chip.

PLATFORM_CORE_COUNT macro is set to be multiple of CSS_SGI_CHIP_COUNT
and topology changes are added to represent the dual-chip configuration.

In order the build the dual-chip platform, CSS_SGI_CHIP_COUNT macro
should be set to 2:
export CROSS_COMPILE=<path-to-cross-compiler>
make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all

Change-Id: I576cdaf71f0b0e41b9a9181fa4feb7091f8c7bb4
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

On systems that have multiple platform components that can interpret the
SCMI messages, there is a need to support multiple SCMI channels (one
each to those platform components). Extend the existing SCMI interface
that currently supports only a single SCMI channel to support multiple
SCMI channels.

Change-Id: Ice4062475b903aef3b5e5bc37df364c9778a62c5
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>

In order to allow the MHUv2 driver to be usable with multiple MHUv2
controllers, use the base address of the controller from the platform
information instead of the MHUV2_BASE_ADDR macro.

Change-Id: I4dbab87b929fb0568935e6c8b339ce67937f8cd1
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>

AFF3 bits of MPIDR corresponds to Chip-Id in Arm multi-chip platforms.
For calculating linear core position of CPU cores from slave chips, AFF3
bits has to be used. Update `plat_arm_calc_core_pos` assembly function
to include AFF3 bits in calculation.

Change-Id: I4af2bd82ab8e31e18bc61de22705a73893954260
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

Some of the Reference Design platforms like RD-N1-Edge can operate in
multi-chip configuration wherein two or more SoCs are connected through
a high speed coherent CCIX link. For the RD platforms, the remote chip
address space is at the offset of 4TB per chip. In order for the primary
chip to access the device memory region on the remote chip, the required
memory region entries need to be added as mmap entry. This patch adds
macros related to the remote chip device memory region.

Change-Id: I833810b96f1a0e7c3c289ac32597b6ba03344c80
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

Multi-chip platforms have two or more identical chips connected using a
high speed coherent link. In order to identify such platforms,
add chip_id and multi_chip_mode information in the platform variant
info structure. The values of these two new elements is populated
during boot.

Change-Id: Ie6e89cb33b3f0f408814f6239cd06647053e23ed
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

For SGI-575 and RD platforms, move bl31_platform_setup handler to
individual board files to allow the platforms to perform board specific
bl31 setup.

Change-Id: Ia44bccc0a7f40a155b33909bcb438a0909b20d42
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

Currently, an IO setup failure will be ignored on arm platform release
build. Change this to panic instead.

Change-Id: I027a045bce2422b0a0fc4ff9e9d4c6e7bf5d2f98
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Change the return type of "arm_io_is_toc_valid()" and
"plat_arm_bl1_fwu_needed()" to bool, to match function behavior.

Change-Id: I503fba211219a241cb263149ef36ca14e3362a1c
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Use the firmware configuration framework to store the io_policies
information inside the configuration device tree instead of the static
structure in the code base.

The io_policies required by BL1 can't be inside the dtb, as this one is
loaded by BL1, and only available at BL2.

This change currently only applies to FVP platform.

Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Use the firmware configuration framework in arm dynamic configuration
to retrieve mbedtls heap information between bl1 and bl2.

For this, a new fconf getter is added to expose the device tree base
address and size.

Change-Id: Ifa5ac9366ae100e2cdd1f4c8e85fc591b170f4b6
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Use fconf to retrieve the `disable_authentication` property.
Move this access from arm dynamic configuration to bl common.

Change-Id: Ibf184a5c6245d04839222f5457cf5e651f252b86
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

This patch introduces a better separation between the trusted-boot
related properties, and the dynamic configuration DTBs loading
information.

The dynamic configuration DTBs properties are moved to a new node:
`dtb-registry`. All the sub-nodes present will be provided to the
dynamic config framework to be loaded. The node currently only contains
the already defined configuration DTBs, but can be extended for future
features if necessary.
The dynamic config framework is modified to use the abstraction provided
by the fconf framework, instead of directly accessing the DTBs.

The trusted-boot properties are kept under the "arm,tb_fw" compatible
string, but in a separate `tb_fw-config` node.
The `tb_fw-config` property of the `dtb-registry` node simply points
to the load address of `fw_config`, as the `tb_fw-config` is currently
part of the same DTB.

Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Use the dtb provided by bl1 as configuration file for fconf.

Change-Id: I3f466ad9b7047e1a361d94e71ac6d693e31496d9
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Move the loading of the dtb from arm_dym_cfg to fconf. The new loading
function is not associated to arm platform anymore, and can be moved
to bl_main if wanted.

Change-Id: I847d07eaba36d31d9d3ed9eba8e58666ea1ba563
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Introduce the Firmware CONfiguration Framework (fconf).

The fconf is an abstraction layer for platform specific data, allowing
a "property" to be queried and a value retrieved without the requesting
entity knowing what backing store is being used to hold the data.

The default backing store used is C structure. If another backing store
has to be used, the platform integrator needs to provide a "populate()"
function to fill the corresponding C structure.
The "populate()" function must be registered to the fconf framework with
the "FCONF_REGISTER_POPULATOR()". This ensures that the function would
be called inside the "fconf_populate()" function.

A two level macro is used as getter:
- the first macro takes 3 parameters and converts it to a function
  call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c).
- the second level defines a__b_getter(c) to the matching C structure,
  variable, array, function, etc..

Ex: Get a Chain of trust property:
    1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id)
    2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id]

Change-Id: Id394001353ed295bc680c3f543af0cf8da549469
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Enables usage of ARM_ROTPK_LOCATION=regs for FVP board.
Removes hard-coded developer keys. Instead, setting
ARM_ROTPK_LOCATION=devel_* takes keys from default directory.
In case of ROT_KEY specified - generates a new hash and replaces the
original.

Note: Juno board was tested by original feature author and was not tested
for this patch since we don't have access to the private key. Juno
implementation was moved to board-specific file without changing
functionality. It is not known whether byte-swapping is still needed
for this platform.

Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986
Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>

Stack usage reaches 90% with some configuration. Bump slightly the stack
size to prevent a stack-overflow.

Change-Id: I44ce8b12906586a42f152b7677785fcdc5e78ae1
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

Fix code that violates the MISRA rule:
MISRA C-2012 Rule 11.9: Literal "0" shall not be used as
null pointer constant.

The fix explicitly checks whether a pointer is NULL.

Change-Id: Ibc318dc0f464982be9a34783f24ccd1d44800551
Signed-off-by: Zelalem <zelalem.aweke@arm.com>

This patch removes unnecessary header file includes
discovered by Coverity HFA option.

Change-Id: I2827c37c1c24866c87db0e206e681900545925d4
Signed-off-by: Zelalem <zelalem.aweke@arm.com>

This patch adds 'fdtw_read_bytes' and 'fdtw_write_inplace_bytes'
functions for read/write array of bytes from/to a given property.
It also adds 'fdt_setprop_inplace_namelen_partial' to jmptbl.i
files for builds with USE_ROMLIB=1 option.

Change-Id: Ied7b5c8b38a0e21d508aa7bcf5893e656028b14d
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>

Allows to select the chain of trust to use when the Trusted Boot feature
is enabled. This affects both the cert_create tool and the firmware
itself.

Right now, the only available CoT is TBBR.

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

The Secure Configuration Register is 64-bits in AArch64 and 32-bits in
AArch32. Use u_register_t instead of unsigned int to reflect this.

Change-Id: I51b69467baba36bf0cfaec2595dc8837b1566934
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load
BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate
the build to require that ARM_BL31_IN_DRAM is enabled as well.

Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code
cannot be reclaimed to be used for runtime data such as secondary cpu stacks.

Memory map for BL31 NOBITS region also has to be created.

Change-Id: Ibbc8c9499a32e63fd0957a6e254608fbf6fa90c9
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

The platform topology description of the upcoming Arm's RD platforms
have different topology than those listed in the sgi_topology.c file. So
instead of adding platform specific topology into existing
sgi_topology.c file, those can be added to respective board files. In
order to maintain consistency with the upcoming platforms, move the
existing platform topology description to respective board files.

Change-Id: I4689c7d24cd0c75a3dc234370c34a85c08598abb
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>

As on SGI platforms, SCPI is unsupported on SGM platforms.

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

This reverts commit d433bbdd.

Change-Id: I46c69dce704a1ce1b50452dd4d62425c4a67f7f0

In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load
BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate
the build to require that ARM_BL31_IN_DRAM is enabled as well.

Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code
cannot be reclaimed to be used for runtime data such as secondary cpu stacks.

Memory map for BL31 NOBITS region also has to be created.

Change-Id: Ibd480f82c1dc74e9cbb54eec07d7a8fecbf25433
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>