- 29 Mar, 2021 8 commits
-
-
Omkar Anand Kulkarni authored
Add the secure partition mmap table and the secure partition boot information to support secure partitions on RD-N2 platform. In addition to this, add the required memory region mapping for accessing the SoC peripherals from the secure partition. Signed-off-by: Omkar Anand Kulkarni <omkar.kulkarni@arm.com> Change-Id: I2c75760d6c8c3da3ff4885599be420e924aeaf3c
-
Aditya Angadi authored
On a multi-chip platform, the boot CPU on the first chip programs the TZC controllers on all the remote chips. Define a memory region map for the TZC controllers for all the remote chips and include it in the BL2 memory map table. In addition to this, for SPM_MM enabled multi-chip platforms, increase the number of mmap entries and xlat table counts for EL3 execution context as well because the shared RAM regions and GIC address space of remote chips are accessed. Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Change-Id: I6f0b5fd22f9f28046451e382eef7f1f9258d88f7
-
Aditya Angadi authored
For multi-chip platforms, add a macro to define the memory regions on chip numbers >1 and its associated access permissions. These memory regions are marked with non-secure access. Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Change-Id: If3d6180fd8ea61f45147c39d3140d694abf06617
-
Thomas Abraham authored
Allow the access of system registers and nor2 flash memory region from s-el0. This allows the secure parititions residing at s-el0 to access these memory regions. Signed-off-by: Thomas Abraham <thomas.abraham@arm.com> Change-Id: I3887a86770de806323fbde0d20fdc96eec6e0c3c
-
Thomas Abraham authored
Define a default DMC-620 TZC memory region configuration and use it to specify the TZC memory regions on sgi575, rdn1edge and rde1edge platforms. The default DMC-620 TZC memory regions are defined considering the support for secure paritition as well. Signed-off-by: Thomas Abraham <thomas.abraham@arm.com> Change-Id: Iedee3e57d0d3de5b65321444da51ec990d3702db
-
Thomas Abraham authored
Remove the 'ARM_' prefix from the macros defining the CPER buffer memory and replace it with 'CSS_SGI_' prefix. These macros are applicable only for platforms supported within plat/sgi. In addition to this, ensure that these macros are defined only if the RAS_EXTENSION build option is enabled. Signed-off-by: Thomas Abraham <thomas.abraham@arm.com> Change-Id: I44df42cded18d9d3a4cb13e5c990e9ab3194daee
-
Thomas Abraham authored
The macros defining the SMC function ids for DMC-620 error handling are listed in the sgi_base_platform_def.h header file. But these macros are not applicable for all platforms supported under plat/sgi. So move these macro definitions to sgi_ras.c file in which these are consumed. While at it, remove the AArch32 and error injection function ids as these are unused. Signed-off-by: Thomas Abraham <thomas.abraham@arm.com> Change-Id: I249b54bf4c1b1694188a1e3b297345b942f16bc9
-
Thomas Abraham authored
The macros specific to SDEI defined in the sgi_base_platform_def.h are not applicable for all the platforms supported by plat/sgi. So refactor the SDEI specific macros into a new header file and include this file on only on platforms it is applicable on. Signed-off-by: Thomas Abraham <thomas.abraham@arm.com> Change-Id: I0cb7125334f02a21cae1837cdfd765c16ab50bf5
-
- 11 Jan, 2021 1 commit
-
-
Aditya Angadi authored
Reference Design platform RD-Daniel has been renamed to RD-V1. Correspondingly, remove all uses of 'rddaniel' and replace it with 'rdv1' where appropriate. Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Change-Id: I1702bab39c501f8c0a09df131cb2394d54c83bcf
-
- 09 Dec, 2020 3 commits
-
-
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>
-
- 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>
-
- 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>
-
- 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>
-
- 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 7 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
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
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>
-
- 20 Dec, 2019 2 commits
-
-
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>
-
- 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>
-
- 25 Jan, 2019 1 commit
-
-
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>
-
- 08 Jan, 2019 1 commit
-
-
Ard Biesheuvel authored
Update some asserts that refer to #defines that only occur in ARM platforms, preventing this code to be used on other platforms. Instead, use a platform agnostic name, and update all the existing users. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 06 Dec, 2018 1 commit
-
-
Chandni Cherukuri authored
SGI-Clark.Helios platform is based on multi-threaded CPUs and uses an additional thread power domain level as well. Define a power domain tree descriptor 'sgi_clark_helios_pd_tree_desc' for SGI-Clark.Helios platform and let the function 'plat_get_power_domain_tree_desc' pick up the correct power domain tree descriptor based on the platform. Change-Id: Ibc6d551b570bc740053316a3608c455679d9155b Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 03 Dec, 2018 1 commit
-
-
Chandni Cherukuri authored
Add two new functions 'plat_arm_sgi_get_platform_id' and 'plat_arm_sgi_get_config_id' which will be implemented by all the SGI platforms. These functions can be used to determine the part number and configuration id of the SGI platforms. In BL2, these functions are used to populate the 'system-id' node. In BL31, these functions are used to populate the 'sgi_plat_info_t' structure with the part number and configuration id of the platform. Change-Id: I3bacda933527724a3b4074ad4ed5b53a81ea4689 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 27 Nov, 2018 1 commit
-
-
Chandni Cherukuri authored
For platforms with multi-threaded CPUs, the number of power domains supported would be more than the value currently defined by PLAT_MAX_PWR_LVL. So move the PLAT_MAX_PWR_LVL macro to platform specific code and let the platform define the number of power domain levels. Change-Id: I21c0682e62b397860b2999031a0c9c5ce0d28eed Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 14 Nov, 2018 1 commit
-
-
Sughosh Ganu authored
Register a priority level, PLAT_SP_PRI, for secure partition with EL3 exception handling framework(ehf) module. The secure partition manager(SPM) would raise the core's priority to PLAT_SP_PRI before entering the secure partition, to protect the core from getting interrupted while in secure partition. Change-Id: I686897f052a4371e0efa9b929c07d3ad77249e95 Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
-
- 08 Nov, 2018 1 commit
-
-
Antonio Nino Diaz authored
All identifiers, regardless of use, that start with two underscores are reserved. This means they can't be used in header guards. The style that this project is now to use the full name of the file in capital letters followed by 'H'. For example, for a file called "uart_example.h", the header guard is UART_EXAMPLE_H. The exceptions are files that are imported from other projects: - CryptoCell driver - dt-bindings folders - zlib headers Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 26 Oct, 2018 1 commit
-
-
Chandni Cherukuri authored
SGI-Clark platform is the next version in the Arm's SGI platform series. One of the primary difference between the SGI-575 platform and the SGI-Clark platform is the MHU version (MHUv2 in case of SGI-Clark). Add the required base support for SGI-Clark platform. Change-Id: If396e5279fdf801d586662dad0b55195e81371e4 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 18 Oct, 2018 1 commit
-
-
Chandni Cherukuri authored
On SGI platforms, the interconnect is setup by the SCP and so the existing unused interconnect setup in sgi575 platform code can be removed. As a result of this, sgi_plat_config.c and sgi_bl1_setup.c files can be removed as these files are now empty or can be substainated by the existing weak functions. Change-Id: I3c883e4d1959d890bf2213a9be01f02551ea3a45 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-