Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refacto

Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refactor(gic): promote most of the GIC driver to common code
refactor: make arm_gicv2.c and arm_gicv3.c common
refactor(fvp): use more arm generic code for gicv3

show more ...

refactor: convert arm platforms to use the generic GIC driver

This reduces the code the platforms have to carry and makes their build
rules a bit simpler.

The main benefit is that plat_my_core_pos(

refactor: convert arm platforms to use the generic GIC driver

This reduces the code the platforms have to carry and makes their build
rules a bit simpler.

The main benefit is that plat_my_core_pos() no longer needs to be called
within the driver, helping with performance a bit.

Change-Id: I0b0d1d36d20d67c41c8c9dc14ade11bda6d4a6af
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3" into integration

refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3

BL2_AT_EL3 is an overloaded macro which has two uses:
1. When BL2 is entry point into TF-A(no BL1)
2. When BL2 is runnin

refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3

BL2_AT_EL3 is an overloaded macro which has two uses:
1. When BL2 is entry point into TF-A(no BL1)
2. When BL2 is running at EL3 exception level
These two scenarios are not exactly same even though first implicitly
means second to be true. To distinguish between these two use cases we
introduce new macros.
BL2_AT_EL3 is renamed to RESET_TO_BL2 to better convey both 1. and 2.
Additional macro BL2_RUNS_AT_EL3 is added to cover all scenarious where
BL2 runs at EL3 (including four world systems).

BREAKING CHANGE: BL2_AT_EL3 renamed to RESET_TO_BL2 across the
repository.

Change-Id: I477e1d0f843b44b799c216670e028fcb3509fb72
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Signed-off-by: Maksims Svecovs <maksims.svecovs@arm.com>

show more ...

Merge changes from topic "refactor-hw-config-load" into integration

* changes:
docs(fvp): update loading addresses of HW_CONFIG
docs(fconf): update device tree binding for FCONF
feat(fvp): upd

Merge changes from topic "refactor-hw-config-load" into integration

* changes:
docs(fvp): update loading addresses of HW_CONFIG
docs(fconf): update device tree binding for FCONF
feat(fvp): update HW_CONFIG DT loading mechanism
refactor(st): update set_config_info function call
refactor(fvp_r): update set_config_info function call
refactor(arm): update set_config_info function call
feat(fconf): add NS load address in configuration DTB nodes

show more ...

feat(fvp): update HW_CONFIG DT loading mechanism

Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue sinc

feat(fvp): update HW_CONFIG DT loading mechanism

Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue since no software runs in non-secure world at this time
(non-secure world has not been started yet).

It does not provide a guarantee though since malicious external
NS-agents can take control of this memory region for update/corruption
after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat
is mapped to Threat ID#3 (Bypass authentication scenario) in threat
model [1].

Hence modified the code as below -
1. BL2 loads the HW_CONFIG into secure memory
2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an
address provided by the newly added property(ns-load-address) in
the 'hw-config' node of the FW_CONFIG
3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that
it can retrieve details (address and size) of HW_CONFIG from
FW_CONFIG
4. A secure and non-secure HW_CONFIG address will eventually be used
by BL31/SP_MIN/BL32 and BL33 components respectively
5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads
information from it to local variables (structures) and then
unmaps it
6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears
sufficient, and it will also create a free space for any future
components to be added to memory

[1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html

Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Merge changes from topic "ck/mpmm" into integration

* changes:
docs(maintainers): add Chris Kay to AMU and MPMM
feat(tc): enable MPMM
feat(mpmm): add support for MPMM
feat(amu): enable per-c

Merge changes from topic "ck/mpmm" into integration

* changes:
docs(maintainers): add Chris Kay to AMU and MPMM
feat(tc): enable MPMM
feat(mpmm): add support for MPMM
feat(amu): enable per-core AMU auxiliary counters
docs(amu): add AMU documentation
refactor(amu): refactor enablement and context switching
refactor(amu): detect auxiliary counters at runtime
refactor(amu): detect architected counters at runtime
refactor(amu): conditionally compile auxiliary counter support
refactor(amu): factor out register accesses
refactor(amu)!: privatize unused AMU APIs
refactor(amu)!: remove `PLAT_AMU_GROUP1_COUNTERS_MASK`
build(amu): introduce `amu.mk`
build(fconf)!: clean up source collection
feat(fdt-wrappers): add CPU enumeration utility function
build(fdt-wrappers): introduce FDT wrappers makefile
build(bl2): deduplicate sources
build(bl1): deduplicate sources

show more ...

build(fdt-wrappers): introduce FDT wrappers makefile

This has been introduced to simplify dependencies on the FDT wrappers.
We generally want to avoid pulling in components on a file-by-file
basis,

build(fdt-wrappers): introduce FDT wrappers makefile

This has been introduced to simplify dependencies on the FDT wrappers.
We generally want to avoid pulling in components on a file-by-file
basis, particularly as we are trying to draw conceptual boxes around
components in preparation for transitioning the build system to CMake,
where dependencies are modelled on libraries rather than files.

Signed-off-by: Chris Kay <chris.kay@arm.com>
Change-Id: Idb7ee05a9b54a8caa3e07f36e608867e20b6dcd5

show more ...

Merge "plat/fvp: Add support for dynamic description of secure interrupts" into integration

plat/fvp: Add support for dynamic description of secure interrupts

Using the fconf framework, the Group 0 and Group 1 secure interrupt
descriptors are moved to device tree and retrieved in runtime.

plat/fvp: Add support for dynamic description of secure interrupts

Using the fconf framework, the Group 0 and Group 1 secure interrupt
descriptors are moved to device tree and retrieved in runtime. This
feature is enabled by the build flag SEC_INT_DESC_IN_FCONF.

Change-Id: I360c63a83286c7ecc2426cd1ff1b4746d61e633c
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...

Merge "plat/arm/fvp: populate runtime console parameters dynamically" into integration

plat/arm/fvp: populate runtime console parameters dynamically

We query the UART base address and clk frequency in runtime
using fconf getter APIs.

Change-Id: I5f4e84953be5f384472bf90720b706d45cb862

plat/arm/fvp: populate runtime console parameters dynamically

We query the UART base address and clk frequency in runtime
using fconf getter APIs.

Change-Id: I5f4e84953be5f384472bf90720b706d45cb86260
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...

Merge "FVP: In BL31/SP_MIN, map only the needed DRAM region statically" into integration

FVP: In BL31/SP_MIN, map only the needed DRAM region statically

Rather than creating entry in plat_arm_mmap array to map the
entire DRAM region in BL31/SP_MIN, only map a smaller region holding
HW_C

FVP: In BL31/SP_MIN, map only the needed DRAM region statically

Rather than creating entry in plat_arm_mmap array to map the
entire DRAM region in BL31/SP_MIN, only map a smaller region holding
HW_CONFIG DTB. Consequently, an increase in number of sub-translation
tables(level-2 and level-3) i.e., MAX_XLAT_TABLES is necessary to map
the new region in memory.

In order to accommodate the increased code size in BL31 i.e.,
PROGBITS, the max size of BL31 image is increased by 0x1000(4K).

Change-Id: I540b8ee550588e22a3a9fb218183d2ab8061c851
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...

Merge changes from topic "mp/enhanced_pal_hw" into integration

* changes:
plat/arm/fvp: populate pwr domain descriptor dynamically
fconf: Extract topology node properties from HW_CONFIG dtb
fc

Merge changes from topic "mp/enhanced_pal_hw" into integration

* changes:
plat/arm/fvp: populate pwr domain descriptor dynamically
fconf: Extract topology node properties from HW_CONFIG dtb
fconf: necessary modifications to support fconf in BL31 & SP_MIN
fconf: enhancements to firmware configuration framework

show more ...

fconf: necessary modifications to support fconf in BL31 & SP_MIN

Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN.
Created few populator() functions which parse HW_CONFIG

fconf: necessary modifications to support fconf in BL31 & SP_MIN

Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN.
Created few populator() functions which parse HW_CONFIG device tree
and registered them with fconf framework. Many of the changes are
only applicable for fvp platform.

This patch:
1. Adds necessary symbols and sections in BL31, SP_MIN linker script
2. Adds necessary memory map entry for translation in BL31, SP_MIN
3. Creates an abstraction layer for hardware configuration based on
fconf framework
4. Adds necessary changes to build flow (makefiles)
5. Minimal callback to read hw_config dtb for capturing properties
related to GIC(interrupt-controller node)
6. updates the fconf documentation

Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...

Merge pull request #1784 from antonio-nino-diaz-arm/an/includes-arm

plat/arm: Cleanup of includes and drivers

fvp: pwrc: Move to drivers/ folder

Change-Id: I670ea80e0331c2d4b2ccfa563a45469a43f6902d
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Merge pull request #1619 from antonio-nino-diaz-arm/an/norflash

plat/arm: Move norflash driver to drivers/ folder

plat/arm: Move norflash driver to drivers/ folder

This way it can be reused by other platforms if needed.

Note that this driver is designed to work with the Versatile Express NOR
flash of Juno and

plat/arm: Move norflash driver to drivers/ folder

This way it can be reused by other platforms if needed.

Note that this driver is designed to work with the Versatile Express NOR
flash of Juno and FVP. In said platforms, the memory is organized as an
interleaved memory of two chips with a 16 bit word.

Any platform that wishes to reuse it with a different configuration will
need to modify the driver so that it is more generic.

Change-Id: Ic721758425864e0cf42b7b9b04bf0d9513b6022e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Merge pull request #1109 from robertovargas-arm/mem_protect

Mem protect

mem_protect: Add mem_protect support in Juno and FVP for DRAM1

mem_protect needs some kind of non-volatile memory because it has
to remember its state across reset and power down events.
The most su

mem_protect: Add mem_protect support in Juno and FVP for DRAM1

mem_protect needs some kind of non-volatile memory because it has
to remember its state across reset and power down events.
The most suitable electronic part for this feature is a NVRAM
which should be only accesible from the secure world. Juno and
FVP lack such hardware and for this reason the MEM_PROTECT
functionality is implemented with Flash EEPROM memory on both
boards, even though this memory is accesible from the non-secure
world. This is done only to show a full implementation of
these PSCI features, but an actual system shouldn't use a
non-secure NVRAM to implement it.

The EL3 runtime software will write the mem_protect flag and BL2
will read and clear the memory ranges if enabled. It is done in
BL2 because it reduces the time that TF needs access to the full
non-secure memory.

The memory layout of both boards is defined using macros which
take different values in Juno and FVP platforms. Generic platform
helpers are added that use the platform specific macros to generate
a mem_region_t that is valid for the platform.

Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

show more ...

Merge pull request #925 from dp-arm/dp/spdx

Use SPDX license identifiers

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 ...

Merge pull request #678 from soby-mathew/sm/PSCI_AArch32

Introduce AArch32 support for PSCI library