- 22 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The values defined in this type are used in logical operations, which goes against MISRA Rule 10.1: "Operands shall not be of an inappropriate essential type". Now, `unsigned int` is used instead. This also allows us to move the dynamic mapping bit from 30 to 31. It was an undefined behaviour in the past because an enum is signed by default, and bit 31 corresponds to the sign bit. It is undefined behaviour to modify the sign bit. Now, bit 31 is free to use as it was originally meant to be. mmap_attr_t is now defined as an `unsigned int` for backwards compatibility. Change-Id: I6b31218c14b9c7fdabebe432de7fae6e90a97f34 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 19 Jun, 2018 4 commits
-
-
Nishanth Menon authored
Create the baseline Makefile, platform definitions file and platform specific assembly macros file. This includes first set of constants for the platform including cache sizes and linker format and a stub for BL31 and the basic memory layout K3 SoC family of processors do not use require a BL1 or BL2 binary, since such functions are provided by an system controller on the SoC. This lowers the burden of ATF to purely managing the local ARM cores themselves. Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com>
-
Ying-Chun Liu (PaulLiu) authored
Describe how to use BL32 build variable to load OP-TEE into FIP. Signed-off-by: Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
-
Anson Huang authored
NXP's i.MX8QM is an ARMv8 SoC with 2 clusters, 2 Cortex-A72 cores in one cluster and 4 Cortex-A53 in the other cluster, and also has system controller (Cortex-M4) inside, documentation can be found in below link: https://www.nxp.com/products/processors-and-microcontrollers/ applications-processors/i.mx-applications-processors/i.mx-8-processors:IMX8-SERIES This patch adds support for booting up SMP linux kernel (v4.9). Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
-
Anson Huang authored
NXP's i.MX8QX is an ARMv8 SoC with 4 Cortex-A35 cores and system controller (Cortex-M4) inside, documentation can be found in below link: https://www.nxp.com/products/processors-and-microcontrollers/ applications-processors/i.mx-applications-processors/i.mx-8-processors:IMX8-SERIES This patch adds support for booting up SMP linux kernel (v4.9). Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
-
- 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>
-
- 15 Jun, 2018 1 commit
-
-
Samuel Holland authored
The Allwinner A64 SoC is quite popular on single board computers. It comes with four Cortex-A53 cores in a singe cluster and the usual peripherals for set-top box/tablet SoC. The ATF platform target is called "sun50i_a64". [Andre: adapted to amended directory layout, removed unneeded definitions ] Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andre Przywara <andre.przywara@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>
-
- 13 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The order of the arguments of memmap was swapped. The old command was reserving 256 MiB from the 16 MiB barrier, it should be reserving only 16 MiB at the 256 MiB barrier. It worked because the memory used by the Trusted Firmware was reserved anyway. Change-Id: I3fefcfc0105ecf05ba5606517bc3236f4eb24ceb Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@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>
-