- 09 Dec, 2020 5 commits
-
-
Aditya Angadi authored
Upcoming RD platforms will have an updated memory map for the various pheripherals on the system. So, for the newer platforms, handle the memory mapping and other platform specific functionality separately from the existing platforms. Change-Id: Iab1355a4c8ea1f6db4f79fcdd6eed907903b6a18 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
In preparation for adding the board support for RD-N2 platform, add macros to define the platform id and the corresponding SCMI platform info for the RD-N2 platform. Change-Id: Ie764ae618732b39e316f7ed080421f5d79adab21 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
Upcoming RD platforms have changes in the SOC address map from that of the existing platforms. As a prepartory step to add support for the upcoming platforms, create platform definitions for those platforms. Change-Id: Ic5df9fed02c44e65ec260bbb5efc1b8dbd919a56 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
Upcoming RD platforms have deviations in various definitions of platform macros from that of the exisiting platforms. In preparation for adding support for those upcoming RD platforms, refactor the header file inclusion to allow newer platforms to use a different set of platform macros. Change-Id: Ic80283ddadafaa7f766f300652cb0d4e507efdb6 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
Upcoming RD platforms have a different memory map from those of the existing platforms. So make the build of the existing mmap entries to be usable only for existing platforms and let upcoming platforms define a different set of mmap entries. Change-Id: Id1ef0293efe8749c78a99237e78d32573c7233aa Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 24 Sep, 2020 1 commit
-
-
Sami Mujawar authored
The SGI platform defines the macro PLAT_ARM_MEM_PROT_ADDR which indicates that the platform has mitigation for cold reboot attacks. However, the flash memory used for the mem_protect region was not mapped. This results in a crash when an OS calls PSCI MEM_PROTECT. To fix this map the flash region used for mem_protect. Change-Id: Ia494f924ecfe2ce835c045689ba8f942bf0941f4 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
-
- 31 Jul, 2020 1 commit
-
-
Olivier Deprez authored
Following merge of patchset [1] the spm_mm_boot_info_t structure is included in few platform files unconditionally even when SPM_MM option is disabled. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2647 Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: I68bc034c9348b5d9bcfd2e5217b781df5ad1b369
-
- 23 Jul, 2020 1 commit
-
-
Manish V Badarkhe authored
Renamed node for trusted boot fw config from 'plat_arm_bl2' to 'tb_fw-config'. Change-Id: I2e16b6f4d272292ec1855daafd014e851436dd9b Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 24 Jun, 2020 2 commits
-
-
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
-
Manish V Badarkhe authored
Moved BL2 configuration nodes from fw_config to newly created tb_fw_config device tree. fw_config device tree's main usage is to hold properties shared across all BLx images. An example is the "dtb-registry" node, which contains the information about the other device tree configurations (load-address, size). Also, Updated load-address of tb_fw_config which is now located after fw_config in SRAM. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ic398c86a4d822dacd55b5e25fd41d4fe3888d79a
-
- 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>
-
- 17 Apr, 2020 1 commit
-
-
Chris Kay authored
This commit fixes an assertion that was triggering in certain contexts: ERROR: mmap_add_region_check() failed. error -22 ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:790 Change-Id: Ia55b3fb4f496c8cd791ea6093d122edae0a7e92a Signed-off-by: Chris Kay <chris.kay@arm.com> Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 15 Apr, 2020 1 commit
-
-
Madhukar Pappireddy authored
By writing 0 to CLUSTERPWRDN DSU register bit 0, we send an advisory to the power controller that cluster power is not required when all cores are powered down. The AArch32 CLUSTERPWRDN register is architecturally mapped to the AArch64 CLUSTERPWRDN_EL1 register Change-Id: Ie6e67c1c7d811fa25c51e2e405ca7f59bd20c81b Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-
- 14 Apr, 2020 1 commit
-
-
Aditya Angadi authored
A single chip platform requires five mmap entries and a corresponding number of translation tables. For every additional chip in the system, three additional mmap entries are required to map the shared SRAM and the IO regions. A corresponding number of additional translation tables are required as well. Change-Id: I1332a1305f2af62181387cf36954f6fb0e6f11ed Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 07 Apr, 2020 1 commit
-
-
Manish V Badarkhe authored
Increased the maximum size of BL2 image in order to accommodate the BL2 image when TF-A build with no compiler optimization for ARM platform. Note: As of now, "no compiler optimization" build works only when TRUSTED_BOOT_BOARD option is set to 0. This change is verified using below CI configuration: 1. juno-no-optimize-default:juno-linux.uboot 2. fvp-no-optimize-default,fvp-default:fvp-tftf-fip.tftf-aemv8a-debug Change-Id: I5932621237f8acd1b510682388f3ba78eae90ea4 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@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>
-
- 27 Mar, 2020 1 commit
-
-
Aditya Angadi authored
Use ARRAY_SIZE macro instead of sizeof operator to obtain the maximum number of SCMI channels supported on the platform. Change-Id: Id922bb548af98ac99b4ac0c34e38e589e5a80b2d Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 13 Mar, 2020 1 commit
-
-
Louis Mayencourt authored
Increase bl1 RW limit to allow future development. Change-Id: I3159b36dbaca798b4c4374c1415cd033d6586388 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 12 Mar, 2020 1 commit
-
-
Chris Kay authored
To accommodate the increasing size of the SCP_BL2 binary, the base address of the memory region allocated to SCP_BL2 has been moved downwards from its current (mostly) arbitrary address to the beginning of the non-shared trusted SRAM. Change-Id: I086a3765bf3ea88f45525223d765dc0dbad6b434 Signed-off-by: Chris Kay <chris.kay@arm.com>
-
- 11 Mar, 2020 1 commit
-
-
Vijayenthiran Subramaniam authored
Shared RAM region in the remote chip's memory is used as one of the mailbox region (SCMI payload area) through which the AP core on the local chip and SCP core on the remote chip exchange SCMI protocol message during the initialization. Mark this region as non-cacheable in the MMAP entry to prevent local AP core from reading stale data from the cache. Change-Id: I7e9dc5fbcc3b40e9bcff5499f15abd2aadaed385 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@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>
-
- 19 Feb, 2020 1 commit
-
-
Suyash Pathak authored
The base address for second DRAM varies across different platforms. So allow platforms to define second DRAM by moving Juno/SGM-775 specific definition of second DRAM base address to Juno/SGM-775 board definition respectively, SGI/RD specific definition of DRAM 2 base address to SGI board definition. Change-Id: I0ecd3a2bd600b6c7019c7f06f8c452952bd07cae Signed-off-by: Suyash Pathak <suyash.pathak@arm.com>
-
- 07 Feb, 2020 11 commits
-
-
Aditya Angadi authored
Add the initial board support for RD-Daniel Config-M platform. Change-Id: I36df16c745bfe4bc817e275ad4722e5de57733cd Signed-off-by: Jagadeesh Ujja <jagadeesh.ujja@arm.com> Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Vijayenthiran Subramaniam authored
In preparation for adding support for Reference Design platforms which have different base addresses for GIC Distributor or Redistributor, move GIC related base addresses to individual platform definition files. Change-Id: Iecf52b4392a30b86905e1cd047c0ff87d59d0191 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
Introduce macro 'CSS_SGI_CHIP_COUNT' to allow Arm CSS platforms with multi-chip support to define number of chiplets on the platform. By default, this flag is set to 1 and does not affect the existing single chip platforms. For multi-chip platforms, override the default value of CSS_SGI_CHIP_COUNT with the number of chiplets supported on the platform. As an example, the command below sets the number of chiplets to two on the RD-N1-Edge multi-chip platform: export CROSS_COMPILE=<path-to-cross-compiler> make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all Change-Id: If364dc36bd34b30cc356f74b3e97633933e6c8ee Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
Include multi-chip-mode parameter in HW_CONFIG dts to let next stage of boot firmware know about the multi-chip operation mode. Change-Id: Ic7535c2280fd57180ad14aa0ae277cf0c4d1337b Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
RD-N1-Edge based platforms can operate in dual-chip configuration wherein two rdn1edge SoCs are connected through a high speed coherent CCIX link. This patch adds a function to check if the RD-N1-Edge platform is operating in multi-chip mode by reading the SID register's NODE_ID value. If operating in multi-chip mode, initialize GIC-600 multi-chip operation by overriding the default GICR frames with array of GICR frames and setting the chip 0 as routing table owner. The address space of the second RD-N1-Edge chip (chip 1) starts from the address 4TB. So increase the physical and virtual address space size to 43 bits to accommodate the multi-chip configuration. If the multi-chip mode configuration is detected, dynamically add mmap entry for the peripherals memory region of the second RD-N1-Edge SoC. This is required to let the BL31 platform setup stage to configure the devices in the second chip. PLATFORM_CORE_COUNT macro is set to be multiple of CSS_SGI_CHIP_COUNT and topology changes are added to represent the dual-chip configuration. In order the build the dual-chip platform, CSS_SGI_CHIP_COUNT macro should be set to 2: export CROSS_COMPILE=<path-to-cross-compiler> make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all Change-Id: I576cdaf71f0b0e41b9a9181fa4feb7091f8c7bb4 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
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>
-
Vijayenthiran Subramaniam authored
AFF3 bits of MPIDR corresponds to Chip-Id in Arm multi-chip platforms. For calculating linear core position of CPU cores from slave chips, AFF3 bits has to be used. Update `plat_arm_calc_core_pos` assembly function to include AFF3 bits in calculation. Change-Id: I4af2bd82ab8e31e18bc61de22705a73893954260 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
Some of the Reference Design platforms like RD-N1-Edge can operate in multi-chip configuration wherein two or more SoCs are connected through a high speed coherent CCIX link. For the RD platforms, the remote chip address space is at the offset of 4TB per chip. In order for the primary chip to access the device memory region on the remote chip, the required memory region entries need to be added as mmap entry. This patch adds macros related to the remote chip device memory region. Change-Id: I833810b96f1a0e7c3c289ac32597b6ba03344c80 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
Multi-chip platforms have two or more identical chips connected using a high speed coherent link. In order to identify such platforms, add chip_id and multi_chip_mode information in the platform variant info structure. The values of these two new elements is populated during boot. Change-Id: Ie6e89cb33b3f0f408814f6239cd06647053e23ed Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
For SGI-575 and RD platforms, move bl31_platform_setup handler to individual board files to allow the platforms to perform board specific bl31 setup. Change-Id: Ia44bccc0a7f40a155b33909bcb438a0909b20d42 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@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>
-
- 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>
-
- 24 Jan, 2020 1 commit
-
-
Chris Kay authored
As on SGI platforms, SCPI is unsupported on SGM platforms. Change-Id: I556ed095b9eb55b72447230ee2725d3c76160a08 Signed-off-by: Chris Kay <chris.kay@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
-
- 20 Dec, 2019 3 commits
-
-
Paul Beesley authored
The contents of this header have been merged into the spm_mm_svc.h header file. Change-Id: I01530b2e4ec1b4c091ce339758025e2216e740a4 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: I91c192924433226b54d33e57d56d146c1c6df81b Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
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>
-