- 19 May, 2021 1 commit
-
-
Manish V Badarkhe authored
Added support for HW computed CRC using Arm ACLE intrinsics. These are built-in intrinsics available for ARMv8.1-A, and onwards. These intrinsics are enabled via '-march=armv8-a+crc' compile switch for ARMv8-A (supports CRC instructions optionally). HW CRC support is enabled unconditionally in BL2 for all Arm platforms. HW CRC calculation is verified offline to ensure a similar result as its respective ZLib utility function. HW CRC calculation support will be used in the upcoming firmware update patches. Change-Id: Ia2ae801f62d2003e89a9c3e6d77469b5312614b3 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 17 May, 2021 1 commit
-
-
Zelalem authored
Disable non-invasive debug of secure state for Juno in release builds. This makes sure that PMU counts only Non-secure events. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I0d1c3f96f3b4e48360a7211ae55851d65d291025
-
- 03 May, 2021 1 commit
-
-
Pranav Madhu authored
AMU counters are used for monitoring the CPU performance. RD-V1-MC platform has architected AMU available for each core. Enable the use of AMU by non-secure OS for supporting the use of counters for processor performance control (ACPI CPPC). Change-Id: I33be594cee669e7f4031e5e5a371eec7c7451030 Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
-
- 29 Apr, 2021 1 commit
-
-
Manish V Badarkhe authored
Added GPT parser support in BL2 for Arm platforms to get the entry address and length of the FIP in the GPT image. Also, increased BL2 maximum size for FVP platform to successfully compile ROM-enabled build with this change. Verified this change using a patch: https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/9654 Change-Id: Ie8026db054966653b739a82d9ba106d283f534d0 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 28 Apr, 2021 2 commits
-
-
David Horstmann authored
NOTE: Breaking change to the way UUIDs are stored in the DT Currently, UUIDs are stored in the device tree as sequences of 4 integers. There is a mismatch in endianness between the way UUIDs are represented in memory and the way they are parsed from the device tree. As a result, we must either store the UUIDs in little-endian format in the DT (which means that they do not match up with their string representations) or perform endianness conversion after parsing them. Currently, TF-A chooses the second option, with unwieldy endianness-conversion taking place after reading a UUID. To fix this problem, and to make it convenient to copy and paste UUIDs from other tools, change to store UUIDs in string format, using a new wrapper function to parse them from the device tree. Change-Id: I38bd63c907be14e412f03ef0aab9dcabfba0eaa0 Signed-off-by: David Horstmann <david.horstmann@arm.com>
-
Manish V Badarkhe authored
Replaced PLAT_ARM_FIP_BASE and PLAT_ARM_FIP_MAX_SIZE macro with a generic name PLAT_ARM_FLASH_IMAGE_BASE and PLAT_ARM_FLASH_IMAGE_MAX_SIZE so that these macros can be reused in the subsequent GPT based support changes. Change-Id: I88fdbd53e1966578af4f1e8e9d5fef42c27b1173 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 27 Apr, 2021 2 commits
-
-
Aditya Angadi authored
Add board support for RD-N2 Cfg1 variant of RD-N2 platform. It is a variant of RD-N2 platform with a reduced interconnect mesh size (3x3) and core count (8-cores). Its platform variant id is 1. Change-Id: I34ad35c5a5c1e9b69a658fb92ed00e5bc5fe72f3 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
Aditya Angadi authored
A Neoverse reference design platform can have two or more variants that differ in core count, cluster count or other peripherals. To allow reuse of platform code across all the variants of a platform, introduce build option CSS_SGI_PLATFORM_VARIANT for Arm Neoverse reference design platforms. The range of allowed values for the build option is platform specific. The recommended range is an interval of non negative integers. An example usage of the build option is make PLAT=rdn2 CSS_SGI_PLATFORM_VARIANT=1 Change-Id: Iaae79c0b4d0dc700521bf6e9b4979339eafe0359 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 26 Apr, 2021 1 commit
-
-
Manish Pandey authored
This will help in keeping source file generic and conditional compilation can be contained in platform provided dt files. Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: I3c6e0a429073f0afb412b9ba521ce43f880b57fe
-
- 23 Apr, 2021 1 commit
-
-
Manish Pandey authored
sgm775 is an old platform and is no longer maintained by Arm and its fast model FVP_CSS_SGM-775 is no longer available for download. This platform is now superseded by Total Compute(tc) platforms. This platform is now deprecated but the source will be kept for cooling off period of 2 release cycle before removing it completely. Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: I8fe1fc3da0c508dba62ed4fc60cbc1642e0f7f2a
-
- 20 Apr, 2021 3 commits
-
-
johpow01 authored
ELP processors can sometimes have different MIDR values or features so we are adding the "_arm" suffix to differentiate the reference implementation from other future versions. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: Ieea444288587c7c18a397d279ee4b22b7ad79e20
-
Mikael Olsson authored
By default the Arm Ethos-N NPU will boot up in secure mode. In this mode the non-secure world cannot access the registers needed to use the NPU. To still allow the non-secure world to use the NPU, a SiP service has been added that can delegate non-secure access to the registers needed to use it. Only the HW_CONFIG for the Arm Juno platform has been updated to include the device tree for the NPU and the platform currently only loads the HW_CONFIG in AArch64 builds. Signed-off-by: Mikael Olsson <mikael.olsson@arm.com> Change-Id: I65dfd864042ed43faae0a259dcf319cbadb5f3d2
-
Mikael Olsson authored
To make it possible to use the hw_config device tree for dynamic configuration in BL31 on the Arm Juno platform. A placeholder hw_config has been added that is included in the FIP and a Juno specific BL31 setup has been added to populate fconf with the hw_config. Juno's BL2 setup has been updated to align it with the new behavior implemented in the Arm FVP platform, where fw_config is passed in arg1 to BL31 instead of soc_fw_config. The BL31 setup is expected to use the fw_config passed in arg1 to find the hw_config. Signed-off-by: Mikael Olsson <mikael.olsson@arm.com> Change-Id: Ib3570faa6714f92ab8451e8f1e59779dcf19c0b6
-
- 16 Apr, 2021 1 commit
-
-
Sandrine Bailleux authored
Remove an incorrect tabulation in front of an $(error) function call outside of a recipe, which caused the following text to be displayed: plat/arm/board/common/board_common.mk:36: *** recipe commences before first target. Stop. instead of: plat/arm/board/common/board_common.mk:36: *** "Unsupported ARM_ROTPK_LOCATION value". Stop. Change-Id: I8592948e7de8ab0c4abbc56eb65a53eb1875a83c Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 14 Apr, 2021 1 commit
-
-
Usama Arif authored
The number of ITS have changed from 4 to 1, resulting in GICR base address change. Signed-off-by: Usama Arif <usama.arif@arm.com> Change-Id: I28101f0d1faf9f3c58591b642033c3fd49a275e7
-
- 09 Apr, 2021 1 commit
-
-
Manish Pandey authored
NT_FW_CONFIG file is meant to be passed from BL31 to be consumed by BL33, fvp platforms use this to pass measured boot configuration and the x0 register is used to pass the base address of it. In case of hafnium used as hypervisor in normal world, hypervisor manifest is expected to be passed from BL31 and its base address is passed in x0 register. As only one of NT_FW_CONFIG or hypervisor manifest base address can be passed in x0 register and also measured boot is not required for SPM so disable passing NT_FW_CONFIG. Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: Ifad9d3658f55ba7d70f468a88997d5272339e53e
-
- 06 Apr, 2021 2 commits
-
-
Heyi Guo authored
Refine the function plat_add_sp_images_load_info() by saving the previous node and only setting its next link when the current node is valid. This can reduce the check for the next node and simply the total logic. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Change-Id: I4061428bf49ef0c3816ac22aaeb2e50315531f88
-
Heyi Guo authored
The traverse flow in function plat_add_sp_images_load_info() will find the last node in the main load info list, with its next_load_info==NULL. However this node is still useful and should not be overridden with SP node info. The bug will cause below error on RDN2 for spmd enabled: ERROR: Invalid NT_FW_CONFIG DTB passed Fix the bug by only setting the next_load_info of the last node in the original main node list. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Change-Id: Icaee5da1f2d53b29fdd6085a8cc507446186fd57
-
- 31 Mar, 2021 1 commit
-
-
Bipin Ravi authored
Add basic support for Cortex_A78C CPU. Signed-off-by: Bipin Ravi <bipin.ravi@arm.com> Change-Id: Id9e41cbe0580a68c6412d194a5ee67940e8dae56
-
- 29 Mar, 2021 9 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
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 across the Chips. For use by secure software, configure the first chip's trustzone controller to protect the upper 16MB of the memory of the first DRAM block for secure accesses only. The other regions are configured for non-secure read write access. For all the remote chips, all the DRAM regions are allowed for non-secure read and write access. Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Change-Id: I809f27eccadfc23ea0ef64e2fd87f95eb8f195c1
-
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
-
- 24 Mar, 2021 1 commit
-
-
johpow01 authored
Add basic support for Makalu ELP processor core. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I7b1ddbb8dd43326ecb8ff188f6f8fcf239826a93
-
- 15 Mar, 2021 1 commit
-
-
Olivier Deprez authored
The FF-A v1.0 spec allows two configurations for the number of EC/vCPU instantiated in a Secure Partition: -A MultiProcessor (MP) SP instantiates as many ECs as the number of PEs. An EC is pinned to a corresponding physical CPU. -An UniProcessor (UP) SP instantiates a single EC. The EC is migrated to the physical CPU from which the FF-A call is originating. This change permits exercising the latter case within the TF-A-tests framework. Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: I7fae0e7b873f349b34e57de5cea496210123aea0
-
- 10 Mar, 2021 1 commit
-
-
Usama Arif authored
Signed-off-by: Usama Arif <usama.arif@arm.com> Change-Id: Ie199c60553477c43d1665548ae78cdfd1aa7ffcf
-
- 01 Mar, 2021 1 commit
-
-
johpow01 authored
Add basic support for Makalu CPU. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I4e85d425eedea499adf585eb8ab548931185043d
-
- 17 Feb, 2021 1 commit
-
-
Aditya Angadi authored
Rename rd_n1e1_edge_scmi_plat_info array to plat_rd_scmi_info as the same array is used to provide SCMI platform info across mulitple RD platforms and is not resitricted to only RD-N1 and RD-E1 platforms. Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Change-Id: I42ba33e0afa3003c731ce513c6a5754b602ec01f
-
- 16 Feb, 2021 1 commit
-
-
Andre Przywara authored
Now that we have a framework for the SMCCC TRNG interface, and the existing Juno entropy code has been prepared, add the few remaining bits to implement this interface for the Juno Trusted Entropy Source. We retire the existing Juno specific RNG interface, and use the generic one for the stack canary generation. Change-Id: Ib6a6e5568cb8e0059d71740e2d18d6817b07127d Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 15 Feb, 2021 1 commit
-
-
Andre Przywara authored
The Juno Trusted Entropy Source has a bias, which makes the generated raw numbers fail a FIPS 140-2 statistic test. To improve the quality of the numbers, we can use the CPU's CRC instructions, which do a decent job on conditioning the bits. This adds a *very* simple version of arm_acle.h, which is typically provided by the compiler, and contains the CRC instrinsics definitions we need. We need the original version by using -nostdinc. Change-Id: I83d3e6902d6a1164aacd5060ac13a38f0057bd1a Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 11 Feb, 2021 2 commits
-
-
Andre Przywara authored
Currently we use the Juno's TRNG hardware entropy source to initialise the stack canary. The current function allows to fill a buffer of any size, but we will actually only ever request 16 bytes, as this is what the hardware implements. Out of this, we only need at most 64 bits for the canary. In preparation for the introduction of the SMCCC TRNG interface, we can simplify this Juno specific interface by making it compatible with the generic one: We just deliver 64 bits of entropy on each call. This reduces the complexity of the code. As the raw entropy register readouts seem to be biased, it makes sense to do some conditioning inside the juno_getentropy() function already. Also initialise the TRNG hardware, if not already done. Change-Id: I11b977ddc5417d52ac38709a9a7b61499eee481f Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Vijayenthiran Subramaniam authored
Update TZC base address to align with the recent changes in the platform memory map. Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> Change-Id: I0d0ad528a2e236607c744979e1ddc5c6d426687a
-
- 09 Feb, 2021 3 commits
-
-
Manish V Badarkhe authored
Currently, BLs are mapping the GIC memory region as read-write for all cores on boot-up. This opens up the security hole where the active core can write the GICR frame of fused/inactive core. To avoid this issue, disable the GICR frame of all inactive cores as below: 1. After primary CPU boots up, map GICR region of all cores as read-only. 2. After primary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 3. After secondary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 4. All unused/fused core's redistributor regions remain read-only and write attempt to such protected regions results in an exception. As mentioned above, this patch offers only the GICR memory-mapped region protection considering there is no facility at the GIC IP level to avoid writing the redistributor area. These changes are currently done in BL31 of Arm FVP and guarded under the flag 'FVP_GICR_REGION_PROTECTION'. As of now, this patch is tested manually as below: 1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core. 2. Verify data abort triggered by manually updating the ‘GICR_CTLR’ register of core 1’s(fused) redistributor from core 0(active). Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
Manish V Badarkhe authored
GIC memory region is not getting used in BL1 and BL2. Hence avoid its mapping in BL1 and BL2 that freed some page table entries to map other memory regions in the future. Retains mapping of CCN interconnect region in BL1 and BL2 overlapped with the GIC memory region. Change-Id: I880dd0690f94b140e59e4ff0c0d436961b9cb0a7 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
Andre Przywara authored
So far the ARM platform Makefile would require that RESET_TO_BL31 is set when we ask for the ARM_LINUX_KERNEL_AS_BL33 feature. There is no real technical reason for that, and the one place in the code where this was needed has been fixed. Remove the requirement of those two options to be always enabled together. This enables the direct kernel boot feature for the Foundation FVP (as described in the documentation), which requires a BL1/FIP combination to boot, so cannot use RESET_TO_BL31. Change-Id: I6814797b6431b6614d684bab3c5830bfd9481851 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-