- 14 Feb, 2018 1 commit
-
-
Antonio Nino Diaz authored
This fixes all defects according to MISRA Rule 3.1: "The character sequences /* and // shall not be used within a comment". This affects all URLs in comments, so they have been removed: - The link in `sdei_state.c` can also be found in the documentation file `docs/sdei.rst`. - The bug that the file `io_fip.c` talks about doesn't affect the currently supported version of GCC, so it doesn't make sense to keep the comment. Note that the version of GCC officially supported is the one that comes with Linaro Release 17.10, which is GCC 6.2. - The link in `tzc400.c` was broken, and it didn't correctly direct to the Technical Reference Manual it should. The link has been replaced by the title of the document, which is more convenient when looking for the document. Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 20 Apr, 2017 1 commit
-
-
Antonio Nino Diaz authored
Many asserts depend on code that is conditionally compiled based on the DEBUG define. This patch modifies the conditional inclusion of such code so that it is based on the ENABLE_ASSERTIONS build option. Change-Id: I6406674788aa7e1ad7c23d86ce94482ad3c382bd Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 18 Apr, 2017 1 commit
-
-
Antonio Nino Diaz authored
C files shouldn't be included into others. This file only contains some macros and functions that can be made `static inline`, so it is ok to convert it into a header file. This is the only occurrence of a C file being included in another one in the codebase instead of using a header, other occurrences are a way of achieving backwards-compatibility. Functions therein have been qualified as `inline`. Change-Id: I88fe300f6d85a7f0740ef14c9cb8fa54849218e6 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 10 Aug, 2016 1 commit
-
-
Soby Mathew authored
This patch modifies GICv3 and TZC drivers to add AArch32 support. No modifications are required for the GICv2 driver for AArch32 support. The TZC driver assumes that the secure world is running in Little-Endian mode to do 64 bit manipulations. Assertions are present to validate the assumption. Note: The legacy GICv3 driver is not supported for AArch32. Change-Id: Id1bc75a9f5dafb9715c9500ca77b4606eb1e2458
-
- 12 Apr, 2016 1 commit
-
-
Yatharth Kochar authored
Currently the `tzc400_configure_region` and `tzc_dmc500_configure_region` functions uses uintptr_t as the data type for `region_top` and `region_base` variables, which will be converted to 32/64 bits for AArch32/AArch64 respectively. But the expectation is to keep these addresses at least 64 bit. This patch modifies the data types to make it at least 64 bit by using unsigned long long instead of uintptr_t for the `region_top` and `region_base` variables. It also modifies the associated macros `_tzc##fn_name##_write_region_xxx` accordingly. Change-Id: I4e3c6a8a39ad04205cf0f3bda336c3970b15a28b
-
- 31 Mar, 2016 2 commits
-
-
Vikram Kanigiri authored
The ARM CoreLink DMC-500 Dynamic Memory Controller provides the programmable address region control of a TrustZone Address Space Controller. The access permissions can be defined for eight separate address regions plus a background or default region. This patch adds a DMC-500 driver to define address regions and program their access permissions as per ARM 100131_0000_02_en (r0p0) document. Change-Id: I9d33120f9480d742bcf7937e4b876f9d40c727e6
-
Vikram Kanigiri authored
TrustZone protection can be programmed by both memory and TrustZone address space controllers like DMC-500 and TZC-400. These peripherals share a similar programmer's view. Furthermore, it is possible to have multiple instances of each type of peripheral in a system resulting in multiple programmer's views. For example, on the TZC-400 each of the 4 filter units can be enabled or disabled for each region. There is a single set of registers to program the region attributes. On the DMC-500, each filter unit has its own programmer's view resulting in multiple sets of registers to program the region attributes. The layout of the registers is almost the same across all these variations. Hence the existing driver in `tzc400\tzc400.c` is refactored into the new driver in `tzc\tzc400.c`. The previous driver file is still maintained for compatibility and it is now deprecated. Change-Id: Ieabd0528e244582875bc7e65029a00517671216d
-