summaryrefslogtreecommitdiff
path: root/plat/arm
AgeCommit message (Collapse)Author
2019-10-03Introducing support for Cortex-A65AEImre Kis
Change-Id: I1ea2bf088f1e001cdbd377cbfb7c6a2866af0422 Signed-off-by: Imre Kis <imre.kis@arm.com>
2019-10-03Merge "a5ds: Add handler for when user tries to switch off secondary cores" ↵Soby Mathew
into integration
2019-10-03a5ds: Add handler for when user tries to switch off secondary coresUsama Arif
a5ds only has always-on power domain and there is no power control present. However, without the pwr_domain_off handler, the kernel panics when the user will try to switch off secondary cores. The a5ds_pwr_domain_off handler will prevent kernel from crashing, i.e. the kernel will attempt but fail to shut down the secondary CPUs if the user tries to switch them offline. Change-Id: I3c2239a1b6f035113ddbdda063c8495000cbe30c Signed-off-by: Usama Arif <usama.arif@arm.com>
2019-10-02Introducing support for Cortex-A65Imre Kis
Change-Id: I645442d52a295706948e2cac88c36c1a3cb0bc47 Signed-off-by: Imre Kis <imre.kis@arm.com>
2019-09-30Cortex_hercules: Add support for Hercules-AEArtsem Artsemenka
Not tested on FVP Model. Change-Id: Iedebc5c1fbc7ea577e94142b7feafa5546f1f4f9 Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
2019-09-27Merge changes from topic "a5ds-multicore" into integrationSoby Mathew
* changes: a5ds: add multicore support a5ds: Hold the secondary cpus in pen rather than panic
2019-09-27Merge changes from topic "mp/giv3-discovery" into integrationSoby Mathew
* changes: Migrate ARM platforms to use the new GICv3 API Adding new optional PSCI hook pwr_domain_on_finish_late GICv3: Enable multi socket GIC redistributor frame discovery
2019-09-25Migrate ARM platforms to use the new GICv3 APIMadhukar Pappireddy
This patch invokes the new function gicv3_rdistif_probe() in the ARM platform specific gicv3 driver. Since this API modifies the shared GIC related data structure, it must be invoked coherently by using the platform specific pwr_domain_on_finish_late hook. Change-Id: I6efb17d5da61545a1c5a6641b8f58472b31e62a8 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2019-09-25FVP: Fix plat_set_nv_ctr() functionSandrine Bailleux
The Fast Models provide a non-volatile counter component, which is used in the Trusted Board Boot implementation to protect against rollback attacks. This component comes in 2 versions (see [1]). - Version 0 is the default and models a locked non-volatile counter, whose value is fixed. - Version 1 of the counter may be incremented in a monotonic fashion. plat_set_nv_ctr() must cope with both versions. This is achieved by: 1) Attempting to write the new value in the counter. 2) Reading the value back. 3) If there is a mismatch, we know the counter upgrade failed. When using version 0 of the counter, no upgrade is possible so the function is expected to fail all the time. However, the code is missing a compiler barrier between the write operation and the next read. Thus, the compiler may optimize and remove the read operation on the basis that the counter value has not changed. With the default optimization level used in TF-A (-Os), this is what's happening. The fix introduced in this patch marks the write and subsequent read accesses to the counter as volatile, such that the compiler makes no assumption about the value of the counter. Note that the comment above plat_set_nv_ctr() was clearly stating that when using the read-only version of the non-volatile counter, "we expect the values in the certificates to always match the RO values so that this function is never called". However, the fact that the counter value was read back seems to contradict this comment, as it is implementing a counter-measure against misuse of the function. The comment has been reworded to avoid any confusion. Without this patch, this bug may be demonstrated on the Base AEM FVP: - Using version 0 of the non-volatile counter (default version). - With certificates embedding a revision number value of 32 (compiling TF-A with TFW_NVCTR_VAL=32). In this configuration, the non-volatile counter is tied to value 31 by default. When BL1 loads the Trusted Boot Firmware certificate, it notices that the two values do not match and tries to upgrade the non-volatile counter. This write operation is expected to fail (because the counter is locked) and the function is expected to return an error but it succeeds instead. As a result, the trusted boot does not abort as soon as it should and incorrectly boots BL2. The boot is finally aborted when BL2 verifies the BL31 image and figures out that the version of the SoC Firmware Key Certificate does not match. On Arm platforms, only certificates signed with the Root-of-Trust Key may trigger an upgrade of the non-volatile Trusted counter. [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
2019-09-23a5ds: add multicore supportUsama Arif
Enable cores 1-3 using psci. On receiving the smc call from kernel, core 0 will bring the secondary cores out pen and signal an event for the cores. Currently on switching the cores is enabled i.e. it is not possible to suspend, switch cores off, etc. Change-Id: I6087e1d2ec650e1d587fd543efc1b08cbb50ae5f Signed-off-by: Usama Arif <usama.arif@arm.com>
2019-09-23a5ds: Hold the secondary cpus in pen rather than panicUsama Arif
For the secondary CPUs, hold the cpu in wfe rather then panic. This will be needed when multicore support is added to a5ds as the smc call will write to the hold base and signal an event to power on the secondary CPUs. Change-Id: I0ffc2059e9ef894c21375ca5c94def859bfa6599 Signed-off-by: Usama Arif <usama.arif@arm.com>
2019-09-13Merge "Refactor ARMv8.3 Pointer Authentication support code" into integrationSoby Mathew
2019-09-13Refactor ARMv8.3 Pointer Authentication support codeAlexei Fedorov
This patch provides the following features and makes modifications listed below: - Individual APIAKey key generation for each CPU. - New key generation on every BL31 warm boot and TSP CPU On event. - Per-CPU storage of APIAKey added in percpu_data[] of cpu_data structure. - `plat_init_apiakey()` function replaced with `plat_init_apkey()` which returns 128-bit value and uses Generic timer physical counter value to increase the randomness of the generated key. The new function can be used for generation of all ARMv8.3-PAuth keys - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`. - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively; pauth_disable_el1()` and `pauth_disable_el3()` functions disable PAuth for EL1 and EL3 respectively; `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from cpu-data structure. - Combined `save_gp_pauth_registers()` function replaces calls to `save_gp_registers()` and `pauth_context_save()`; `restore_gp_pauth_registers()` replaces `pauth_context_restore()` and `restore_gp_registers()` calls. - `restore_gp_registers_eret()` function removed with corresponding code placed in `el3_exit()`. - Fixed the issue when `pauth_t pauth_ctx` structure allocated space for 12 uint64_t PAuth registers instead of 10 by removal of macro CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h` and assigning its value to CTX_PAUTH_REGS_END. - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions in `msr spsel` instruction instead of hard-coded values. - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI. Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-09-11Modify FVP makefile for cores that support both AArch64/32John Tsichritzis
Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly handle those cores, only the AArch64 cores' assembly is included in the TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only cores will never exist in the same cluster with cores that also support AArch32. However, A55 and A75 can be used as AArch64 only cores, despite supporting AArch32, too. This patch enables A55 and A75 to exist in clusters together with AArch64 cores. Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-08-20Merge "plat/arm: Introduce corstone700 platform." into integrationPaul Beesley
2019-08-20plat/arm: Introduce corstone700 platform.Manish Pandey
This patch adds support for Corstone-700 foundation IP, which integrates both Cortex-M0+ and Cortex-A(Host) processors in one handy, flexible subsystem. This is an example implementation of Corstone-700 IP host firmware. Cortex-M0+ will take care of boot stages 1 and 2(BL1/BL2) as well as bringing Host out RESET. Host will start execution directly from BL32 and then will jump to Linux. It is an initial port and additional features are expected to be added later. Change-Id: I7b5c0278243d574284b777b2408375d007a7736e Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2019-08-16Merge "FVP: Add Delay Timer driver to BL1 and BL31" into integrationPaul Beesley
2019-08-16FVP: Add Delay Timer driver to BL1 and BL31Alexei Fedorov
SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16Merge changes from topic "lm/juno_dyn_cfg" into integrationPaul Beesley
* changes: Juno: Use shared mbedtls heap between bl1 and bl2 Juno: add basic support for dynamic config
2019-08-13Juno: Use shared mbedtls heap between bl1 and bl2Louis Mayencourt
Change-Id: Ia1ecad58ebf9de3f3a44b17ad1de57424b431125 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-08-13Juno: add basic support for dynamic configLouis Mayencourt
Add the disable_auth dynamic parameter, that allows to disable the authentication when TBBR is enabled. This parameter is for development only. Change-Id: Ic24ad16738517f7e07c4f506dcf69a1ae8df7d2d Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-08-01Switch AARCH32/AARCH64 to __aarch64__Julius Werner
NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__. All common C compilers pre-define the same macros to signal which architecture the code is being compiled for: __arm__ for AArch32 (or earlier versions) and __aarch64__ for AArch64. There's no need for TF-A to define its own custom macros for this. In order to unify code with the export headers (which use __aarch64__ to avoid another dependency), let's deprecate the AARCH32 and AARCH64 macros and switch the code base over to the pre-defined standard macro. (Since it is somewhat unintuitive that __arm__ only means AArch32, let's standardize on only using __aarch64__.) Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200 Signed-off-by: Julius Werner <jwerner@chromium.org>
2019-08-01Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__Julius Werner
NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__. All common C compilers predefine a macro called __ASSEMBLER__ when preprocessing a .S file. There is no reason for TF-A to define it's own __ASSEMBLY__ macro for this purpose instead. To unify code with the export headers (which use __ASSEMBLER__ to avoid one extra dependency), let's deprecate __ASSEMBLY__ and switch the code base over to the predefined standard. Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417 Signed-off-by: Julius Werner <jwerner@chromium.org>
2019-07-26Merge "sgm775: Fix build fail for TSP support on sgm775" into integrationSoby Mathew
2019-07-25Merge changes from topic "gby/cryptocell-multi-vers" into integrationSoby Mathew
* changes: cryptocell: add product version awareness support cryptocell: move Cryptocell specific API into driver
2019-07-25sgm775: Fix build fail for TSP support on sgm775Madhukar Pappireddy
Fixed the path to a source file specified in tsp makefile Created a platform specific tsp makefile Change-Id: I89565127c67eff510e48e21fd450af4c3088c2d4 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2019-07-25cryptocell: move Cryptocell specific API into driverGilad Ben-Yossef
Code using Cryptocell specific APIs was used as part of the arm common board ROT support, instead of being abstracted in Cryptocell specific driver code, creating two problems: - Any none arm board that uses Cryptocell wuld need to copy and paste the same code. - Inability to cleanly support multiple versions of Cryptocell API and products. Move over Cryptocell specific API calls into the Cryptocell driver, creating abstraction API where needed. Signed-off-by: Gilad Ben-Yossef <gilad.benyossef@arm.com> Change-Id: I9e03ddce90fcc47cfdc747098bece86dbd11c58e
2019-07-23Merge "n1sdp: fix DMC ECC enablement sequence in N1SDP platform" into ↵Soby Mathew
integration
2019-07-23Merge "arm: Shorten the Firmware Update (FWU) process" into integrationSoby Mathew
2019-07-23n1sdp: fix DMC ECC enablement sequence in N1SDP platformManoj Kumar
The DMC-620 memory controllers in N1SDP platform has to be put into CONFIG state before writing to ERR0CTLR0 register to enable ECC. This patch fixes the sequence so that DMCs are set to CONFIG state before writing to ERR0CTLR0 register and moved back to READY state after writing. Change-Id: I1252f3ae0991603bb29234029cddb5fbf869c1b2 Signed-off-by: Manoj Kumar <manoj.kumar3@arm.com>
2019-07-23arm: Shorten the Firmware Update (FWU) processAmbroise Vincent
The watchdog is configured with a default value of 256 seconds in order to implement the Trusted Board Boot Requirements. For the FVP and Juno platforms, the FWU process relies on a watchdog reset. In order to automate the test of FWU, the length of this process needs to be as short as possible. Instead of waiting for those 4 minutes to have a reset by the watchdog, tell it to reset immediately. There are no side effects as the value of the watchdog's load register resets to 0xFFFFFFFF. Tested on Juno. Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
2019-07-23Merge "Cortex_hercules: Introduce preliminary cpu support" into integrationSoby Mathew
2019-07-16Cortex_hercules: Introduce preliminary cpu supportLouis Mayencourt
Change-Id: Iab767e9937f5c6c8150953fcdc3b37e8ee83fa63 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-07-16plat/arm: Introduce A5 DesignStart platform.Usama Arif
This patch adds support for Cortex-A5 FVP for the DesignStart program. DesignStart aims at providing low cost and fast access to Arm IP. Currently with this patch only the primary CPU is booted and the rest of them wait for an interrupt. Signed-off-by: Usama Arif <usama.arif@arm.com> Change-Id: I3a2281ce6de2402dda4610a89939ed53aa045fab
2019-07-10Rename Cortex-Deimos to Cortex-A77Balint Dobszay
Change-Id: I755e4c42242d9a052570fd1132ca3d937acadb13 Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
2019-06-28Merge changes from topic "av/console-port" into integrationPaul Beesley
* changes: qemu: use new console interface in aarch32 warp7: remove old console from makefile Remove MULTI_CONSOLE_API flag and references to it Console: removed legacy console API
2019-06-28Remove MULTI_CONSOLE_API flag and references to itAmbroise Vincent
The new API becomes the default one. Change-Id: Ic1d602da3dff4f4ebbcc158b885295c902a24fec Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
2019-06-26n1sdp: add code for DDR ECC enablement and BL33 copy to DDRManoj Kumar
N1SDP platform supports RDIMMs with ECC capability. To use the ECC capability, the entire DDR memory space has to be zeroed out before enabling the ECC bits in DMC620. Zeroing out several gigabytes of memory from SCP is quite time consuming so functions are added that zeros out the DDR memory from application processor which is much faster compared to SCP. BL33 binary cannot be copied to DDR memory before enabling ECC so this is also done by TF-A from IOFPGA-DDR3 memory to main DDR4 memory after ECC is enabled. Original PLAT_PHY_ADDR_SPACE_SIZE was limited to 36-bits with which the entire DDR space cannot be accessed as DRAM2 starts in base 0x8080000000. So these macros are redefined for all ARM platforms. Change-Id: If09524fb65b421b7a368b1b9fc52c49f2ddb7846 Signed-off-by: Manoj Kumar <manoj.kumar3@arm.com>
2019-06-11plat/arm: Skip BL2U if RESET_TO_SP_MIN flag is setLouis Mayencourt
BL2U should not build when RESET_TO_SP_MIN flag is set, like BL1 and BL2. Change-Id: Iac516121f98611ca1f58d2b5efdec6525b06ce4e Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-06-06Merge "FVP: Remove GIC initialisation from secondary core cold boot" into ↵John Tsichritzis
integration
2019-06-05FVP: Remove GIC initialisation from secondary core cold bootJohn Tsichritzis
During the secondary cores' cold boot path, the cores initialise the GIC CPU interface. However this is a redundant action since 1) the cores are powered down immediately after that, 2) the GIC CPU interface is initialised from scratch when the secondary cores are powered up again later. Moreover, this part of code was introducing a bug. In a GICv3 system, the GIC's CPU interface system registers must not be written without the core being marked as "awake" in the redistributor. However, this sequence was performing such accesses and this would cause those cores to hang. The hang was caused by the DSB instruction that would never complete because of the GIC not recognising those writes. For the two aforementioned reasons, the entire part of the GIC CPU interface initialisation is removed. Change-Id: I6c33a1edda69dd5b6add16a27390a70731b5532a Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-04Apply compile-time check for AArch64-only coresJohn Tsichritzis
Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-05-16Merge changes from topic "sami/550_fix_n1sdp_issues_v1" into integrationSoby Mathew
* changes: N1SDP: Initialise CNTFRQ in Non Secure CNTBaseN N1SDP: Fix DRAM2 start address Add option for defining platform DRAM2 base Disable speculative loads only if SSBS is supported
2019-05-15N1SDP: Initialise CNTFRQ in Non Secure CNTBaseNSami Mujawar
N1SDP exhibits the behavior similar to Juno wherein CNTBaseN.CNTFRQ can be written but does not reflect the value of the CNTFRQ register in CNTCTLBase frame. This doesn't follow ARM ARM in that the value updated in CNTCTLBase.CNTFRQ is not reflected in CNTBaseN.CNTFRQ. Hence enable the workaround (applied to Juno) for N1SDP that updates the CNTFRQ register in the Non Secure CNTBaseN frame. Change-Id: Id89ee1bca0f25c9d62f8f794f2c4f4e618cdf092 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
2019-05-15N1SDP: Fix DRAM2 start addressSami Mujawar
The default DRAM2 start address for Arm platforms is 0x880000000. However, for N1SDP platform this is 0x8080000000. Fix the DRAM2 start address by initialising PLAT_ARM_DRAM2_BASE. Without this fix there is a mismatch of the System memory region view as seen by the BL31 runtime firmware (PSCI) versus the view of the OS (which is based on the description provided by UEFI. In this case UEFI is correctly describing the DRAM2 start address). This implicates in secondary cores failing to start on some Operating Systems if the OS decides to place the secondary start address in the mismatched region. Change-Id: I57220e753219353dda429868b4c5e1a69944cc64 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
2019-05-15Add option for defining platform DRAM2 baseSami Mujawar
The default DRAM2 base address for Arm platforms is 0x880000000. However, on some platforms the firmware may want to move the start address to a different value. To support this introduce PLAT_ARM_DRAM2_BASE that defaults to 0x880000000; but can be overridden by a platform (e.g. in platform_def.h). Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
2019-05-10SMMUv3: Abort DMA transactionsAlexei Fedorov
For security DMA should be blocked at the SMMU by default unless explicitly enabled for a device. SMMU is disabled after reset with all streams bypassing the SMMU, and abortion of all incoming transactions implements a default deny policy on reset. This patch also moves "bl1_platform_setup()" function from arm_bl1_setup.c to FVP platforms' fvp_bl1_setup.c and fvp_ve_bl1_setup.c files. Change-Id: Ie0ffedc10219b1b884eb8af625bd4b6753749b1a Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-05-03Merge "Add compile-time errors for HW_ASSISTED_COHERENCY flag" into integrationSoby Mathew
2019-05-03Add compile-time errors for HW_ASSISTED_COHERENCY flagJohn Tsichritzis
This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-05-03SMMUv3: refactor the driver codeAlexei Fedorov
This patch is a preparation for the subsequent changes in SMMUv3 driver. It introduces a new "smmuv3_poll" function and replaces inline functions for accessing SMMU registers with mmio read/write operations. Also the infinite loop for the poll has been replaced with a counter based timeout. Change-Id: I7a0547beb1509601f253e126b1a7a6ab3b0307e7 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>