- 04 Feb, 2020 1 commit
-
-
Zelalem authored
This patch removes unnecessary header file includes discovered by Coverity HFA option. Change-Id: I2827c37c1c24866c87db0e206e681900545925d4 Signed-off-by: Zelalem <zelalem.aweke@arm.com>
-
- 27 Jan, 2020 1 commit
-
-
Vijayenthiran Subramaniam authored
The platform topology description of the upcoming Arm's RD platforms have different topology than those listed in the sgi_topology.c file. So instead of adding platform specific topology into existing sgi_topology.c file, those can be added to respective board files. In order to maintain consistency with the upcoming platforms, move the existing platform topology description to respective board files. Change-Id: I4689c7d24cd0c75a3dc234370c34a85c08598abb Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
- 10 Jan, 2020 2 commits
-
-
Deepika Bhavnani authored
NOTE for platform integrators: API `plat_psci_stat_get_residency()` third argument `last_cpu_idx` is changed from "signed int" to the "unsigned int" type. Issue / Trouble points 1. cpu_idx is used as mix of `unsigned int` and `signed int` in code with typecasting at some places leading to coverity issues. 2. Underlying platform API's return cpu_idx as `unsigned int` and comparison is performed with platform specific defines `PLAFORM_xxx` which is not consistent Misra Rule 10.4: The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression. Based on above points, cpu_idx is kept as `unsigned int` to match the API's and low-level functions and platform defines are updated where ever required Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com> Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
-
Alexei Fedorov authored
This patch removes re-definition of the following FVP build options from plat\arm\board\fvp\fvp_def.h: 'FVP_CLUSTER_COUNT' 'FVP_MAX_CPUS_PER_CLUSTER' 'FVP_MAX_PE_PER_CPU' which are set in platform.mk. This fixes a potential problem when a build option set in platform.mk file can be re-defined in fvp_def.h header file used by other build component with a different makefile which does not set this option. Ref. GENFW-3505. Change-Id: I4288629920516acf2c239c7b733f92a0c5a812ff Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 07 Jan, 2020 3 commits
-
-
Ambroise Vincent authored
The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
-
Avinash Mehta authored
Point boot address to DDR location for booting A5DS FPGA FIP, Kernel and rootfs are sideloaded to DDR Also move BL2 to higher address in DDR Change-Id: Ia2a57a0bda776a1a0a96bcd3cfb5c6cd2cf4dc04 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
-
Avinash Mehta authored
Correct the system, timer and uart frequencies to successfully run the stack on FPGA Correct Cortex-A5MPcore to 8 word granularity for Cache writeback Change-Id: I2c59c26b7dca440791ad39f2297c68ae513da7b6 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
-
- 03 Jan, 2020 1 commit
-
-
Vishnu Banavath authored
The SCU connects one to four Cortex-A5/Cortex-A9 processors to the memory system through the AXI interfaces. The SCU functions are to: - maintain data cache coherency between the Cortex-A5/Cortex-A9 processors - initiate L2 AXI memory accesses - arbitrate between Cortex-A5/Cortex-A9 processors requesting L2 accesses - manage ACP accesses. Snoop Control Unit will enable to snoop on other CPUs caches. This is very important when it comes to synchronizing data between CPUs. As an example, there is a high chance that data might be cache'd and other CPUs can't see the change. In such cases, if snoop control unit is enabled, data is synchoronized immediately between CPUs and the changes are visible to other CPUs. This driver provides functionality to enable SCU as well as enabling user to know the following - number of CPUs present - is a particular CPU operating in SMP mode or AMP mode - data cache size of a particular CPU - does SCU has ACP port - is L2CPRESENT Change-Id: I0d977970154fa60df57caf449200d471f02312a0 Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>
-
- 20 Dec, 2019 3 commits
-
-
Paul Beesley authored
Before adding any new SPM-related components we should first do some cleanup around the existing SPM-MM implementation. The aim is to make sure that any SPM-MM components have names that clearly indicate that they are MM-related. Otherwise, when adding new SPM code, it could quickly become confusing as it would be unclear to which component the code belongs. The secure_partition.h header is a clear example of this, as the name is generic so it could easily apply to any SPM-related code, when it is in fact SPM-MM specific. This patch renames the file and the two structures defined within it, and then modifies any references in files that use the header. Change-Id: I44bd95fab774c358178b3e81262a16da500fda26 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
The Secure Partition Manager (SPM) prototype implementation is being removed. This is preparatory work for putting in place a dispatcher component that, in turn, enables partition managers at S-EL2 / S-EL1. This patch removes: - The core service files (std_svc/spm) - The Resource Descriptor headers (include/services) - SPRT protocol support and service definitions - SPCI protocol support and service definitions Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426 Signed-off-by: Paul Beesley <paul.beesley@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
-
Paul Beesley authored
There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the other is based on the Secure Partition Client Interface (SPCI) specification. Currently there is a dependency between their build flags that shouldn't exist, making further development harder than it should be. This patch removes that dependency, making the two flags function independently. Before: ENABLE_SPM=1 is required for using either implementation. By default, the SPCI-based implementation is enabled and this is overridden if SPM_MM=1. After: ENABLE_SPM=1 enables the SPCI-based implementation. SPM_MM=1 enables the MM-based implementation. The two build flags are mutually exclusive. Note that the name of the ENABLE_SPM flag remains a bit ambiguous - this will be improved in a subsequent patch. For this patch the intention was to leave the name as-is so that it is easier to track the changes that were made. Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
- 18 Dec, 2019 1 commit
-
-
Ambroise Vincent authored
Provide an SMC interface to the 9p filesystem. This permits accessing firmware drivers through a common interface, using standardized read/write/control operations. Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: I9314662314bb060f6bc02714476574da158b2a7d
-
- 09 Dec, 2019 1 commit
-
-
Ambroise Vincent authored
Previously the .init section was created even when the reclaim flag was manually set to 0. Change-Id: Ia9e7c7997261f54a4eca725d7ea605192f60bcf8 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Zelalem Aweke <zelalem.aweke@arm.com>
-
- 19 Nov, 2019 1 commit
-
-
Max Shvetsov authored
Change-Id: Ia120bcaacea3a462ab78db13f84ed23493033601 Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
-
- 18 Nov, 2019 1 commit
-
-
Louis Mayencourt authored
ROMLIB extract functions code from BL images to put them inside ROM. This has for effect to reduce the size of the BL images. This patch take this size reduction into consideration to optimize the memory layout of BL2. A new "PLAT_ARM_BL2_ROMLIB_OPTIMIZATION" macro is defined and used to reduce "PLAT_ARM_MAX_BL2_SIZE". This allows to remove the gap between BL1 and BL2 when ROMLIB is used and provides more room for BL31. The current memory gain is 0x6000 for fvp and 0x8000 for juno. Change-Id: I71c2c2c63b57bce5b22a125efaefc486ff3e87be Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 15 Nov, 2019 1 commit
-
-
Imre Kis authored
The number of levels in the topology has not changed but the count of processing elements on the lowest layer is now multiplied by the value of FVP_MAX_PE_PER_CPU. Signed-off-by: Imre Kis <imre.kis@arm.com> Change-Id: Ia1568a40ea33dbbbcdfab6c8ab6d19f4db0b8eb4
-
- 11 Nov, 2019 1 commit
-
-
Manish Pandey authored
N1SDP supports multichip configuration wherein n1sdp boards are connected over high speed coherent CCIX link, for now only dual-chip is supported. Whether or not multiple chips are present is dynamically probed by SCP firmware and passed on to TF-A, routing table will be set up only if multiple chips are present. Initialize GIC-600 multichip operation by overriding the default GICR frames with array of GICR frames and setting the chip 0 as routing table owner. Change-Id: Ida35672be4bbf4c517469a5b330548d75e593ff2 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 07 Nov, 2019 1 commit
-
-
Manish Pandey authored
Earlier PIE support was enabled for all arm platforms when RESET_TO_BL31=1, but later on it was restricted only to FVP with patch SHA d4580d17 because of n1sdp platform. Now it has been verified that PIE does work for n1sdp platform also, so enabling it again for all arm platforms. Change-Id: I05ad4f1775ef72e7cb578ec9245cde3fbce971a5 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 31 Oct, 2019 1 commit
-
-
Manish Pandey authored
N1SDP supports multichip configuration wherein n1sdp boards are connected over high speed coherent CCIX link for now only dual-chip is supported. A single instance of TF-A runs on master chip which should be aware of slave chip's CPU and memory topology. This patch updates platform macros to include remote chip's information and also ensures that a single version of firmware works for both single and dual-chip setup. Change-Id: I75799fd46dc10527aa99585226099d836c21da70 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 30 Oct, 2019 1 commit
-
-
Manish Pandey authored
Platform information structure holds information about platform's DDR size(local/remote) which will be used to zero out the memory before enabling the ECC capability as well as information about multichip setup. Multichip and remote DDR information can only be probed in SCP, SDS region will be used by TF-A to get this information at boot up. This patch introduces a new SDS to store platform information, which is populated dynamically by SCP Firmware.previously used mem_info SDS is also made part of this structure itself. The platform information is also passed to BL33 by copying it to Non- Secure SRAM. Change-Id: I4781dc6a7232c3c0a3219b164d943ce9e3e469ee Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 03 Oct, 2019 2 commits
-
-
Imre Kis authored
Change-Id: I1ea2bf088f1e001cdbd377cbfb7c6a2866af0422 Signed-off-by: Imre Kis <imre.kis@arm.com>
-
Usama Arif authored
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>
-
- 02 Oct, 2019 1 commit
-
-
Imre Kis authored
Change-Id: I645442d52a295706948e2cac88c36c1a3cb0bc47 Signed-off-by: Imre Kis <imre.kis@arm.com>
-
- 30 Sep, 2019 1 commit
-
-
Artsem Artsemenka authored
Not tested on FVP Model. Change-Id: Iedebc5c1fbc7ea577e94142b7feafa5546f1f4f9 Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
-
- 26 Sep, 2019 1 commit
-
-
Madhukar Pappireddy authored
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>
-
- 25 Sep, 2019 1 commit
-
-
Sandrine Bailleux authored
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>
-
- 23 Sep, 2019 2 commits
-
-
Usama Arif authored
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>
-
Usama Arif authored
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>
-
- 11 Sep, 2019 1 commit
-
-
John Tsichritzis authored
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>
-
- 20 Aug, 2019 1 commit
-
-
Manish Pandey authored
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>
-
- 16 Aug, 2019 1 commit
-
-
Alexei Fedorov authored
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>
-
- 13 Aug, 2019 2 commits
-
-
Louis Mayencourt authored
Change-Id: Ia1ecad58ebf9de3f3a44b17ad1de57424b431125 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
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>
-
- 01 Aug, 2019 1 commit
-
-
Julius Werner authored
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>
-
- 25 Jul, 2019 2 commits
-
-
Madhukar Pappireddy authored
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>
-
Gilad Ben-Yossef authored
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
-
- 23 Jul, 2019 2 commits
-
-
Manoj Kumar authored
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>
-
Ambroise Vincent authored
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>
-
- 16 Jul, 2019 2 commits
-
-
Louis Mayencourt authored
Change-Id: Iab767e9937f5c6c8150953fcdc3b37e8ee83fa63 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Usama Arif authored
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
-