- 24 Feb, 2020 2 commits
-
-
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>
-
- 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 15 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>
-
Louis Mayencourt authored
Move the loading of the dtb from arm_dym_cfg to fconf. The new loading function is not associated to arm platform anymore, and can be moved to bl_main if wanted. Change-Id: I847d07eaba36d31d9d3ed9eba8e58666ea1ba563 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 06 Feb, 2020 2 commits
-
-
Max Shvetsov authored
Enables usage of ARM_ROTPK_LOCATION=regs for FVP board. Removes hard-coded developer keys. Instead, setting ARM_ROTPK_LOCATION=devel_* takes keys from default directory. In case of ROT_KEY specified - generates a new hash and replaces the original. Note: Juno board was tested by original feature author and was not tested for this patch since we don't have access to the private key. Juno implementation was moved to board-specific file without changing functionality. It is not known whether byte-swapping is still needed for this platform. Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986 Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
-
Louis Mayencourt authored
Stack usage reaches 90% with some configuration. Bump slightly the stack size to prevent a stack-overflow. Change-Id: I44ce8b12906586a42f152b7677785fcdc5e78ae1 Signed-off-by: Louis Mayencourt <louis.mayencourt@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>
-
- 03 Feb, 2020 1 commit
-
-
Alexei Fedorov authored
This patch adds 'fdtw_read_bytes' and 'fdtw_write_inplace_bytes' functions for read/write array of bytes from/to a given property. It also adds 'fdt_setprop_inplace_namelen_partial' to jmptbl.i files for builds with USE_ROMLIB=1 option. Change-Id: Ied7b5c8b38a0e21d508aa7bcf5893e656028b14d Signed-off-by: Alexei Fedorov <Alexei.Fedorov@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>
-
- 10 Jan, 2020 2 commits
-
-
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
-
Alexei Fedorov authored
This patch removes re-definition of the following FVP build options from plat\arm\board\fvp\fvp_def.h: 'FVP_CLUSTER_COUNT' 'FVP_MAX_CPUS_PER_CLUSTER' 'FVP_MAX_PE_PER_CPU' which are set in platform.mk. This fixes a potential problem when a build option set in platform.mk file can be re-defined in fvp_def.h header file used by other build component with a different makefile which does not set this option. Ref. GENFW-3505. Change-Id: I4288629920516acf2c239c7b733f92a0c5a812ff Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 07 Jan, 2020 3 commits
-
-
Ambroise Vincent authored
The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
-
Avinash Mehta authored
Point boot address to DDR location for booting A5DS FPGA FIP, Kernel and rootfs are sideloaded to DDR Also move BL2 to higher address in DDR Change-Id: Ia2a57a0bda776a1a0a96bcd3cfb5c6cd2cf4dc04 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
-
Avinash Mehta authored
Correct the system, timer and uart frequencies to successfully run the stack on FPGA Correct Cortex-A5MPcore to 8 word granularity for Cache writeback Change-Id: I2c59c26b7dca440791ad39f2297c68ae513da7b6 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
-
- 03 Jan, 2020 1 commit
-
-
Vishnu Banavath authored
The SCU connects one to four Cortex-A5/Cortex-A9 processors to the memory system through the AXI interfaces. The SCU functions are to: - maintain data cache coherency between the Cortex-A5/Cortex-A9 processors - initiate L2 AXI memory accesses - arbitrate between Cortex-A5/Cortex-A9 processors requesting L2 accesses - manage ACP accesses. Snoop Control Unit will enable to snoop on other CPUs caches. This is very important when it comes to synchronizing data between CPUs. As an example, there is a high chance that data might be cache'd and other CPUs can't see the change. In such cases, if snoop control unit is enabled, data is synchoronized immediately between CPUs and the changes are visible to other CPUs. This driver provides functionality to enable SCU as well as enabling user to know the following - number of CPUs present - is a particular CPU operating in SMP mode or AMP mode - data cache size of a particular CPU - does SCU has ACP port - is L2CPRESENT Change-Id: I0d977970154fa60df57caf449200d471f02312a0 Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>
-