- 18 Jun, 2018 1 commit
-
-
Jeenu Viswambharan authored
To build with the new release, we pick couple of more files from mbedTLS library. Change-Id: I77dfe5723284cb26d4e5c717fb0e6f6dd803cb6b Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 14 Jun, 2018 1 commit
-
-
Daniel Boulby authored
Changed the ordering of the log levels in the documentation to mate the code Change-Id: Ief1930b73d833fdf675b039c98046591c0c264c1 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 11 Jun, 2018 1 commit
-
-
Dimitris Papastamos authored
For the BL2_AT_EL3 configuration, move BL2 higher up to make more space for BL31. Adjust the BL31 limit to be up to BL2 base. This is because BL2 is always resident for the BL2_AT_EL3 configuration and thus we cannot overlay it with BL31. Change-Id: I71e89863ed48f5159e8b619f49c7c73b253397aa Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 07 Jun, 2018 2 commits
-
-
Soby Mathew authored
This patch updates the firmware design guide for the BL memory layout change on ARM platforms. Change-Id: Icbfe7249484bb8b4ba3c94421172d42f27605c52 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 24 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
BL31 is running out of space, and the use-case of SPM doesn't require it to be in SRAM. To prevent BL31 from running out of space in the future, move BL31 to DRAM if SPM is enabled. Secure Partition Manager design document updated to reflect the changes. Increased the size of the stack of BL31 for builds with SPM. The translation tables used by SPM in Arm platforms have been moved back to the 'xlat_tables' region instead of 'arm_el3_tzc_dram'. Everything is in DRAM now, so it doesn't make sense to treat them in a different way. Change-Id: Ia6136c8e108b8da9edd90e9d72763dada5e5e5dc Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 May, 2018 2 commits
-
-
Dimitris Papastamos authored
Some CPUS may benefit from using a dynamic mitigation approach for CVE-2018-3639. A new SMC interface is defined to allow software executing in lower ELs to enable or disable the mitigation for their execution context. It should be noted that regardless of the state of the mitigation for lower ELs, code executing in EL3 is always mitigated against CVE-2018-3639. NOTE: This change is a compatibility break for any platform using the declare_cpu_ops_workaround_cve_2017_5715 macro. Migrate to the declare_cpu_ops_wa macro instead. Change-Id: I3509a9337ad217bbd96de9f380c4ff8bf7917013 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
For affected CPUs, this approach enables the mitigation during EL3 initialization, following every PE reset. No mechanism is provided to disable the mitigation at runtime. This approach permanently mitigates the entire software stack and no additional mitigation code is required in other software components. TF-A implements this approach for the following affected CPUs: * Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of `CPUACTLR_EL1` (`S3_1_C15_C2_0`). * Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the Technical Reference Manual (TRM)). * Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1` (`S3_0_C15_C1_0`). Additionally, a new SMC interface is implemented to allow software executing in lower ELs to discover whether the system is mitigated against CVE-2018-3639. Refer to "Firmware interfaces for mitigating cache speculation vulnerabilities System Software on Arm Systems"[0] for more information. [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 21 May, 2018 1 commit
-
-
Soby Mathew authored
From TF-A v1.5, FVP supports loading the kernel FDT through firmware as part of dynamic configuration feature. This means that the FDT no longer needs to be loaded via Model parameters. This patch updates the user guide to reflect the same. Change-Id: I79833beeaae44a1564f6512c3a473625e5959f65 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 18 May, 2018 1 commit
-
-
Soby Mathew authored
This patch allows platforms to dynamically disable authentication of images during cold boot. This capability is controlled via the DYN_DISABLE_AUTH build flag and is only meant for development purposes. Change-Id: Ia3df8f898824319bb76d5cc855b5ad6c3d227260 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 14 May, 2018 2 commits
-
-
Sandrine Bailleux authored
In the porting guide, fix the function name and the argument type to reflect the code. Change-Id: Iac8d69af403194de5586bc0d5890da531e3c8da2 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Antonio Nino Diaz authored
The instructions to boot the bootwrapped kernel were outdated. Also, the bootwrapped kernel boot flow isn't really useful. It was meant to be a replacement for the Trusted Firmware-A, not to be used as the next step during boot. The instructions have been removed in favour of the new build option ARM_LINUX_KERNEL_AS_BL33. This new system directly boots the Linux kernel from BL31, and requires RESET_TO_BL31 to be 1. Also, the kernel has to be preloaded in memory, so PRELOADED_BL33_BASE has to be set to its address. This way, the runtime services of the Trusted Firmware-A are available for the kernel in the least possible amount of time. This new system requires the DTB to be patched so that the kernel knows where the ramdisk is. A short script to add this information to the DTB has been added to the User Guide. The information related to it can be found in the following file in the Linux kernel tree: ``Documentation/devicetree/bindings/chosen.txt`` Change-Id: Ide135580959e09f6aa8e4425f37ea55d97439178 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
Normally, BL33 needs to contain a boot loader like U-Boot or UEFI that eventually gives control to the OS. However, in some cases, this boot sequence may be too slow. For example, when doing tests in a cycle-accurate emulator, the user may only be interested in the interaction between the Trusted Firmware and the OS, not in the boot process itself. The new option ARM_LINUX_KERNEL_AS_BL33 allows BL33 to contain the Linux kernel image by changing the value of registers x0-x3 to the values expected by the kernel. This option requires the device tree blob (DTB) to be present in memory. Its address must be specified in the newly introduced ARM_PRELOADED_DTB_BASE build option. For now, it only supports AArch64 kernels. This option is only available when RESET_TO_BL31=1. For this reason the BL33 binary must be preloaded in memory and PRELOADED_BL33_BASE must be used. For example, if the kernel is loaded at 0x80080000 and the DTB is loaded at address 0x82000000, the firmware could be built like this: CROSS_COMPILE=aarch64-linux-gnu- \ make PLAT=fvp DEBUG=1 \ RESET_TO_BL31=1 \ ARM_LINUX_KERNEL_AS_BL33=1 \ PRELOADED_BL33_BASE=0x80080000 \ ARM_PRELOADED_DTB_BASE=0x82000000 \ all fip Change-Id: If9dc847c65ae2d0c27b51f0fd44fc06b28497db9 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 04 May, 2018 2 commits
-
-
Jeenu Viswambharan authored
The ARMv8.4 RAS extensions introduce architectural support for software to inject faults into the system in order to test fault-handling software. This patch introduces the build option FAULT_HANDLING_SUPPORT to allow for lower ELs to use registers in the Standard Error Record to inject fault. The build option RAS_EXTENSIONS must also be enabled along with fault injection. This feature is intended for testing purposes only, and is advisable to keep disabled for production images. Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 23 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
Due to differences in the bitfields of the SMC IDs, it is not possible to support SMCCC 1.X and 2.0 at the same time. The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build option that specifies the major version of the SMCCC that the Trusted Firmware supports. The only two allowed values are 1 and 2, and it defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it. Note: Support for SMCCC v2.0 is an experimental feature to enable prototyping of secure partition specifications. Support for this convention is disabled by default and could be removed without notice. Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 10 Apr, 2018 2 commits
-
-
Summer Qin authored
Add TZMP1 support on Juno and increase the BL2 size accordingly due to the extra data structures to describe the TZC regions and the additional code. Signed-off-by: Summer Qin <summer.qin@arm.com>
-
Jiafei Pan authored
This patch introduce TF-A support for NXP's ls1043a platform. more details information of ls1043a chip and ls1043ardb board can be found at docs/plat/ls1043a.rst. Boot sequence on ls1043a is: bootrom loads bl1 firstly, then bl1 loads bl2, bl2 will load bl31, bl32 and bl33, bl31 will boot bl32(tee os) and bl33(u-boot or uefi), bl33 boot Linux kernel. Now TF-A on ls1043ardb platform has the following features in this patch: * Support boot from Nor flash. * TF-A can boot bl33 which runs in el2 of non-secure world. * TF-A boot OPTee OS. * Support PSCI Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com> Signed-off-by: Chenyin.Ha <Chenyin.Ha@nxp.com> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com> Signed-off-by: jiaheng.fan <jiaheng.fan@nxp.com> Signed-off-by: Wen He <wen.he_1@nxp.com>
-
- 07 Apr, 2018 1 commit
-
-
Jiafei Pan authored
In some use-cases BL2 will be stored in eXecute In Place (XIP) memory, like BL1. In these use-cases, it is necessary to initialize the RW sections in RAM, while leaving the RO sections in place. This patch enable this use-case with a new build option, BL2_IN_XIP_MEM. For now, this option is only supported when BL2_AT_EL3 is 1. Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
-
- 03 Apr, 2018 1 commit
-
-
Dimitris Papastamos authored
Only return -1 if the workaround for CVE-2017-5715 is not compiled in. Change-Id: I1bd07c57d22b4a13cf51b35be141a1f1ffb065ff Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 27 Mar, 2018 1 commit
-
-
Antonio Nino Diaz authored
Switch to the new console APIs enabled by setting MULTI_CONSOLE_API=1. The crash console doesn't use this API, it uses internally the core functions of the 16550 console. `bl31_plat_runtime_setup` is no longer needed. When this platform port was introduced, that function used to disable the console. It was needed to override that behaviour. The new behaviour is to switch to the runtime console. The console is registered for all scopes (boot, crash and runtime) in `rpi3_console_init` so it is not needed to override the default behaviour anymore. Update documentation. Change-Id: If2ee8f91044216183b7ef142e5c05ad6220ae92f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 21 Mar, 2018 1 commit
-
-
Antonio Nino Diaz authored
When the source code says 'SMCC' it is talking about the SMC Calling Convention. The correct acronym is SMCCC. This affects a few definitions and file names. Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S) but the old files have been kept for compatibility, they include the new ones with an ERROR_DEPRECATED guard. Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 20 Mar, 2018 1 commit
-
-
Joel Hutton authored
Following Out of Box testing for v1.5 release: Update host OS version to Ubuntu 16.04 Clarify configuration files needed for checkpatch Add note on using Linaro precompiled binaries Change-Id: Ia4ae61e01128ddff1a288972ddf84b79370fa52c Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
-
- 15 Mar, 2018 3 commits
-
-
David Cunado authored
The CI has been updated to run tests against the AEMv8-A RevC model, FVP_Base_RevC-2xAEMv8A, which is available from the Fast Model releases on Connected Community [1]. Additionally, the CI now also includes the Cortex-A55x4, Cortex-A75x4 and Cortex-A55x4-A75x4 Base models. [1] https://developer.arm.com/products/system-design/fixed-virtual-platforms Change-Id: I57806f3b2a8121211490a7aa0089dcae566d8635 Signed-off-by: David Cunado <david.cunado@arm.com>
-
David Cunado authored
Updated change-log.rst with summary of changes since release v1.4. Change-Id: I56b5a30d13a5a7099942535cbaeff0e2a5c5804e Signed-off-by: David Cunado <david.cunado@arm.com>
-
Dan Handley authored
Update Arm Trusted Firmware references in the upstream documents to Trusted Firmware-A (TF-A). This is for consistency with and disambiguation from Trusted Firmware-M (TF-M). Also update other Arm trademarks, e.g. ARM->Arm, ARMv8->Armv8-A. Change-Id: I8bb0e18af29c6744eeea2dc6c08f2c10b20ede22 Signed-off-by: Dan Handley <dan.handley@arm.com> Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 13 Mar, 2018 1 commit
-
-
Soby Mathew authored
This patch updates the `firmware-design.rst` document for changes in ARM-TF for supporting dynamic configuration features as presented in `Secure Firmware BoF SFO'17`[1]. The patch also updates the user-guide for 2 build options for FVP pertaining to dynamic config. [1] https://www.slideshare.net/linaroorg/bof-device-tree-and-secure-firmware-bof-sfo17310 Change-Id: Ic099cf41e7f1a98718c39854e6286d884011d445 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 05 Mar, 2018 3 commits
-
-
Arve Hjønnevåg authored
Change-Id: Ibfb75145e3a31ae2106eedfbe4a91c2e31bb9f2a
-
Haojian Zhuang authored
Since non-TF ROM is used in HiKey960 platform (Hisilicon Hi3660 SoC), replace BL1 by BL2_EL3 in normal boot mode. When flush images in recovery mode, keep to use BL1. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
-
Haojian Zhuang authored
Since non-TF ROM is used in HiKey platform (Hisilicon Hi6220 SoC), replace BL1 by BL2_EL3 in normal boot mode. When we recovery images in recovery mode, keep to use BL1. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
-
- 28 Feb, 2018 1 commit
-
-
Jeenu Viswambharan authored
FVPs that model DynamIQ configuration implements all CPUs in a single cluster. I.e., such models have a single cluster with more than 4 CPUs. This differs from existing default build configuration for FVP where up to 4 CPUs are assumed per cluster. To allow building for DynamIQ configuration, promote the macro FVP_MAX_CPUS_PER_CLUSTER as a build option to have it set from the build command line. The value of the build option defaults to 4. Change-Id: Idc3853bc95f680869b434b011c2dbd733e40c6ce Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 27 Feb, 2018 2 commits
-
-
David Cunado authored
MISRA C-2012 Rule 7.3 violation: lowercase l shall not be used as literal suffixes. This patch resolves this for the ULL() macro by using ULL suffix instead of the ull suffix. Change-Id: Ia8183c399e74677e676956e8653e82375d0e0a01 Signed-off-by: David Cunado <david.cunado@arm.com>
-
Jeenu Viswambharan authored
To make exception handling amongst Secure components, require that SDEI exception priorities must be assigned the lowest among Secure priorities. Clarify documentation to this effect. Change-Id: I92524b7b7e9b3fa06a10c86372bc3c4dd18c00ad Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 26 Feb, 2018 2 commits
-
-
Soby Mathew authored
The `bl1_init_bl2_mem_layout()` API is now deprecated. The default weak implementation of `bl1_plat_handle_post_image_load()` calculates the BL2 memory layout and populates the same in x1(r1). This ensures compatibility for the deprecated API. Change-Id: Id44bdc1f572dc42ee6ceef4036b3a46803689315 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
This patch adds an argument to bl1_plat_post/pre_image_load() APIs to make it more future proof. The default implementation of these are moved to `plat_bl1_common.c` file. These APIs are now invoked appropriately in the FWU code path prior to or post image loading by BL1 and are not restricted to LOAD_IMAGE_V2. The patch also reorganizes some common platform files. The previous `plat_bl2_el3_common.c` and `platform_helpers_default.c` files are merged into a new `plat_bl_common.c` file. NOTE: The addition of an argument to the above mentioned platform APIs is not expected to have a great impact because these APIs were only recently added and are unlikely to be used. Change-Id: I0519caaee0f774dd33638ff63a2e597ea178c453 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 23 Feb, 2018 1 commit
-
-
Antonio Nino Diaz authored
The Arm Trusted Firmware is built by default for ARMv8-A version 8.0. However, the Foundation FVP runs by default in the highest version of the architecture it supports. This causes problems when trying to run the Arm Trusted Firmware on it. This patch adds a note to the User Guide about this problem. Change-Id: I0220fe1a9c66c2292149ad4a7ffe5e27ba08ab28 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 06 Feb, 2018 3 commits
-
-
Jeenu Viswambharan authored
Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how Non-secure interrupt affects TSPs execution. When TSP is executing: 1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received at the TSP's exception vector, and TSP voluntarily preempts itself. 2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a trap to EL3, which preempts TSP execution. When EL3 exception handling is in place (i.e., EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system with GICv3, pending NS interrupts while TSP is executing will be signalled as FIQ (which traps to EL3). This situation necessitates the same treatment applied to case (2) above. Therefore, when EL3 exception handling is in place, additionally require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1. Strictly speaking, this is not required on a system with GICv2, but the same model is uniformly followed regardless, for simplicity. Relevant documentation updated. Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1, EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and secure execution. The interrupt management framework currently treats EL3 interrupt routing as valid. For the above reason, this patch makes them invalid when EL3_EXCEPTION_HANDLING is in effect. Change-Id: I95bca8f5dc8df8eb0ff6f305cfba098611522a39 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 01 Feb, 2018 1 commit
-
-
Masahiro Yamada authored
Just like bl2_, add pre/post image load handlers for BL1. No argument is needed since BL2 is the only image loaded by BL1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-