| #
9a207532 |
| 04-Jan-2019 |
Antonio Niño Díaz <antonio.ninodiaz@arm.com> |
Merge pull request #1726 from antonio-nino-diaz-arm/an/includes
Sanitise includes across codebase
|
| #
09d40e0e |
| 14-Dec-2018 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Sanitise includes across codebase
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH} - inclu
Sanitise includes across codebase
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: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988b9 ("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>
show more ...
|
| #
9d068f66 |
| 08-Nov-2018 |
Antonio Niño Díaz <antonio.ninodiaz@arm.com> |
Merge pull request #1673 from antonio-nino-diaz-arm/an/headers
Standardise header guards across codebase
|
| #
c3cf06f1 |
| 08-Nov-2018 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Standardise header guards across codebase
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 proje
Standardise header guards across codebase
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>
show more ...
|
| #
dcf95e7e |
| 30-Aug-2018 |
Dimitris Papastamos <dimitris.papastamos@arm.com> |
Merge pull request #1542 from antonio-nino-diaz-arm/an/bl31-misra
Some MISRA fixes in BL31, cci and smmu
|
| #
819df3fc |
| 21-Aug-2018 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Fix MISRA defects in some common headers
Change-Id: I8fbb4c785e7e07c7241e0c399a9b65161985c9df Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
|
| #
a937d93e |
| 14-Aug-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #1046 from jeenu-arm/revc
Support for RevC FVP model
|
| #
955242d8 |
| 18-Jul-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
FVP: Support Base FVP RevC
Revision C of the Base FVP has the same memory map as earlier revisions, but has the following differences:
- Implements CCI550 instead of CCI400, - Has a single inst
FVP: Support Base FVP RevC
Revision C of the Base FVP has the same memory map as earlier revisions, but has the following differences:
- Implements CCI550 instead of CCI400, - Has a single instantiation of SMMUv3, - CPU MPIDs are shifted left by one level, and has MT bit set in them.
The correct interconnect to program is chosen at run time based on the FVP revision. Therefore, this patch implements FVP functions for interconnect programming, rather than depending on ARM generic ones. The macros used have been renamed to reflect this change.
Additionally, this patch initializes SMMUv3 as part of FVP early platform setup.
New ARM config flags are introduced for feature queries at run time.
Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| #
f132b4a0 |
| 04-May-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #925 from dp-arm/dp/spdx
Use SPDX license identifiers
|
| #
82cb2c1a |
| 03-May-2017 |
dp-arm <dimitris.papastamos@arm.com> |
Use SPDX license identifiers
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
Use SPDX license identifiers
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>
show more ...
|
| #
49b6d349 |
| 17-Feb-2016 |
danh-arm <dan.handley@arm.com> |
Merge pull request #522 from danh-arm/vk/rework-interconnect-drivers
Rework use of interconnect drivers
|
| #
6355f234 |
| 15-Feb-2016 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Rework use of interconnect drivers
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals.
Rework use of interconnect drivers
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals.
This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below:
1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver.
2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S.
3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
show more ...
|
| #
4ca473db |
| 09-Dec-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #456 from soby-mathew/sm/gicv3-tsp-plat-changes-v2
Modify TSP and ARM standard platforms for new GIC drivers v2
|
| #
27573c59 |
| 03-Nov-2015 |
Achin Gupta <achin.gupta@arm.com> |
Rework use of ARM GIC drivers on ARM platforms
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both
Rework use of ARM GIC drivers on ARM platforms
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases:
1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400
2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems.
ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below:
1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver.
2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build.
3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts.
The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems.
This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed.
Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
show more ...
|
| #
01f1ebbb |
| 18-Aug-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #362 from jcastillo-arm/jc/inline
Fix build error with optimizations disabled (-O0)
|
| #
80bb6afd |
| 04-Aug-2015 |
Juan Castillo <juan.castillo@arm.com> |
Fix build error with optimizations disabled (-O0)
If Trusted Firmware is built with optimizations disabled (-O0), the linker throws the following error:
undefined reference to 'xxx'
Where 'xxx
Fix build error with optimizations disabled (-O0)
If Trusted Firmware is built with optimizations disabled (-O0), the linker throws the following error:
undefined reference to 'xxx'
Where 'xxx' is a raw inline function defined in a header file. The reason is that, with optimizations disabled, GCC may decide to skip the inlining. If that is the case, an external definition to the compilation unit must be provided. Because no external definition is present, the linker throws the error.
This patch fixes the problem by declaring the following inline functions static, so the internal definition is used:
inline void soc_css_security_setup(void) inline const arm_config_t *get_arm_config(void)
Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f
show more ...
|
| #
1f06ca8a |
| 17-Jul-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #332 from jcastillo-arm/jc/tf-issues/214
Use uintptr_t as base address type in ARM driver APIs
|
| #
02462972 |
| 09-Sep-2014 |
Juan Castillo <juan.castillo@arm.com> |
Use uintptr_t as base address type in ARM driver APIs
This patch changes the type of the base address parameter in the ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The uintptr_t ty
Use uintptr_t as base address type in ARM driver APIs
This patch changes the type of the base address parameter in the ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The uintptr_t type allows coverage of the whole memory space and to perform arithmetic operations on the addresses. ARM platform code has also been updated to use uintptr_t as GIC base address in the configuration.
Fixes ARM-software/tf-issues#214
Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1
show more ...
|
| #
4731e8f0 |
| 29-Apr-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #295 from danh-arm/dh/plat-port-reorg
ARM platform port reorganization
|
| #
b4315306 |
| 19-Mar-2015 |
Dan Handley <dan.handley@arm.com> |
Add common ARM and CSS platform code
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories:
* (include/)plat/common. Common platf
Add common ARM and CSS platform code
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories:
* (include/)plat/common. Common platform porting functionality that typically may be used by all platforms.
* (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms.
* (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level.
* (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform.
* (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level.
No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm.
Also remove any unnecessary variation between the ARM development platform ports, including:
* Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory.
* Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case.
* Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space.
These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches.
Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
show more ...
|