GitLab

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>

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>

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>

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>

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>

NOTE for platform integrators:
   API `plat_psci_stat_get_residency()` third argument
   `last_cpu_idx` is changed from "signed int" to the
   "unsigned int" type.

Issue / Trouble points
1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
with typecasting at some places leading to coverity issues.

2. Underlying platform API's return cpu_idx as `unsigned int`
and comparison is performed with platform specific defines
`PLAFORM_xxx` which is not consistent

Misra Rule 10.4:
The value of a complex expression of integer type may only be cast to
a type that is narrower and of the same signedness as the underlying
type of the expression.

Based on above points, cpu_idx is kept as `unsigned int` to match
the API's and low-level functions and platform defines are updated
where ever required
Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com>
Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c

This patch removes re-definition of the following FVP build
options from plat\arm\board\fvp\fvp_def.h:
 'FVP_CLUSTER_COUNT'
 'FVP_MAX_CPUS_PER_CLUSTER'
 'FVP_MAX_PE_PER_CPU'
which are set in platform.mk.

This fixes a potential problem when a build option set in
platform.mk file can be re-defined in fvp_def.h header file
used by other build component with a different makefile which
does not set this option.
Ref. GENFW-3505.

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

The reclaim init code functionality relies on forward reference in the
linker script. The LLVM linker does not process it correctly.

Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>

Point boot address to DDR location for booting A5DS FPGA
FIP, Kernel and rootfs are sideloaded to DDR
Also move BL2 to higher address in DDR

Change-Id: Ia2a57a0bda776a1a0a96bcd3cfb5c6cd2cf4dc04
Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>

Correct the system, timer and uart frequencies to successfully run
the stack on FPGA
Correct Cortex-A5MPcore to 8 word granularity for Cache writeback

Change-Id: I2c59c26b7dca440791ad39f2297c68ae513da7b6
Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>

The SCU connects one to four Cortex-A5/Cortex-A9 processors
to the memory system through the AXI interfaces.

The SCU functions are to:
- maintain data cache coherency between the Cortex-A5/Cortex-A9
  processors
- initiate L2 AXI memory accesses
- arbitrate between Cortex-A5/Cortex-A9 processors requesting
  L2 accesses
- manage ACP accesses.

Snoop Control Unit will enable to snoop on other CPUs caches.
This is very important when it comes to synchronizing data between
CPUs. As an example, there is a high chance that data might be
cache'd and other CPUs can't see the change. In such cases,
if snoop control unit is enabled, data is synchoronized immediately
between CPUs and the changes are visible to other CPUs.

This driver provides functionality to enable SCU as well as enabling
user to know the following
- number of CPUs present
- is a particular CPU operating in SMP mode or AMP mode
- data cache size of a particular CPU
- does SCU has ACP port
- is L2CPRESENT

Change-Id: I0d977970154fa60df57caf449200d471f02312a0
Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>

The contents of this header have been merged into the spm_mm_svc.h
header file.

Change-Id: I01530b2e4ec1b4c091ce339758025e2216e740a4
Signed-off-by: Paul Beesley <paul.beesley@arm.com>

Change-Id: I91c192924433226b54d33e57d56d146c1c6df81b
Signed-off-by: Paul Beesley <paul.beesley@arm.com>

Before adding any new SPM-related components we should first do
some cleanup around the existing SPM-MM implementation. The aim
is to make sure that any SPM-MM components have names that clearly
indicate that they are MM-related. Otherwise, when adding new SPM
code, it could quickly become confusing as it would be unclear to
which component the code belongs.

The secure_partition.h header is a clear example of this, as the
name is generic so it could easily apply to any SPM-related code,
when it is in fact SPM-MM specific.

This patch renames the file and the two structures defined within
it, and then modifies any references in files that use the header.

Change-Id: I44bd95fab774c358178b3e81262a16da500fda26
Signed-off-by: Paul Beesley <paul.beesley@arm.com>

The Secure Partition Manager (SPM) prototype implementation is
being removed. This is preparatory work for putting in place a
dispatcher component that, in turn, enables partition managers
at S-EL2 / S-EL1.

This patch removes:

- The core service files (std_svc/spm)
- The Resource Descriptor headers (include/services)
- SPRT protocol support and service definitions
- SPCI protocol support and service definitions

Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>

There are two different implementations of Secure Partition
management in TF-A. One is based on the "Management Mode" (MM)
design, the other is based on the Secure Partition Client Interface
(SPCI) specification. Currently there is a dependency between their
build flags that shouldn't exist, making further development
harder than it should be. This patch removes that
dependency, making the two flags function independently.

Before: ENABLE_SPM=1 is required for using either implementation.
        By default, the SPCI-based implementation is enabled and
        this is overridden if SPM_MM=1.

After: ENABLE_SPM=1 enables the SPCI-based implementation.
       SPM_MM=1 enables the MM-based implementation.
       The two build flags are mutually exclusive.

Note that the name of the ENABLE_SPM flag remains a bit
ambiguous - this will be improved in a subsequent patch. For this
patch the intention was to leave the name as-is so that it is
easier to track the changes that were made.

Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a
Signed-off-by: Paul Beesley <paul.beesley@arm.com>

This patch fixes the bug in BL2 dynamic configuration initialisation
which prevents loading NT_FW_CONFIG image (ref. GENFW-3471).
It also adds parentheses around 'if' statement conditions to fix
Coverity defect.

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

Provide an SMC interface to the 9p filesystem. This permits
accessing firmware drivers through a common interface, using
standardized read/write/control operations.
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I9314662314bb060f6bc02714476574da158b2a7d

Ported the pmf asm macros and the asm code in the bl31 entrypoint
necessary for the instrumentation to AArch32.

Since smc dispatch is handled by the bl32 payload on AArch32, we
provide this service only if AARCH32_SP=sp_min is set.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Change-Id: Id33b7e9762ae86a4f4b40d7f1b37a90e5130c8ac

Switching execution states is only possible if EL3 is AArch64.
As such there is no need to validate the entrypoint on AArch32 builds.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Change-Id: I3c1eb25b5df296a492870641d274bf65213c6608

C99 standard: "What constitutes an access to an object that has
volatile-qualified type is implementation-defined".

GCC is not considering the cast to void of volatile structures as an
access and so is not actually issuing reads.

Clang does read those structures by copying them on the stack, which in
this case creates an overflow because of their large size.

This patch removes the cast to void and instead uses the USED attribute
to tell the compiler to retain the static variables.

Change-Id: I952b5056e3f6e91841e7ef9558434352710ab80d
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
	       Zelalem Aweke <zelalem.aweke@arm.com>

Previously the .init section was created even when the reclaim flag was
manually set to 0.

Change-Id: Ia9e7c7997261f54a4eca725d7ea605192f60bcf8
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
	       Zelalem Aweke <zelalem.aweke@arm.com>

Currently tb_fw_cfg_dtb size is fixed to max, which is generally a page
(but depend on the platform). Instead, read the actual size of the dtb
with the libfdt "fdt_totalsize" function.
This avoid flushing extra memory after updating the dtb with mbedtls
heap information when shared heap is used.

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

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

ROMLIB extract functions code from BL images to put them inside ROM.
This has for effect to reduce the size of the BL images.

This patch take this size reduction into consideration to optimize the
memory layout of BL2.
A new "PLAT_ARM_BL2_ROMLIB_OPTIMIZATION" macro is defined and used to
reduce "PLAT_ARM_MAX_BL2_SIZE". This allows to remove the gap between
BL1 and BL2 when ROMLIB is used and provides more room for BL31.

The current memory gain is 0x6000 for fvp and 0x8000 for juno.

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