- 03 Feb, 2021 3 commits
-
-
Heyi Guo authored
In function gicv3_spis_config_defaults(), the variable num_ints is set to (maximum SPI INTID + 1), while num_eints is set to (maximum ESPI INTID). It introduces not only inconsistency to the code, but also logical bug in the "for" loops, for the INTID of num_eints is also valid and the check should be inclusive. Fix this by setting num_eints to (maximum ESPI INTID + 1) as well. Fix similar issues in gicv3_distif_save() and gicv3_distif_init_restore(). Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Change-Id: I4425777d17e84e85f38853603340bd348640154f
-
Heyi Guo authored
RESTORE/SAVE_GICD_EREGS uses (int_id - (MIN_ESPI_ID - MIN_SPI_ID)) to get the context array index for ESPI, which will override the space of standard SPI starting from (MIN_SPI_ID + MIN_SPI_ID). However, using TOTAL_SPI_INTR_NUM to replace the above MIN_SPI_ID cannot totally fix the issue, for TOTAL_SPI_INTR_NUM is not well aligned and the array index will be rounded down by the shifting operation if being shifted more than 2 bits. It will cause buffer override again when the existing maximum SPI reaches 1019. So round up TOTAL_SPI_INTR_NUM with (1 << REG##R_SHIFT) for GICD context arrays. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Change-Id: I5be2837c42f381a62f8d46a4ecd778009b1fe059
-
Heyi Guo authored
In function gicv3_rdistif_probe(), line #1322 implies gicv3_driver_data->mpidr_to_core_pos() may be null, but the original code uses this interface to get current CPU index unconditionally. It is better to use MPIDR to probe GICR which does not depend on gicv3_driver_data->mpidr_to_core_pos(). Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Change-Id: I64add055385040fe0a56b977e2299608e2309a6e
-
- 12 Oct, 2020 1 commit
-
-
Jimmy Brisson authored
Usually, C has no problem up-converting types to larger bit sizes. MISRA rule 10.7 requires that you not do this, or be very explicit about this. This resolves the following required rule: bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None> The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U | 0x3c0U" (32 bits) is less that the right hand operand "18446744073709547519ULL" (64 bits). This also resolves MISRA defects such as: bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)] In the expression "3U << 20", shifting more than 7 bits, the number of bits in the essential type of the left expression, "3U", is not allowed. Further, MISRA requires that all shifts don't overflow. The definition of PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues. This fixes the violation by changing the definition to 1UL << 12. Since this uses 32bits, it should not create any issues for aarch32. This patch also contains a fix for a build failure in the sun50i_a64 platform. Specifically, these misra fixes removed a single and instruction, 92407e73 and x19, x19, #0xffffffff from the cm_setup_context function caused a relocation in psci_cpus_on_start to require a linker-generated stub. This increased the size of the .text section and caused an alignment later on to go over a page boundary and round up to the end of RAM before placing the .data section. This sectionn is of non-zero size and therefore causes a link error. The fix included in this reorders the functions during link time without changing their ording with respect to alignment. Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
- 10 Oct, 2020 1 commit
-
-
johpow01 authored
In the function gicv2_set_spi_routing, the signed value proc_num is cast to unsigned int before being compared to other unsigned values in two assert calls. The value proc_num can be a negative value, and once the negative value is cast to unsigned it becomes a very large number which will trigger the assert. This patch changes the assert cast so that the unsigned values are cast to signed instead, keeping the same functionality but allowing proc_num to be negative. This bug can be seen when running the SDEI RM_ANY routing mode test in TFTF on the Juno platform. This patch also makes the usage of the proc_num variable in other gicv2 functions more clear. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: If1b98eebb00bd9b73862e5e995e5e68c168170a6
-
- 09 Oct, 2020 1 commit
-
-
Jimmy Brisson authored
And from crash_console_flush. We ignore the error information return by console_flush in _every_ place where we call it, and casting the return type to void does not work around the MISRA violation that this causes. Instead, we collect the error information from the driver (to avoid changing that API), and don't return it to the caller. Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
- 29 Sep, 2020 1 commit
-
-
Andre Przywara authored
A GICv3 interrupt controller will be instantiated for a certain number of cores. This will result in the respective number of GICR frames. The last frame will have the "Last" bit set in its GICR_TYPER register. For platforms with a topology unknown at build time (the Arm FPGAs, for instance), we need to learn the number of used cores at runtime, to size the GICR region in the devicetree accordingly. Add a generic function that iterates over all GICR frames until it encounters one with the "Last" bit set. It returns the number of cores the GICv3 has been configured for. Change-Id: I79f033c50dfc1c275aba7122725868811abcc4f8 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 29 Jul, 2020 1 commit
-
-
Alexei Fedorov authored
This patch fixes violation of Rules 10.1, 10.4, 11.9 and 13.2 reported by MISRA-2012 scan. Change-Id: Ibe9190cb0f26ae85d9a31db8e92fbd32f1740e25 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 27 Jul, 2020 1 commit
-
-
Alexei Fedorov authored
This patch fixes defects 10.3, 10.4, 10.7, 20.7 reported by MISRA-2012 scan and adds braces for conditional statements according to the TF-A coding style. Change-Id: If84ed31cdd55bc8e7cdd2a5f48c0dacc25792112 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 21 Jul, 2020 1 commit
-
-
Andre Przywara authored
The Arm GIC-Clayton IP has the same power management requirements as the GIC-600, when it comes to powering up the redistributors before using them. Add the IIDR value to the existing list of implementations requiring the power sequence. Change-Id: Ib965dfe278c40a4fff94f65a8d445c27a2ae6fd2 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 20 Jul, 2020 1 commit
-
-
Alexei Fedorov authored
This patch moves all GICv2 driver files into new added 'gicv2.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. NOTE: Usage of 'drivers/arm/gic/common/gic_common.c' file is now deprecated and platforms with GICv2 driver need to be modified to include 'drivers/arm/gic/v2/gicv2.mk' in their makefiles. Change-Id: Ib10e71bdda0e5c7e80a049ddce2de1dd839602d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 07 Jul, 2020 1 commit
-
-
Varun Wadekar authored
This patch adds the IIDR value for GIC600-AE to the gicv3_is_gic600() helper function. This helps platforms supporting this version of the GIC600 interrupt controller to function with the generic GIC driver. Verified with tftf-validation test suite ******************************* Summary ******************************* > Test suite 'Framework Validation' Passed > Test suite 'Timer framework Validation' Passed ================================= Tests Skipped : 0 Tests Passed : 6 Tests Failed : 0 Tests Crashed : 0 Total tests : 6 ================================= NOTICE: Exiting tests. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I518ae7b56f7f372e374e453287d76ca370fc3574
-
- 24 Jun, 2020 1 commit
-
-
Manish V Badarkhe authored
Cleaned up confused naming between TB_FW and FW_CONFIG. Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I9e9f6e6ca076d38fee0388f97d370431ae067f08
-
- 22 Jun, 2020 1 commit
-
-
Sandeep Tripathy authored
It is desired to have the peripheral writes completed to clear the interrupt condition and de-assert the interrupt request to GIC before EOI write. Failing which spurious interrupt will occurred. A barrier is needed to ensure peripheral register write transfers are complete before EOI is done. GICv2 memory mapped DEVICE nGnR(n)E writes are ordered from core point of view. However these writes may pass over different interconnects, bridges, buffers leaving some rare chances for the actual write to complete out of order. GICv3 ICC EOI system register writes have no ordering against nGnR(n)E memory writes as they are over different interfaces. Hence a dsb can ensure from core no writes are issued before the previous writes are *complete*. Signed-off-by: Sandeep Tripathy <sandeep.tripathy@broadcom.com> Change-Id: Ie6362009e2f91955be99dca8ece14ade7b4811d6
-
- 09 Jun, 2020 1 commit
-
-
Andre Przywara authored
The only difference between GIC-500 and GIC-600 relevant to TF-A is the differing power management sequence. A certain GIC implementation is detectable at runtime, for instance by checking the IIDR register. Let's add that test before initiating the GIC-600 specific sequence, so the code can be used on both GIC-600 and GIC-500 chips alike, without deciding on a GIC chip at compile time. This means that the GIC-500 "driver" is now redundant. To allow minimal platform support, add a switch to disable GIC-600 support. Change-Id: I17ea97d9fb05874772ebaa13e6678b4ba3415557 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 07 Apr, 2020 3 commits
-
-
Alexei Fedorov authored
To support compatibility with previous GICv3 driver version this patch: - restores original API for gicr_read_ipriority() and gicr_wrtite_ipriority() functions; - adds accessor functions for GICR_XXX0,1 registers, e.g. GICR_IGROUPR0, GICR_ICFGR0, GICR_ICFGR1, etc. Change-Id: I796a312a61665ff384e3d9de2f4b3c60f700b43b Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
Vijayenthiran Subramaniam authored
GIC-Clayton supports multichip operation mode which allows it to connect upto 16 other GIC-Clayton instances. GIC-Clayton's multichip programming and operation remains same as GIC-600 with a minor change in the SPI_BLOCKS and SPI_BLOCK_MIN shifts to accommodate additional SPI ranges. So identify if the GIC v4 extension is enabled by the platform makefile and appropriately select the SPI_BLOCKS and SPI_BLOCK_MIN shifts. Change-Id: I95fd80ef16af6c7ca09e2335539187b133052d41 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Alexei Fedorov authored
This patch adds support for GICv4 extension. New `GIC_ENABLE_V4_EXTN` option passed to gicv3.mk makefile was added, and enables GICv4 related changes when set to 1. This option defaults to 0. Change-Id: I30ebe1b7a98d3a54863900f37eda4589c707a288 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 06 Apr, 2020 1 commit
-
-
Alexei Fedorov authored
This patch provides support for GICv3.1 extended PPI and SPI range. The option is enabled by setting to 1 and passing `GIC_EXT_INTID` build flag to gicv3.mk makefile. This option defaults to 0 with no extended range support. Change-Id: I7d09086fe22ea531c5df51a8a1efd8928458d394 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 30 Mar, 2020 1 commit
-
-
Alexei Fedorov authored
This patch moves all GICv3 driver files into new added 'gicv3.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. The patch adds GICv3 driver configuration flags 'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and 'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in 'GICv3 driver options' section of 'build-option.rst' document. NOTE: Platforms with GICv3 driver need to be modified to include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles. Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 10 Mar, 2020 1 commit
-
-
Alexei Fedorov authored
This patch provides separation of GICD, GICR accessor functions and adds new macros for GICv3 registers access as a preparation for GICv3.1 and GICv4 support. NOTE: Platforms need to modify to include both 'gicdv3_helpers.c' and 'gicrv3_helpers.c' instead of the single helper file previously. Change-Id: I1641bd6d217d6eb7d1228be3c4177b2d556da60a Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 05 Mar, 2020 1 commit
-
-
Manish Pandey authored
The cpu index was wrongly checked causing it to assert always. Since this code path is exercised only during TF test "NODE_HW_STAT", which queries Power state from SCP, this bug was not detected earlier. Change-Id: Ia25cef4c0aa23ed08092df39134937a2601c21ac Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 25 Feb, 2020 1 commit
-
-
Andre Przywara authored
Since now the generic console_t structure holds the UART base address as well, let's use that generic location and drop the UART driver specific data structure at all. Change-Id: I7a23327394d142af4b293ea7ccd90b843c54587c Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 13 Feb, 2020 1 commit
-
-
Samuel Holland authored
Instead, pass back the error to the calling function. This allows platform code to fall back to another PSCI implementation if scpi_wait_ready() or a later SCPI command fails. Signed-off-by: Samuel Holland <samuel@sholland.org> Change-Id: Ib4411e63c2512857f09ffffe1c405358dddeb4a6
-
- 07 Feb, 2020 2 commits
-
-
Aditya Angadi authored
On systems that have multiple platform components that can interpret the SCMI messages, there is a need to support multiple SCMI channels (one each to those platform components). Extend the existing SCMI interface that currently supports only a single SCMI channel to support multiple SCMI channels. Change-Id: Ice4062475b903aef3b5e5bc37df364c9778a62c5 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
In order to allow the MHUv2 driver to be usable with multiple MHUv2 controllers, use the base address of the controller from the platform information instead of the MHUV2_BASE_ADDR macro. Change-Id: I4dbab87b929fb0568935e6c8b339ce67937f8cd1 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 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>
-
- 28 Jan, 2020 1 commit
-
-
Louis Mayencourt authored
The Secure Configuration Register is 64-bits in AArch64 and 32-bits in AArch32. Use u_register_t instead of unsigned int to reflect this. Change-Id: I51b69467baba36bf0cfaec2595dc8837b1566934 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 10 Jan, 2020 1 commit
-
-
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
-
- 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>
-
- 06 Dec, 2019 1 commit
-
-
Bence Szépkúti authored
As supporting architectures aside from AArch32 and AArch64 is not a concern, keeping identical definitions in two places for a large part of the libc seems counterproductive The int128 types were left un-unified as __int128 is not supported by gcc on AArch32 Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com> Change-Id: Idf08e6fab7e4680d9da62d3c57266ea2d80472cf
-
- 19 Nov, 2019 1 commit
-
-
Max Shvetsov authored
Change-Id: Ia120bcaacea3a462ab78db13f84ed23493033601 Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
-
- 15 Nov, 2019 1 commit
-
-
Alexei Fedorov authored
Arm's GIC-600 features a Power Register (GICR_PWRR), which needs to be programmed to enable redistributor operation. Section 3.6.1 in the GIC-600 TRM describes the power-up and power-down sequence in pseudo code, which deviates from the current TF-A implementation in drivers/arm/gic/v3/gic600.c. For powering on a redistributor, the pseudo code suggests to loop over the whole sequence (check for transition, write request bit) instead of just looping over the ready bit read as TF-A does in gic600_pwr_on(). This patch fixes GIC-600 power up sequence according to the TRM. Change-Id: I445c480e96ba356b69a2d8e5308ffe6c0a97f45b Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 11 Nov, 2019 1 commit
-
-
Vijayenthiran Subramaniam authored
Add support to configure GIC-600's multichip routing table registers. Introduce a new gic600 multichip structure in order to support platforms to pass their GIC-600 multichip information such as routing table owner, SPI blocks ownership. This driver is currently experimental and the driver api may change in the future. Change-Id: Id409d0bc07843e271ead3fc2f6e3cb38b317878d Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
- 01 Nov, 2019 1 commit
-
-
Deepika Bhavnani authored
Instead of retry polling, timer of 1ms is used to poll Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com> Change-Id: I7e028dc68138d2888e3cf0cbed744f5e6bc6ff42
-
- 08 Oct, 2019 1 commit
-
-
Avinash Mehta authored
Currently for Armv7 plaforms the quotient calculated in pl011 uart init code is moved to register r1. This patch moves the quotient to register r2 as done for other platforms in the udiv instruction. Value of register r2 is then used to calculate the values for IBRD and FBRD register Change-Id: Ie6622f9f0e6d634378b471df5d02823b492c8a24 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
-
- 26 Sep, 2019 1 commit
-
-
Madhukar Pappireddy authored
This patch provides declaration and definition of new GICv3 driver API: gicv3_rdistif_probe().This function delegates the responsibility of discovering the corresponding Redistributor base frame to each CPU itself. It is a modified version of gicv3_rdistif_base_addrs_probe() and is executed by each CPU in the platform unlike the previous approach in which only the Primary CPU did the discovery of all the Redistributor frames for every CPU. The flush operations as part of gicv3_driver_init() function are made necessary even for platforms with WARMBOOT_ENABLE_DCACHE_EARLY because the GICv3 driver data structure contents are accessed by CPU with D-Cache turned off during power down operations. Change-Id: I1833e81d3974b32a3e4a3df4766a33d070982268 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-
- 13 Sep, 2019 1 commit
-
-
Alexei Fedorov authored
This patch fixes GICv3 driver bug which causes assertion when full range of SPI INTIDs 32-1019 is supported in GICv3 implementation. Change-Id: Ib6da4b6eea868cff271cb32c7c7570bf5547ab47 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 01 Aug, 2019 2 commits
-
-
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>
-
Julius Werner authored
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>
-