- 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>
-
- 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>
-
- 03 Mar, 2020 2 commits
-
-
Max Shvetsov authored
Added SPMD_SPM_AT_SEL2 build command line parameter. Set to 1 to run SPM at S-EL2. Set to 0 to run SPM at S-EL1 (pre-v8.4 or S-EL2 is disabled). Removed runtime EL from SPM core manifest. Change-Id: Icb4f5ea4c800f266880db1d410d63fe27a1171c0 Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
-
Manish Pandey authored
Add load address and UUID in fw config dts for Cactus and Ivy which are example SP's in tf-test repository. For prototype purpose these information is added manually but later on it will be updated at compile time from SP layout file and SP manifests provided by platform. Change-Id: I41f485e0245d882c7b514bad41fae34036597ce4 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 25 Feb, 2020 1 commit
-
-
Alexei Fedorov authored
This patch fixes incorrect setting for DEVICE1_SIZE for FVP platforms with more than 8 PEs. The current value of 0x200000 supports only 8 PEs and causes exception for FVP platforms with the greater number of PEs, e.g. FVP_Base_Cortex_A65AEx8 with 16 PEs in one cluster. Change-Id: Ie6391509fe6eeafb8ba779303636cd762e7d21b2 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 24 Feb, 2020 5 commits
-
-
Petre-Ionut Tudor authored
This patch introduces a build flag which allows the xlat tables to be mapped in a read-only region within BL31 memory. It makes it much harder for someone who has acquired the ability to write to arbitrary secure memory addresses to gain control of the translation tables. The memory attributes of the descriptors describing the tables themselves are changed to read-only secure data. This change happens at the end of BL31 runtime setup. Until this point, the tables have read-write permissions. This gives a window of opportunity for changes to be made to the tables with the MMU on (e.g. reclaiming init code). No changes can be made to the tables with the MMU turned on from this point onwards. This change is also enabled for sp_min and tspd. To make all this possible, the base table was moved to .rodata. The penalty we pay is that now .rodata must be aligned to the size of the base table (512B alignment). Still, this is better than putting the base table with the higher level tables in the xlat_table section, as that would cost us a full 4KB page. Changing the tables from read-write to read-only cannot be done with the MMU on, as the break-before-make sequence would invalidate the descriptor which resolves the level 3 page table where that very descriptor is located. This would make the translation required for writing the changes impossible, generating an MMU fault. The caches are also flushed. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
-
Sandrine Bailleux authored
The dualroot chain of trust involves 2 root-of-trust public keys: - The classic ROTPK. - The platform ROTPK (a.k.a. PROTPK). Use the cookie argument as a key ID for plat_get_rotpk_info() to return the appropriate one. This only applies if we are using the dualroot CoT ; if using the TBBR one, the behaviour is unchanged. Change-Id: I400707a87ec01afd5922b68db31d652d787f79bd Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
The cookie will be leveraged in the next commit. Change-Id: Ie8bad275d856d84c27466461cf815529dd860446 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
- Use the development PROTPK if using the dualroot CoT. Note that unlike the ROTPK, the PROTPK key hash file is not generated from the key file, instead it has to be provided. This might be enhanced in the future. - Define a CoT build flag for the platform code to provide different implementations where needed. Change-Id: Iaaf25183b94e77a99a5d8d875831d90c102a97ea Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
When using the new dualroot chain of trust, a new root of trust key is needed to authenticate the images belonging to the platform owner. Provide a development one to deploy this on Arm platforms. Change-Id: I481145e09aa564822d474cb47d38ec211dd24efd Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 19 Feb, 2020 4 commits
-
-
Suyash Pathak authored
A TZC400 controller is placed inline on DRAM channels and regulates the secure and non-secure accesses to both secure and non-secure regions of the DRAM memory. Configure each of the TZC controllers accordingly. Change-Id: I75f6d13591a7fe9e50ce15c793e35a8018041815 Signed-off-by: Suyash Pathak <suyash.pathak@arm.com>
-
Suyash Pathak authored
For platforms that have two or more TZC400 controllers instantiated, allow the TZC400 driver to be usable with all those instances. This is achieved by allowing 'arm_tzc400_setup' function to accept the base address of the TZC400 controller. Change-Id: I4add470e6ddb58432cd066145e644112400ab924 Signed-off-by: Suyash Pathak <suyash.pathak@arm.com>
-
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>
-
Suyash Pathak authored
A TZC400 can have upto 4 filters and the number of filters instantiated within a TZC400 is platform dependent. So allow platforms to define the value of PLAT_ARM_TZC_FILTERS by moving the existing Juno specific definition of PLAT_ARM_TZC_FILTERS to Juno board definitions. Change-Id: I67a63d7336595bbfdce3163f9a9473e15e266f40 Signed-off-by: Suyash Pathak <suyash.pathak@arm.com>
-
- 18 Feb, 2020 4 commits
-
-
Vijayenthiran Subramaniam authored
Use CREATE_SEQ helper macro to create sequence of valid chip counts instead of manually creating the sequence. This allows a scalable approach to increase the valid chip count sequence in the future. Change-Id: I5ca7a00460325c156b9e9e52b2bf656a2e43f82d Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Jimmy Brisson authored
Also update copyright statements Change-Id: Iba0305522ac0f2ddc4da99127fd773f340e67300 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
Jimmy Brisson authored
Change-Id: I686fd623b8264c85434853a2a26ecd71e9eeac01 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
Alexei Fedorov authored
When TF-A is built with RESET_TO_BL31=1 option, BL31 is the first image to be run and should have all the memory allocated to it except for the memory reserved for Shared RAM at the start of Trusted SRAM. This patch fixes FVP BL31 load address and its image size for RESET_TO_BL31=1 option. BL31 startup address should be set to 0x400_1000 and its maximum image size to the size of Trusted SRAM minus the first 4KB of shared memory. Loading BL31 at 0x0402_0000 as it is currently stated in '\docs\plat\arm\fvp\index.rst' causes EL3 exception when the image size gets increased (i.e. building with LOG_LEVEL=50) but doesn't exceed 0x3B000 not causing build error. Change-Id: Ie450baaf247f1577112f8d143b24e76c39d33e91 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 17 Feb, 2020 3 commits
-
-
Vishnu Banavath authored
Adding support for 32MHz UART clock and selecting it as the default UART clock Change-Id: I9541eaff70424e85a3b5ee4820ca0e7efb040d2c Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
-
Avinash Mehta authored
Running checkpatch.pl on the codebase and making required changes Change-Id: I7d3f8764cef632ab2a6d3c355c68f590440b85b8 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
-
Khandelwal authored
Note: This patch implements in-band messaging protocol only. ARM has launched a next version of MHU i.e. MHUv2 with its latest subsystems. The main change is that the MHUv2 is now a distributed IP with different peripheral views (registers) for the sender and receiver. Another main difference is that MHUv1 duplex channels are now split into simplex/half duplex in MHUv2. MHUv2 has a configurable number of communication channels. There is a capability register (MSG_NO_CAP) to find out how many channels are available in a system. The register offsets have also changed for STAT, SET & CLEAR registers from 0x0, 0x8 & 0x10 in MHUv1 to 0x0, 0xC & 0x8 in MHUv2 respectively. 0x0 0x4 0x8 0xC 0x1F ------------------------....----- | STAT | | | SET | | | ------------------------....----- Transmit Channel 0x0 0x4 0x8 0xC 0x1F ------------------------....----- | STAT | | CLR | | | | ------------------------....----- Receive Channel The MHU controller can request the receiver to wake-up and once the request is removed, the receiver may go back to sleep, but the MHU itself does not actively put a receiver to sleep. So, in order to wake-up the receiver when the sender wants to send data, the sender has to set ACCESS_REQUEST register first in order to wake-up receiver, state of which can be detected using ACCESS_READY register. ACCESS_REQUEST has an offset of 0xF88 & ACCESS_READY has an offset of 0xF8C and are accessible only on any sender channel. This patch adds necessary changes in a new file required to support the latest MHUv2 controller. This patch also needs an update in DT binding for ARM MHUv2 as we need a second register base (tx base) which would be used as the send channel base. Change-Id: I1455e08b3d88671a191c558790c503eabe07a8e6 Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
-
- 13 Feb, 2020 1 commit
-
-
Morten Borup Petersen authored
Adding support for generating a semi-random number required for enabling building TF-A with stack protector support. TF-A for corstone-700 may now be built using ENABLE_STACK_PROTECTOR=all Change-Id: I03e1be1a8d4e4a822cf286f3b9ad4da4337ca765 Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
-
- 12 Feb, 2020 1 commit
-
-
Louis Mayencourt authored
Change-Id: I011256ca60672a00b711c3f5725211be64bbc2b2 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 11 Feb, 2020 1 commit
-
-
Max Shvetsov authored
Forced hash generation used to always generate hash via RSA encryption. This patch changes encryption based on ARM_ROTPK_LOCATION. Also removes setting KEY_ALG based on ARM_ROTPL_LOCATION - there is no relation between these two. Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com> Change-Id: Id727d2ed06176a243719fd0adfa0cae26c325005
-
- 10 Feb, 2020 2 commits
-
-
Achin Gupta authored
This patch reserves and maps the Trusted DRAM for SPM core execution. It also configures the TrustZone address space controller to run BL31 in secure DRAM. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: I7e1bb3bbc61a0fec6a9cb595964ff553620c21dc
-
Achin Gupta authored
This patch repurposes the TOS FW configuration file as the manifest for the SPM core component which will reside at the secure EL adjacent to EL3. The SPM dispatcher component will use the manifest to determine how the core component must be initialised. Routines and data structure to parse the manifest have also been added. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb
-
- 07 Feb, 2020 14 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
RD-E1-Edge platform consists of two clusters with eight CPUs each and two processing elements (PE) per CPU. Commit a9fbf13e (plat/arm/sgi: move topology information to board folder) defined the RD-E1-Edge topology tree to have two clusters with eight CPUs each but PE per CPU entries were not added. This patch fixes the topology tree accordingly. Change-Id: I7f97f0013be60e5d51c214fce3962e246bae8a0b Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@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
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>
-
Louis Mayencourt authored
Currently, an IO setup failure will be ignored on arm platform release build. Change this to panic instead. Change-Id: I027a045bce2422b0a0fc4ff9e9d4c6e7bf5d2f98 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Change the return type of "arm_io_is_toc_valid()" and "plat_arm_bl1_fwu_needed()" to bool, to match function behavior. Change-Id: I503fba211219a241cb263149ef36ca14e3362a1c Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Use the firmware configuration framework to store the io_policies information inside the configuration device tree instead of the static structure in the code base. The io_policies required by BL1 can't be inside the dtb, as this one is loaded by BL1, and only available at BL2. This change currently only applies to FVP platform. Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
This patch introduces a better separation between the trusted-boot related properties, and the dynamic configuration DTBs loading information. The dynamic configuration DTBs properties are moved to a new node: `dtb-registry`. All the sub-nodes present will be provided to the dynamic config framework to be loaded. The node currently only contains the already defined configuration DTBs, but can be extended for future features if necessary. The dynamic config framework is modified to use the abstraction provided by the fconf framework, instead of directly accessing the DTBs. The trusted-boot properties are kept under the "arm,tb_fw" compatible string, but in a separate `tb_fw-config` node. The `tb_fw-config` property of the `dtb-registry` node simply points to the load address of `fw_config`, as the `tb_fw-config` is currently part of the same DTB. Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-