- 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 2 commits
-
-
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>
-
Chandni Cherukuri authored
In preparation of adding support for upcoming SGI platforms, macros common to all the SGI platforms are moved into sgi_base_platform_def.h file. Macros that are specific to sgi575 platform remain in the platform_def.h file. In addition to this, the platform_def.h file is moved to sgi575 board directory. Also the ENT_CPU_SOURCES has been renamed to SGI_CPU_SOURCES and moved from sgi-common.mk to board specific makefile platform.mk Change-Id: Iccdd9f070f4feea232b9fbf4fdcc0ef2e8eccbf2 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 11 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 02 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
This option makes it hard to optimize the memory definitions of all Arm platforms because any change in the common defines must work in all of them. The best thing to do is to remove it and move the definition to each platform's header. FVP, SGI and SGM were using the definitions in board_arm_def.h. The definitions have been copied to each platform's platform_def.h. Juno was already using the ones in platform_def.h, so there have been no changes. Change-Id: I9aecd11bbc72a3d0d7aad1ef9934d8df21dcfaf2 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 28 Sep, 2018 1 commit
-
-
Antonio Nino Diaz authored
- Remove references to removed build options. - Remove support for LOAD_IMAGE_V2=0. Change-Id: I296385ef2ebf829446c76a54400d73f963ed265f Tested-by: Nariman Poushin <nariman.poushin@linaro.org> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 03 Aug, 2018 1 commit
-
-
Chandni Cherukuri authored
The Arm SGI platforms can switch to using SCMI. So enable support for SCMI and remove portions of code that would be unused after switching to SCMI. Change-Id: Ifd9e1c944745f703da5f970b5daf1be2b07ed14e Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 26 Jul, 2018 4 commits
-
-
Sughosh Ganu authored
Add platform specific changes needed to add support for the RAS feature on SGI575 platform, including adding a mapping for the CPER buffer being used on SGI575 platform. Change-Id: I01a982e283609b5c48661307906346fa2738a43b Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
-
Sughosh Ganu authored
Add a platform specific handler for RAS interrupts and configure the platform RAS interrupts for EL3 handling. The interrupt handler passes control to StandaloneMM code executing in S-EL0, which populates the CPER buffer with relevant error information. The handler subsequently invokes the SDEI client which processes the information in the error information in the CPER buffer. The helper functions plat_sgi_get_ras_ev_map and plat_sgi_get_ras_ev_map_size would be defined for sgi platforms in the subsequent patch, which adds sgi575 specific RAS changes. Change-Id: I490f16c15d9917ac40bdc0441659b92380108d63 Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
-
Sughosh Ganu authored
The secure partition manager reserves chunks of memory which are used for the S-EL0 StandaloneMM image and the buffers required for communication between the Non-Secure world with the StandaloneMM image. Add the memory chunks to relevant arrays for mapping the regions of memory with corresponding attributes. Change-Id: If371d1afee0a50ca7cacd55e16aeaca949d5062b Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
-
Sughosh Ganu authored
The SGI platforms need to allocate memory for CPER buffers. These platform buffers would be placed between the shared reserved memory and the per cpu stack memory, thus the need to redefine stack base pointer for these platforms. This patch allows each board in ARM platform to define the PLAT_SP_IMAGE_STACK_BASE. Change-Id: Ib5465448b860ab7ab0f645f7cb278a67acce7be9 Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
-