The CPUACTLR_EL1 register on Cortex-A57 CPUs supports a bit to enable
non-cacheable streaming enhancement. Platforms can set this bit only
if their memory system meets the requirement that cache line fill
requests from the Cortex-A57 processor are atomic.
This patch adds support to enable higher performance non-cacheable load
forwarding for such platforms. Platforms must enable this support by
setting the 'A57_ENABLE_NONCACHEABLE_LOAD_FWD' flag from their
makefiles. This flag is disabled by default.
board/rdn1edge: use CREATE_SEQ helper macro to compare chip count
Use CREATE_SEQ helper macro to create sequence of valid chip counts
instead of manually creating the sequence. This allows a scalable
approach to increase the valid chip count sequence in the future.
Add `CREATE_SEQ` function to generate sequence of numbers starting from
1 to allow easy comparison of a user defined macro with non-zero
positive numbers.
Rui Silva [Wed, 9 Oct 2019 11:54:30 +0000 (12:54 +0100)]
corstone700: fdts: using DDR memory and XIP rootfs
This patch allows to use DDR address in memory node because on FPGA we
typically use DDR instead of shared RAM.
This patch also modifies the kernel arguments to allow the rootfs to be
mounted from a direct mapping of the QSPI NOR flash using the physmap
driver in the kernel. This allows to support CRAMFS XIP.
Zelalem [Wed, 12 Feb 2020 16:37:03 +0000 (10:37 -0600)]
coverity: fix MISRA violations
Fixes for the following MISRA violations:
- Missing explicit parentheses on sub-expression
- An identifier or macro name beginning with an
underscore, shall not be declared
- Type mismatch in BL1 SMC handlers and tspd_main.c
Mark Dykes [Tue, 18 Feb 2020 16:24:33 +0000 (16:24 +0000)]
Merge changes I4e95678f,Ia7c28704,I1bb04bb4,I93d96dca,I50aef5dd into integration
* changes:
Fix boot failures on some builds linked with ld.lld.
trusty: generic-arm64-smcall: Support gicr address
trusty: Allow gic base to be specified with GICD_BASE
trusty: Allow getting trusty memsize from BL32_MEM_SIZE instead of TSP_SEC_MEM_SIZE
Fix clang build if CC is not in the path.
Alexei Fedorov [Mon, 17 Feb 2020 13:38:35 +0000 (13:38 +0000)]
FVP: Fix BL31 load address and image size for RESET_TO_BL31=1
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.
The TBBR implementation extracts hashes from certificates and stores
them in static buffers. TF-A supports 3 variants of SHA right now:
SHA-256, SHA-384 and SHA-512. When support for SHA-512 was added in
commit 9a3088a5f509084e60d9c55bf53985c5ec4ca821 ("tbbr: Add build flag
HASH_ALG to let the user to select the SHA"), the hash buffers got
unconditionally increased from 51 to 83 bytes each. We can reduce that
space if we're using SHA-256 or SHA-384.
This saves some BSS space in both BL1 and BL2:
- BL1 with SHA-256: saving 168 bytes.
- BL1 with SHA-384: saving 80 bytes.
- BL2 with SHA-256: saving 384 bytes.
- BL2 with SHA-384: saving 192 bytes.
The TBBR implementation extracts public keys from certificates and
stores them in static buffers. DER-encoded ECDSA keys are only 91 bytes
each but were each allocated 294 bytes instead. Reducing the size of
these buffers saves 609 bytes of BSS in BL2 (294 - 91 = 203 bytes for
each of the 3 key buffers in use).
Also add a comment claryfing that key buffers are tailored on RSA key
sizes when both ECDSA and RSA keys are used.
Khandelwal [Wed, 29 Jan 2020 16:51:42 +0000 (16:51 +0000)]
Corstone700: add support for mhuv2 in arm TF-A
Note: This patch implements in-band messaging protocol only.
ARM has launched a next version of MHU i.e. MHUv2 with its latest
subsystems. The main change is that the MHUv2 is now a distributed IP
with different peripheral views (registers) for the sender and receiver.
Another main difference is that MHUv1 duplex channels are now split into
simplex/half duplex in MHUv2. MHUv2 has a configurable number of
communication channels. There is a capability register (MSG_NO_CAP) to
find out how many channels are available in a system.
The register offsets have also changed for STAT, SET & CLEAR registers
from 0x0, 0x8 & 0x10 in MHUv1 to 0x0, 0xC & 0x8 in MHUv2 respectively.
0x0 0x4 0x8 0xC 0x1F
------------------------....-----
| STAT | | | SET | | |
------------------------....-----
Transmit Channel
The MHU controller can request the receiver to wake-up and once the
request is removed, the receiver may go back to sleep, but the MHU
itself does not actively put a receiver to sleep.
So, in order to wake-up the receiver when the sender wants to send data,
the sender has to set ACCESS_REQUEST register first in order to wake-up
receiver, state of which can be detected using ACCESS_READY register.
ACCESS_REQUEST has an offset of 0xF88 & ACCESS_READY has an offset
of 0xF8C and are accessible only on any sender channel.
This patch adds necessary changes in a new file required to support the
latest MHUv2 controller. This patch also needs an update in DT binding
for ARM MHUv2 as we need a second register base (tx base) which would
be used as the send channel base.
Merge changes from topic "uniphier" into integration
* changes:
uniphier: make I/O register region configurable
uniphier: make PSCI related base address configurable
uniphier: make counter control base address configurable
uniphier: make UART base address configurable
uniphier: make pinmon base address configurable
uniphier: make NAND controller base address configurable
uniphier: make eMMC controller base address configurable
Fix topology description of cpus for DynamIQ based FVP
DynamIQ based designs have upto 8 CPUs in each cluster. This
patch fixes the device tree node which describes the topology
of the CPU for DynamIQ FVP Model.
corstone700: adding support for stack protector for the FVP
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>
Merge changes from topic "uniphier" into integration
* changes:
uniphier: extend boot device detection for future SoCs
uniphier: change block_addressing flag to bool
uniphier: change the return value type of .is_usb_boot() to bool
Fix boot failures on some builds linked with ld.lld.
Pad the .rodata section to 16 bytes as ld.lld does not apply the ALIGN
statement on the .data section to the LMA. Fixes boot failure on builds
where the .rodata section happens to not be 16 bytes aligned.
Arve Hjønnevåg [Fri, 15 Nov 2019 22:25:43 +0000 (14:25 -0800)]
trusty: generic-arm64-smcall: Support gicr address
Add SMC_GET_GIC_BASE_GICR option to SMC_FC_GET_REG_BASE and
SMC_FC64_GET_REG_BASE calls for returning the base address of the gic
redistributor added in gic version 3.
Masahiro Yamada [Mon, 3 Feb 2020 09:40:37 +0000 (18:40 +0900)]
uniphier: change block_addressing flag to bool
The flag, uniphier_emmc_block_addressing, is boolean logic, so
"bool' is more suitable.
uniphier_emmc_is_over_2gb() is not boolean - it returns 1 / 0
depending on the card density, or a negative value on failure.
Rename it to make it less confusing.
Max Shvetsov [Tue, 11 Feb 2020 12:41:08 +0000 (12:41 +0000)]
Fixes ROTPK hash generation for ECDSA encryption
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
Olivier Deprez [Tue, 11 Feb 2020 08:34:47 +0000 (08:34 +0000)]
Merge changes from topic "spmd" into integration
* changes:
SPMD: enable SPM dispatcher support
SPMD: hook SPMD into standard services framework
SPMD: add SPM dispatcher based upon SPCI Beta 0 spec
SPMD: add support to run BL32 in TDRAM and BL31 in secure DRAM on Arm FVP
SPMD: add support for an example SPM core manifest
SPMD: add SPCI Beta 0 specification header file
Achin Gupta [Fri, 11 Oct 2019 14:49:00 +0000 (15:49 +0100)]
SPMD: hook SPMD into standard services framework
This patch adds support to initialise the SPM dispatcher as a standard
secure service. It also registers a handler for SPCI SMCs exported by
the SPM dispatcher.
Achin Gupta [Fri, 11 Oct 2019 14:41:16 +0000 (15:41 +0100)]
SPMD: add SPM dispatcher based upon SPCI Beta 0 spec
This patch adds a rudimentary SPM dispatcher component in EL3.
It does the following:
- Consumes the TOS_FW_CONFIG to determine properties of the SPM core
component
- Initialises the SPM core component which resides in the BL32 image
- Implements a handler for SPCI calls from either security state. Some
basic validation is done for each call but in most cases it is simply
forwarded as-is to the "other" security state.
Achin Gupta [Fri, 11 Oct 2019 14:15:19 +0000 (15:15 +0100)]
SPMD: add support to run BL32 in TDRAM and BL31 in secure DRAM on Arm FVP
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.
Achin Gupta [Fri, 11 Oct 2019 13:54:48 +0000 (14:54 +0100)]
SPMD: add support for an example SPM core manifest
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.
Manish Pandey [Mon, 10 Feb 2020 13:32:43 +0000 (13:32 +0000)]
Merge changes from topics "rddaniel", "rdn1edge_dual" into integration
* changes:
plat/arm: add board support for rd-daniel platform
plat/arm/sgi: move GIC related constants to board files
platform/arm/sgi: add multi-chip mode parameter in HW_CONFIG dts
board/rdn1edge: add support for dual-chip configuration
drivers/arm/scmi: allow use of multiple SCMI channels
drivers/mhu: derive doorbell base address
plat/arm/sgi: include AFF3 affinity in core position calculation
plat/arm/sgi: add macros for remote chip device region
plat/arm/sgi: add chip_id and multi_chip_mode to platform variant info
plat/arm/sgi: move bl31_platform_setup to board file
Manish Pandey [Tue, 7 Jan 2020 17:05:28 +0000 (17:05 +0000)]
SPM: modify sptool to generate individual SP blobs
Currently sptool generates a single blob containing all the Secure
Partitions, with latest SPM implementation, it is desirable to have
individual blobs for each Secure Partition. It allows to leverage
packaging and parsing of SP on existing FIP framework. It also allows
SP packages coming from different sources.
This patch modifies sptool so that it takes number of SP payload pairs
as input and generates number of SP blobs instead of a single blob.
Each SP blob can optionally have its own header containing offsets and
sizes of different payloads along with a SP magic number and version.
It is also associated in FIP with a UUID, provided by SP owner.
Alexei Fedorov [Thu, 6 Feb 2020 17:11:03 +0000 (17:11 +0000)]
Make PAC demangling more generic
At the moment, address demangling is only used by the backtrace
functionality. However, at some point, other parts of the TF-A
codebase may want to use it.
The 'demangle_address' function is replaced with a single XPACI
instruction which is also added in 'do_crash_reporting()'.
board/rde1edge: fix incorrect topology tree description
RD-E1-Edge platform consists of two clusters with eight CPUs each and
two processing elements (PE) per CPU. Commit a9fbf13e049e (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.
plat/arm/sgi: move GIC related constants to board files
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.
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
board/rdn1edge: add support for dual-chip configuration
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
Aditya Angadi [Tue, 31 Dec 2019 08:53:53 +0000 (14:23 +0530)]
drivers/arm/scmi: allow use of multiple SCMI channels
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.
Aditya Angadi [Tue, 31 Dec 2019 04:44:32 +0000 (10:14 +0530)]
drivers/mhu: derive doorbell base address
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.
plat/arm/sgi: include AFF3 affinity in core position calculation
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.
plat/arm/sgi: add macros for remote chip device region
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.
plat/arm/sgi: add chip_id and multi_chip_mode to platform variant info
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.
Louis Mayencourt [Thu, 24 Oct 2019 14:18:46 +0000 (15:18 +0100)]
fconf: Move platform io policies into fconf
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>
Louis Mayencourt [Tue, 17 Dec 2019 13:17:25 +0000 (13:17 +0000)]
fconf: Add dynamic config DTBs info as property
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>
projects / arm-tf.git / log