Previously the cache flush happened in 2 different places in code
depending on whether TRUSTED_BOARD_BOOT is enabled or not. This
patch unifies this code path for both the cases. The `load_image()`
function is now made an internal static function.
Change-Id: I96a1da29d29236bbc34b1c95053e6a9a7fc98a54
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
This patch allows non-secure bus masters to access TZC region0 as well
as the EL3 Payload itself.
Change-Id: I7e44f2673a2992920d41503fb4c57bd7fb30747a
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
The defines have been renamed to match the names used in the
documentation.
Change-Id: I2f18b65112d2db040a89d5a8522e9790c3e21628
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This includes the stdint header to declare the various types used within
the file, preventing build errors with recent GCC versions.
Change-Id: I9e7e92bb31deb58d4ff2732067dd88b53124bcc9
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Added design documentation and usage guide for the AArch64 port of the
Arm Trusted Firmware to the Raspberry Pi 3.
Change-Id: I1be60fbbd54c797b48a1bcebfb944d332616a0de
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This port can be compiled to boot an AArch64 or AArch32 payload with the
build option `RPI3_BL33_AARCH32`.
Note: This is not a secure port of the Trusted Firmware. This port is
only meant to be a reference implementation to experiment with an
inexpensive board in real hardware.
Change-Id: Ide58114299289bf765ef1366199eb05c46f81903
Co-authored-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Pre-v8.2 platforms such as the Juno platform does not have
the Scalable Vector Extensions implemented and so the build
option ENABLE_SVE is set to zero.
This has a minor performance improvement with no functional
impact.
Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1
Signed-off-by: David Cunado <david.cunado@arm.com>
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>
This patch updates Xilinx maintainers details
as sorenb is no more the maintainer for xilinx
and the email id is invalid now.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
The bl2_early_platform_setup() and bl2_platform_setup() were
redefined for Juno AArch32 eventhough CSS platform layer had
same definition for them. The CSS definitions definitions were
previously restricted to EL3_PAYLOAD_BASE builds and this is now
modified to include the Juno AArch32 builds as well thus
allowing us to remove the duplicate definitions in Juno platform
layer.
Change-Id: Ibd1d8c1428cc1d51ac0ba90f19f5208ff3278ab5
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
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>
When defining different sections in linker scripts it is needed to align
them to multiples of the page size. In most linker scripts this is done
by aligning to the hardcoded value 4096 instead of PAGE_SIZE.
This may be confusing when taking a look at all the codebase, as 4096
is used in some parts that aren't meant to be a multiple of the page
size.
Change-Id: I36c6f461c7782437a58d13d37ec8b822a1663ec1
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The `ENABLE_AMU` build option can be used to enable the
architecturally defined AMU counters. At present, there is no support
for the auxiliary counter group.
Change-Id: Ifc7532ef836f83e629f2a146739ab61e75c4abc8
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
The `ENABLE_AMU` build option can be used to enable the
architecturally defined AMU counters. At present, there is no support
for the auxiliary counter group.
Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
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>
Commit 26e63c4450 broke the Makefile for ARMv8-A AArch32 platforms.
This patch fixes it.
Change-Id: I49b8eb5b88f3a131aa4c8642ef970e92d90b6dd2
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
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>
Set alignment size to 512B so finally we can get fip.bin with 512B
alignment. This can avoid stuck issue for 'fastboot' downloading
if USB driver uses DMA for data transferring.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Set alignment size to 512B so finally we can get fip.bin with 512B
alignment. This can avoid stuck issue for 'fastboot' downloading if
USB driver uses DMA for data transferring.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
The flag support the following values:
- sha256 (default)
- sha384
- sha512
Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
This option enables the user to select the secure hash algorithm
to be used for generating the hash. It supports the following
options:
- sha256 (default)
- sha384
- sha512
Change-Id: Icb093cec1b5715e248c3d1c3749a2479a7ab4b89
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
There is an edge case where the cache maintaince done in
psci_do_cpu_off may not seen by some cores. This case is handled in
psci_cpu_on_start but it hasn't handled in psci_affinity_info.
Change-Id: I4d64f3d1ca9528e364aea8d04e2d254f201e1702
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Factor out SPE operations in a separate file. Use the publish
subscribe framework to drain the SPE buffers before entering secure
world. Additionally, enable SPE before entering normal world.
A side effect of this change is that the profiling buffers are now
only drained when a transition from normal world to secure world
happens. Previously they were drained also on return from secure
world, which is unnecessary as SPE is not supported in S-EL1.
Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
It is not possible to detect at compile-time whether support for an
optional extension such as SPE should be enabled based on the
ARM_ARCH_MINOR build option value. Therefore SPE is now enabled by
default.
Change-Id: I670db164366aa78a7095de70a0962f7c0328ab7c
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
Factor out extension enabling to a separate function that is called
before exiting from EL3 for first entry into Non-secure world.
Change-Id: Ic21401ebba531134d08643c0a1ca9de0fc590a1b
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
The explicit event dispatch sequence currently depicts handling done in
Secure EL1, although further error handling is typically done inside a
Secure Partition. Clarify the sequence diagram to that effect.
Change-Id: I53deedc6d5ee0706626890067950c2c541a62c78
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The SDEI specification requires that binding a client interrupt
dispatches SDEI Normal priority event. This means that dynamic events
can't have Critical priority. Add asserts for this.
Change-Id: I0bdd9e0e642fb2b61810cb9f4cbfbd35bba521d1
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Register count is currently declared as unsigned, where as there are
asserts in place to check it being negative during unregister. These are
flagged as never being true.
Change-Id: I34f00f0ac5bf88205791e9c1298a175dababe7c8
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
If an implementation of ARMv8.2 includes ARMv8.2-LPA, the value 0b0110
is permitted in ID_AA64MMFR0_EL1.PARange, which means that the Physical
Address range supported is 52 bits (4 PiB). It is a reserved value
otherwise.
Change-Id: Ie0147218e9650aa09f0034a9ee03c1cca8db908a
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The FPEXC32_EL2 register controls SIMD and FP functionality when the
lower ELs are executing in AArch32 mode. It is architecturally mapped
to AArch32 system register FPEXC.
This patch removes FPEXC32_EL2 register from the System Register context
and adds it to the floating-point context. EL3 only saves / restores the
floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1.
The rationale for this change is that if the Secure world is using FP
functionality and EL3 is not managing the FP context, then the Secure
world will save / restore the appropriate FP registers.
NOTE - this is a break in behaviour in the unlikely case that
CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32
Secure Payload that modifies FPEXC, but does not save and restore
this register
Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184
Signed-off-by: David Cunado <david.cunado@arm.com>
The parameters passed to the Secure world from the Secure Partition
Manager when invoking SP_COMMUNICATE_AARCH32/64 were incorrect, as well
as the checks done on them.
Change-Id: I26e8c80cad0b83437db7aaada3d0d9add1c53a78
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The code was incorrectly reading from ID_AA64PRF0_EL1 instead of
ID_AA64MMFR0_EL1 causing the supported granularity sizes returned by the
code to be wrong.
This wasn't causing any problem because it's just used to check the
alignment of the base of the buffer shared between Non-secure and Secure
worlds, and it was aligned to more than 64 KiB, which is the maximum
granularity supported by the architecture.
Change-Id: Icc0d949d9521cc0ef13afb753825c475ea62d462
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>