| 9a3088a5 | 09-Nov-2017 |
Qixiang Xu <qixiang.xu@arm.com> |
tbbr: Add build flag HASH_ALG to let the user to select the SHA
The flag support the following values: - sha256 (default) - sha384 - sha512
Change-Id: I7a49d858c361e993949cf6ada0a86575c
tbbr: Add build flag HASH_ALG to let the user to select the SHA
The flag support the following values: - sha256 (default) - sha384 - sha512
Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066 Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
show more ...
|
| c776deed | 13-Oct-2017 |
Dimitris Papastamos <dimitris.papastamos@arm.com> |
Change Statistical Profiling Extensions build option handling
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_AR
Change Statistical Profiling Extensions build option handling
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>
show more ...
|
| b7cb133e | 16-Oct-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
BL31: Add SDEI dispatcher
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1].
Introduce the build o
BL31: Add SDEI dispatcher
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1].
Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31.
Update user guide and porting guide. SDEI documentation to follow.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| 21b818c0 | 22-Sep-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
BL31: Introduce Exception Handling Framework
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3.
This framework facilitates the firmware-first error ha
BL31: Introduce Exception Handling Framework
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3.
This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs.
The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller.
This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns.
Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1.
Documentation to follow.
NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later).
Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| 9500d5a4 | 09-Nov-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #1148 from antonio-nino-diaz-arm/an/spm
Introduce Secure Partition Manager |
| 2fccb228 | 24-Oct-2017 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
SPM: Introduce Secure Partition Manager
A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL
SPM: Introduce Secure Partition Manager
A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources:
- Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers.
A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex.
The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following:
- Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request.
Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
show more ...
|
| 86e26835 | 08-Nov-2017 |
Etienne Carriere <etienne.carriere@linaro.org> |
ARMv7 may not support Generic Timer Extension
If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_GENERIC_TIMER to enable generic timer support.
Signed-off-
ARMv7 may not support Generic Timer Extension
If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_GENERIC_TIMER to enable generic timer support.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| 64cc6e91 | 08-Nov-2017 |
Etienne Carriere <etienne.carriere@linaro.org> |
ARMv7 may not support Virtualization Extensions
ARMv7-A Virtualization extensions brings new instructions and resources that were supported by later architectures. Reference ARM ARM Issue C.c [DDI04
ARMv7 may not support Virtualization Extensions
ARMv7-A Virtualization extensions brings new instructions and resources that were supported by later architectures. Reference ARM ARM Issue C.c [DDI0406C_C].
ERET and extended MSR/MRS instructions, as specified in [DDI0406C_C] in ID_PFR1 description of bits[15:12] (Virtualization Extensions): A value of 0b0001 implies implementation of the HVC, ERET, MRS (Banked register), and MSR (Banked register) instructions. The ID_ISARs do not identify whether these instructions are implemented.
UDIV/SDIV were introduced with the Virtualization extensions, even if not strictly related to the virtualization extensions.
If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_VIRTUALIZATION to enable virtualization extension related resources.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| 51b992ec | 08-Nov-2017 |
Etienne Carriere <etienne.carriere@linaro.org> |
ARMv7 may not support large page addressing
ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to handle specific case when target ARMv7 core only supports 32bit MMU descriptor mode.
If A
ARMv7 may not support large page addressing
ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to handle specific case when target ARMv7 core only supports 32bit MMU descriptor mode.
If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_LARGE_PAGE_ADDRESSING to enable large page addressing support.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| 26e63c44 | 08-Nov-2017 |
Etienne Carriere <etienne.carriere@linaro.org> |
ARMv7 target is driven by ARM_ARCH_MAJOR==7
External build environment shall sets directive ARM_ARCH_MAJOR to 7 to specify a target ARMv7-A core.
As ARM-TF expects AARCH to be set, ARM_ARCH_MAJOR==
ARMv7 target is driven by ARM_ARCH_MAJOR==7
External build environment shall sets directive ARM_ARCH_MAJOR to 7 to specify a target ARMv7-A core.
As ARM-TF expects AARCH to be set, ARM_ARCH_MAJOR==7 mandates AARCH=aarch32.
The toolchain target architecture/cpu is delegated after the platform configuration is parsed. Platform shall define target core through ARM_CORTEX_A<x>=yes, <x> being 5, 7, 9, 12, 15 and/or 17.
Platform can bypass ARM_CORTEX_A<x>=yes directive and provide straight the toolchain target directive through MARCH32_DIRECTIVE.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| 8012cc5c | 03-Nov-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Build: introduce ${BUILD_PLAT} target to create the top build directory
Some platforms (for ex. UniPhier) want to create files in the very top of the build directory. Add ${BUILD_PLAT} so such file
Build: introduce ${BUILD_PLAT} target to create the top build directory
Some platforms (for ex. UniPhier) want to create files in the very top of the build directory. Add ${BUILD_PLAT} so such files can depend on it.
Make existing directory targets depend on ${BUILD_PLAT} because they are sub-directories of ${BUILD_PLAT}.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 74dce7fa | 22-Sep-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
GIC: Add APIs to set interrupt type and query support
The back end GIC driver converts and assigns the interrupt type to suitable group.
For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, wh
GIC: Add APIs to set interrupt type and query support
The back end GIC driver converts and assigns the interrupt type to suitable group.
For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which determines to which type Group 0 interrupts maps to.
- When the build option is set 0 (the default), Group 0 interrupts are meant for Secure EL1. This is presently the case.
- Otherwise, Group 0 interrupts are meant for EL3. This means the SPD will have to synchronously hand over the interrupt to Secure EL1.
The query API allows the platform to query whether the platform supports interrupts of a given type.
API documentation updated.
Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858 Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| 03b397a8 | 14-Oct-2016 |
Nishanth Menon <nm@ti.com> |
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 ...
|
| 2091755c | 31-Aug-2017 |
Soby Mathew <soby.mathew@arm.com> |
Export KEY_ALG as a user build option
The `KEY_ALG` variable is used to select the algorithm for key generation by `cert_create` tool for signing the certificates. This variable was previously undoc
Export KEY_ALG as a user build option
The `KEY_ALG` variable is used to select the algorithm for key generation by `cert_create` tool for signing the certificates. This variable was previously undocumented and did not have a global default value. This patch corrects this and also adds changes to derive the value of `TF_MBEDTLS_KEY_ALG` based on `KEY_ALG` if it not set by the platform. The corresponding assignment of these variables are also now removed from the `arm_common.mk` makefile.
Signed-off-by: Soby Mathew <soby.mathew@arm.com> Change-Id: I78e2d6f4fc04ed5ad35ce2266118afb63127a5a4
show more ...
|
| 1a52aca5 | 14-Aug-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #1040 from sliai/support-opteed-header
Support opteed header |
| 71fb3964 | 20-Apr-2017 |
Summer Qin <summer.qin@arm.com> |
Support Trusted OS firmware extra images in TF tools
Since Trusted OS firmware may have extra images, need to assign new uuid and image id for them. The TBBR chain of trust has been extended to add
Support Trusted OS firmware extra images in TF tools
Since Trusted OS firmware may have extra images, need to assign new uuid and image id for them. The TBBR chain of trust has been extended to add support for the new images within the existing Trusted OS firmware content certificate.
Change-Id: I678dac7ba1137e85c5779b05e0c4331134c10e06 Signed-off-by: Summer Qin <summer.qin@arm.com>
show more ...
|
| e33fd445 | 19-Jul-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
CCI: Adapt for specific product at run time
The current build system and driver requires the CCI product to be specified at build time. The device constraints can be determined at run time from its
CCI: Adapt for specific product at run time
The current build system and driver requires the CCI product to be specified at build time. The device constraints can be determined at run time from its ID registers, obviating the need for specifying them ahead.
This patch adds changes to identify and validate CCI at run time. Some global variables are renamed to be in line with the rest of the code base.
The build option ARM_CCI_PRODUCT_ID is now removed, and user guide is updated.
Change-Id: Ibb765e349d3bc95ff3eb9a64bde1207ab710a93d Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| 048531d7 | 10-May-2017 |
Soby Mathew <soby.mathew@arm.com> |
Add support to link an external lib with ARM TF
This patch defines the variable `LDLIBS` which allows external libraries to be specified to 'ld' to enable it to link the libraries.
Change-Id: I02a4
Add support to link an external lib with ARM TF
This patch defines the variable `LDLIBS` which allows external libraries to be specified to 'ld' to enable it to link the libraries.
Change-Id: I02a490eca1074063d00153ccb0ee974ef8859a0e Signed-off-by: Soby Mathew <soby.mathew@arm.com>
show more ...
|
| c2b8806f | 22-Jun-2017 |
Douglas Raillard <douglas.raillard@arm.com> |
Introduce TF_LDFLAGS
Use TF_LDFLAGS from the Makefiles, and still append LDFLAGS as well to the compiler's invocation. This allows passing extra options from the make command line using LDFLAGS.
Do
Introduce TF_LDFLAGS
Use TF_LDFLAGS from the Makefiles, and still append LDFLAGS as well to the compiler's invocation. This allows passing extra options from the make command line using LDFLAGS.
Document new LDFLAGS Makefile option.
Change-Id: I88c5ac26ca12ac2b2d60a6f150ae027639991f27 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
show more ...
|
| d832aee9 | 23-May-2017 |
dp-arm <dimitris.papastamos@arm.com> |
aarch64: Enable Statistical Profiling Extensions for lower ELs
SPE is only supported in non-secure state. Accesses to SPE specific registers from SEL1 will trap to EL3. During a world switch, befo
aarch64: Enable Statistical Profiling Extensions for lower ELs
SPE is only supported in non-secure state. Accesses to SPE specific registers from SEL1 will trap to EL3. During a world switch, before `TTBR` is modified the SPE profiling buffers are drained. This is to avoid a potential invalid memory access in SEL1.
SPE is architecturally specified only for AArch64.
Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| 79eb1aff | 12-May-2017 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Remove `DISABLE_PEDANTIC` build option
It doesn't make sense to use the `-pedantic` flag when building the Trusted Firmware as we use GNU extensions and so our code is not fully ISO C compliant. Thi
Remove `DISABLE_PEDANTIC` build option
It doesn't make sense to use the `-pedantic` flag when building the Trusted Firmware as we use GNU extensions and so our code is not fully ISO C compliant. This flag only makes sense if the code intends to be ISO C compliant.
Change-Id: I6273564112759ff57f03b273f5349733a5f38aef Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
show more ...
|
| e715e676 | 24-May-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #938 from masahir0y/tools_share
Collect headers shared between TF and host-tools into include/tools_share |
| bb41eb7a | 22-May-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide a
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide any value (at least technically).
For easier use of TBBR, this commit allows platforms to reuse the OIDs obtained by ARM Ltd. This will be useful for non-ARM vendors that do not need their own extension fields in their certificate files.
The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the backward compatibility.
For clarification, I inserted a blank line between headers from the include/ directory (#include <...>) and ones from a local directory (#include "..." ).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| be4cd40e | 23-May-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Build: fix assert_boolean implementation
The current assert_boolean does not work with variables assigned with '=' flavor instead of ':='.
For example,
FOO = $(BAR) BAR := 1
Here, $(value FOO)
Build: fix assert_boolean implementation
The current assert_boolean does not work with variables assigned with '=' flavor instead of ':='.
For example,
FOO = $(BAR) BAR := 1
Here, $(value FOO) is evaluated to $(BAR), not 1. This is not what we expect. While I am here, I simplified the implementation.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| a4409008 | 15-Feb-2017 |
dp-arm <dimitris.papastamos@arm.com> |
AArch32: Add `TRUSTED_BOARD_BOOT` support
This patch adds `TRUSTED_BOARD_BOOT` support for AArch32 mode.
To build this patch the "mbedtls/include/mbedtls/bignum.h" needs to be modified to remove `#
AArch32: Add `TRUSTED_BOARD_BOOT` support
This patch adds `TRUSTED_BOARD_BOOT` support for AArch32 mode.
To build this patch the "mbedtls/include/mbedtls/bignum.h" needs to be modified to remove `#define MBEDTLS_HAVE_UDBL` when `MBEDTLS_HAVE_INT32` is defined. This is a workaround for "https://github.com/ARMmbed/mbedtls/issues/708"
NOTE: TBBR support on Juno AArch32 is not currently supported.
Change-Id: I86d80e30b9139adc4d9663f112801ece42deafcf Signed-off-by: dp-arm <dimitris.papastamos@arm.com> Co-Authored-By: Yatharth Kochar <yatharth.kochar@arm.com>
show more ...
|