utils.h is included in various header files for the defines in it.
Some of the other header files only contain defines. This allows the
header files to be shared between host and target builds for shared defines.
Recently types.h has been included in utils.h as well as some function
prototypes.
Because of the inclusion of types.h conflicts exist building host tools
abd these header files now. To solve this problem,
move the defines to utils_def.h and have this included by utils.h and
change header files to only include utils_def.h and not pick up the new
types.h being introduced.
FixesARM-software/tf-issues#461
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Remove utils_def.h from utils.h
This patch removes utils_def.h from utils.h as it is not required.
And also makes a minor change to ensure Juno platform compiles.
Change-Id: I10cf1fb51e44a8fa6dcec02980354eb9ecc9fa29
Some header files using the ULL() macro were not directly including
utils.h where the macro definition resides. As a consequence, a linker
script with values using this macro did not see the macro definition
and kept the "ULL(<value>)" call in the preprocessed file, which lead to
link error.
Files using ULL() macro now include utils.h directly.
Change-Id: I433a7f36bd21a156c20e69bc2a2bb406140ebdf9
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
With GCC 6.2 compiler, more C undefined behaviour is being flagged as
warnings, which result in build errors in ARM TF build.
The specific issue that this patch resolves is the use of (1 << 31),
which is predominantly used in case statements, where 1 is represented
as a signed int. When shifted to msb the behaviour is undefined.
The resolution is to specify 1 as an unsigned int using a convenience
macro ULL(). A duplicate macro MAKE_ULL() is replaced.
FixesARM-software/tf-issues#438
Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1
Signed-off-by: David Cunado <david.cunado@arm.com>
This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.
The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.
FixesARM-software/tf-issues#220
Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
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
Scott Branden
Douglas Raillard
David Cunado
Soby Mathew
Dan Handley