- 09 Dec, 2020 1 commit
-
-
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
-
- 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>
-
- 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>
-
- 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 10 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>
-
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>
-
- 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>
-
- 20 Dec, 2019 5 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>
-
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>
-
- 01 Aug, 2019 1 commit
-
-
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>
-
- 17 Apr, 2019 1 commit
-
-
Aditya Angadi authored
The BL1 stage setup code for ARM platforms sets up the SP805 watchdog controller as the secure watchdog. But not all ARM platforms use SP805 as the secure watchdog controller. So introduce two new ARM platform code specific wrapper functions to start and stop the secure watchdog. These functions then replace the calls to SP805 driver in common BL1 setup code. All the ARM platforms implement these wrapper functions by either calling into SP805 driver or the SBSA watchdog driver. Change-Id: I1a9a11b124cf3fac2a84f22ca40acd440a441257 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 01 Apr, 2019 1 commit
-
-
Ambroise Vincent authored
Improved support for W=1 compilation flag by solving missing-prototypes and old-style-definition warnings. The libraries are compiling with warnings (which turn into errors with the Werror flag). Outside of libraries, some warnings cannot be fixed without heavy structural changes. Change-Id: I1668cf99123ac4195c2a6a1d48945f7a64c67f16 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
-
- 28 Feb, 2019 1 commit
-
-
Chandni Cherukuri authored
Replace all uses of 'SGI_CLARK' with 'RD_N1E1_EDGE' and 'SGI_CLARK_HELIOS' with 'RD_E1_EDGE' as per the updated product names Change-Id: Ib8136e421b1a46da1e5df58c6b1432d5c78d279b Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 19 Feb, 2019 1 commit
-
-
John Tsichritzis authored
Change-Id: Ideb49011da35f39ff1959be6f5015fa212ca2b6b Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
-
- 01 Feb, 2019 1 commit
-
-
Antonio Nino Diaz authored
Many parts of the code were duplicating symbols that are defined in include/common/bl_common.h. It is better to only use the definitions in this header. As all the symbols refer to virtual addresses, they have to be uintptr_t, not unsigned long. This has also been fixed in bl_common.h. Change-Id: I204081af78326ced03fb05f69846f229d324c711 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 25 Jan, 2019 3 commits
-
-
Antonio Nino Diaz authored
Change-Id: I656753a1825ea7340a3708b950fa6b57455e9056 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Change-Id: I8989d2aa0258bf3b50a856c5b81532d578600124 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Use full include paths like it is done for common includes. This cleanup was started in commit d40e0e08283a ("Sanitise includes across codebase"), but it only cleaned common files and drivers. This patch does the same to Arm platforms. Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 Jan, 2019 1 commit
-
-
Sathees Balya authored
On ARM platforms, the BL2 memory can be overlaid by BL31/BL32. The memory descriptors describing the list of executable images are created in BL2 R/W memory, which could be possibly corrupted later on by BL31/BL32 due to overlay. This patch creates a reserved location in SRAM for these descriptors and are copied over by BL2 before handing over to next BL image. Also this patch increases the PLAT_ARM_MAX_BL2_SIZE for juno when TBBR is enabled. Fixes ARM-Software/tf-issues#626 Change-Id: I755735706fa702024b4032f51ed4895b3687377f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
-
- 15 Jan, 2019 2 commits
-
-
Antonio Nino Diaz authored
From now on, platform_def.h must include any header with definitions that are platform-specific (like arm_def.h) and the included headers mustn't include back platform_def.h, and shouldn't be used by other files. Only platform_def.h should be included in other files. This will ensure that all needed definitions are present, rather than needing to include all the headers in all the definitions' headers just in case. This also prevents problems like cyclic dependencies. Change-Id: I9d3cf4d1de4b956fa035c79545222697acdaf5ca Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
The definitions in bl1/bl1_private.h and bl2/bl2_private.h are useful for platforms that may need to access them. Change-Id: Ifd1880f855ddafcb3bfcaf1ed4a4e0f121eda174 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-