History log of /rk3399_ARM-atf/include/ (Results 3551 – 3575 of 3957)
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
4ca5753522-Mar-2016 Gerald Lejeune <gerald.lejeune@st.com>

Remove DAIF bits handling macros

These macros are unused and redundant with other CPU system registers
functions.

Moreover enable_serror() function implementation may not reach its purpose
because

Remove DAIF bits handling macros

These macros are unused and redundant with other CPU system registers
functions.

Moreover enable_serror() function implementation may not reach its purpose
because it does not handle the value of SCR_EL3.EA.

Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>

show more ...

adb4fcfb22-Mar-2016 Gerald Lejeune <gerald.lejeune@st.com>

Enable asynchronous abort exceptions during boot

Asynchronous abort exceptions generated by the platform during cold boot are
not taken in EL3 unless SCR_EL3.EA is set.

Therefore EA bit is set alon

Enable asynchronous abort exceptions during boot

Asynchronous abort exceptions generated by the platform during cold boot are
not taken in EL3 unless SCR_EL3.EA is set.

Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
initialisation. Further write accesses to SCR_EL3 preserve these bits during
cold boot.

A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
being trapped by EL3 after cold boot or not.

For further reference SError Interrupts are also known as asynchronous external
aborts.

On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
EL3 whatever the SCR_EL3.EA value is.

Fixes arm-software/tf-issues#368

Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>

show more ...

1319e7b121-Mar-2016 Soby Mathew <soby.mathew@arm.com>

Make cpu operations warning a VERBOSE print

The assembler helper function `print_revision_warning` is used when a
CPU specific operation is enabled in the debug build (e.g. an errata
workaround) but

Make cpu operations warning a VERBOSE print

The assembler helper function `print_revision_warning` is used when a
CPU specific operation is enabled in the debug build (e.g. an errata
workaround) but doesn't apply to the executing CPU's revision/part number.
However, in some cases the system integrator may want a single binary to
support multiple platforms with different IP versions, only some of which
contain a specific erratum. In this case, the warning can be emitted very
frequently when CPUs are being powered on/off.

This patch modifies this warning print behaviour so that it is emitted only
when LOG_LEVEL >= LOG_LEVEL_VERBOSE. The `debug.h` header file now contains
guard macros so that it can be included in assembly code.

Change-Id: Ic6e7a07f128dcdb8498a5bfdae920a8feeea1345

show more ...

1c3ea10301-Feb-2016 Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Remove all non-configurable dead loops

Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it ma

Remove all non-configurable dead loops

Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it may be called before the C environment
is initialized. A default implementation is provided, which simply
spins.

Corrected all dead loops in generic code to call this function
instead. This includes the dead loop that occurs at the end of the
call to panic().

All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
been removed.

Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134

show more ...

a34f3bf211-Mar-2016 danh-arm <dan.handley@arm.com>

Merge pull request #538 from sandrine-bailleux-arm/sb/extend-memory-types

Extend memory attributes to map non-cacheable memory

b6fc25e009-Mar-2016 danh-arm <dan.handley@arm.com>

Merge pull request #541 from antonio-nino-diaz-arm/an/secondary-cpu-init

Initialize secondary CPUs during cold boot

4e85e4fd23-Feb-2016 Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Initialize secondary CPUs during cold boot

The previous reset code in BL1 performed the following steps in
order:

1. Warm/Cold boot detection.
If it's a warm boot, jump to warm boot entrypoint.

Initialize secondary CPUs during cold boot

The previous reset code in BL1 performed the following steps in
order:

1. Warm/Cold boot detection.
If it's a warm boot, jump to warm boot entrypoint.

2. Primary/Secondary CPU detection.
If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(),
which doesn't return.

3. CPU initialisations (cache, TLB...).

4. Memory and C runtime initialization.

For a secondary CPU, steps 3 and 4 are never reached. This shouldn't
be a problem in most cases, since current implementations of
plat_secondary_cold_boot_setup() either panic or power down the
secondary CPUs.

The main concern is the lack of secondary CPU initialization when
bare metal EL3 payloads are used in case they don't take care of this
initialisation themselves.

This patch moves the detection of primary/secondary CPU after step 3
so that the CPU initialisations are performed per-CPU, while the
memory and the C runtime initialisation are only performed on the
primary CPU. The diagrams used in the ARM Trusted Firmware Reset
Design documentation file have been updated to reflect the new boot
flow.

Platforms ports might be affected by this patch depending on the
behaviour of plat_secondary_cold_boot_setup(), as the state of the
platform when entering this function will be different.

Fixes ARM-software/tf-issues#342

Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e

show more ...

5f65497501-Mar-2016 Sandrine Bailleux <sandrine.bailleux@arm.com>

Extend memory attributes to map non-cacheable memory

At the moment, the memory translation library allows to create memory
mappings of 2 types:

- Device nGnRE memory (named MT_DEVICE in the librar

Extend memory attributes to map non-cacheable memory

At the moment, the memory translation library allows to create memory
mappings of 2 types:

- Device nGnRE memory (named MT_DEVICE in the library);

- Normal, Inner Write-back non-transient, Outer Write-back
non-transient memory (named MT_MEMORY in the library).

As a consequence, the library code treats the memory type field as a
boolean: everything that is not device memory is normal memory and
vice-versa.

In reality, the ARMv8 architecture allows up to 8 types of memory to
be used at a single time for a given exception level. This patch
reworks the memory attributes such that the memory type is now defined
as an integer ranging from 0 to 7 instead of a boolean. This makes it
possible to extend the list of memory types supported by the memory
translation library.

The priority system dictating memory attributes for overlapping
memory regions has been extended to cope with these changes but the
algorithm at its core has been preserved. When a memory region is
re-mapped with different memory attributes, the memory translation
library examines the former attributes and updates them only if
the new attributes create a more restrictive mapping. This behaviour
is unchanged, only the manipulation of the value has been modified
to cope with the new format.

This patch also introduces a new type of memory mapping in the memory
translation library: MT_NON_CACHEABLE, meaning Normal, Inner
Non-cacheable, Outer Non-cacheable memory. This can be useful to map
a non-cacheable memory region, such as a DMA buffer for example.

The rules around the Execute-Never (XN) bit in a translation table
for an MT_NON_CACHEABLE memory mapping have been aligned on the rules
used for MT_MEMORY mappings:
- If the memory is read-only then it is also executable (XN = 0);
- If the memory is read-write then it is not executable (XN = 1).

The shareability field for MT_NON_CACHEABLE mappings is always set as
'Outer-Shareable'. Note that this is not strictly needed since
shareability is only relevant if the memory is a Normal Cacheable
memory type, but this is to align with the existing device memory
mappings setup. All Device and Normal Non-cacheable memory regions
are always treated as Outer Shareable, regardless of the translation
table shareability attributes.

This patch also removes the 'ATTR_SO' and 'ATTR_SO_INDEX' #defines.
They were introduced to map memory as Device nGnRnE (formerly called
"Strongly-Ordered" memory in the ARMv7 architecture) but were not
used anywhere in the code base. Removing them avoids any confusion
about the memory types supported by the library.

Upstream platforms do not currently use the MT_NON_CACHEABLE memory
type.

NOTE: THIS CHANGE IS SOURCE COMPATIBLE BUT PLATFORMS THAT RELY ON THE
BINARY VALUES OF `mmap_attr_t` or the `attr` argument of
`mmap_add_region()` MAY BE BROKEN.

Change-Id: I717d6ed79b4c845a04e34132432f98b93d661d79

show more ...

1a4fdb3626-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #533 from yatharth-arm/yk/genfw-1292

Fix the inconsistencies in bl1_tbbr_image_descs[]

843ddee401-Feb-2016 Yatharth Kochar <yatharth.kochar@arm.com>

Fix the inconsistencies in bl1_tbbr_image_descs[]

This patch fixes inconsistencies in bl1_tbbr_image_descs[]
and miscellaneous fixes in Firmware Update code.

Following are the changes:
* As part of

Fix the inconsistencies in bl1_tbbr_image_descs[]

This patch fixes inconsistencies in bl1_tbbr_image_descs[]
and miscellaneous fixes in Firmware Update code.

Following are the changes:
* As part of the original FWU changes, a `copied_size`
field was added to `image_info_t`. This was a subtle binary
compatibility break because it changed the size of the
`bl31_params_t` struct, which could cause problems if
somebody used different versions of BL2 or BL31, one with
the old `image_info_t` and one with the new version.
This patch put the `copied_size` within the `image_desc_t`.
* EXECUTABLE flag is now stored in `ep_info.h.attr` in place
of `image_info.h.attr`, associating it to an entrypoint.
* The `image_info.image_base` is only relevant for secure
images that are copied from non-secure memory into secure
memory. This patch removes initializing `image_base` for
non secure images in the bl1_tbbr_image_descs[].
* A new macro `SET_STATIC_PARAM_HEAD` is added for populating
bl1_tbbr_image_descs[].ep_info/image_info.h members statically.
The version, image_type and image attributes are now
populated using this new macro.
* Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct
usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c.
* Refactoring of code/macros related to SECURE and EXECUTABLE flags.

NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t`
OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr`
OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE
BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY.

Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d

show more ...

9931932b22-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #532 from soby-mathew/vk/configure_mmap_macros

Rationalise MMU and Page table related constants on ARM platforms

c64a044820-Jan-2016 Vikram Kanigiri <vikram.kanigiri@arm.com>

Rationalise MMU and Page table related constants on ARM platforms

`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage

Rationalise MMU and Page table related constants on ARM platforms

`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.

Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.

Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.

Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0

show more ...

094a935d22-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #518 from hzhuang1/pl061_gpio_v5

Pl061 gpio v5

f62d89ed19-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #531 from soby-mathew/sm/multicluster_fvp

Allow multi cluster topology definitions for ARM platforms

0108047a01-Feb-2016 Soby Mathew <soby.mathew@arm.com>

Allow multi cluster topology definitions for ARM platforms

The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible e

Allow multi cluster topology definitions for ARM platforms

The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible enough to scale to multi cluster platforms. This patch does
the following changes for more flexibility in defining topology:

1. The `plat_get_power_domain_tree_desc()` definition is moved from
`arm_topology.c` to platform specific files, that is `fvp_topology.c`
and `juno_topology.c`. Similarly the common definition of the porting
macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
specific `platform_def.h` header.

2. The ARM common layer porting macros which were dual cluster specific
are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
which must be defined by each ARM standard platform.

3. A new mandatory ARM common layer porting API
`plat_arm_get_cluster_core_count()` is introduced to enable the common
implementation of `arm_check_mpidr()` to validate MPIDR.

4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
introduced which allows the user to specify the cluster count to be
used to build the topology tree within Trusted Firmare. This enables
Trusted Firmware to be built for multi cluster FVP models.

Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b

show more ...

85df7e4418-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #523 from jcastillo-arm/jc/genfw-791

ARM platforms: rationalise memory attributes of shared memory

74eb26e413-Jan-2016 Juan Castillo <juan.castillo@arm.com>

ARM platforms: rationalise memory attributes of shared memory

The shared memory region on ARM platforms contains the mailboxes and,
on Juno, the payload area for communication with the SCP. This sha

ARM platforms: rationalise memory attributes of shared memory

The shared memory region on ARM platforms contains the mailboxes and,
on Juno, the payload area for communication with the SCP. This shared
memory may be configured as normal memory or device memory at build
time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
When set as normal memory, the platform port performs the corresponding
cache maintenance operations. From a functional point of view, this is
the equivalent of setting the shared memory as device memory, so there
is no need to maintain both options.

This patch removes the option to specify the shared memory as normal
memory on ARM platforms. Shared memory is always treated as device
memory. Cache maintenance operations are no longer needed and have
been replaced by data memory barriers to guarantee that payload and
MHU are accessed in the right order.

Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f

show more ...

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

e45264ab16-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #520 from vikramkanigiri/vk/scp_flexibility

Vk/scp flexibility

ea8d69af16-Feb-2016 danh-arm <dan.handley@arm.com>

Merge pull request #519 from vikramkanigiri/vk/misc_plat_reorg

Vk/misc plat reorg

7fb9a32d14-Jan-2016 Vikram Kanigiri <vikram.kanigiri@arm.com>

Make SCP_BL2(U) image loading configurable on CSS platforms

Current code mandates loading of SCP_BL2/SCP_BL2U images for all
CSS platforms. On future ARM CSS platforms, the Application
Processor (AP

Make SCP_BL2(U) image loading configurable on CSS platforms

Current code mandates loading of SCP_BL2/SCP_BL2U images for all
CSS platforms. On future ARM CSS platforms, the Application
Processor (AP) might not need to load these images. So, these
items can be removed from the FIP on those platforms.

BL2 tries to load SCP_BL2/SCP_BL2U images if their base
addresses are defined causing boot error if the images are not
found in FIP.

This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
to `1` does:
1. Adds SCP_BL2, SCP_BL2U images to FIP.
2. Defines the base addresses of these images so that AP loads
them.

And vice-versa if it is set to `0`. The default value is set to
`1`.

Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a

show more ...

8e083ecd08-Feb-2016 Vikram Kanigiri <vikram.kanigiri@arm.com>

Support for varying BOM/SCPI protocol base addresses in ARM platforms

Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
for BOM/SCPI protocol between AP<->SCP on all CSS platforms.

Support for varying BOM/SCPI protocol base addresses in ARM platforms

Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
cater for future ARM platforms this is made platform specific.
Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
platform specific.

Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8

show more ...

65cb1c4c12-Nov-2015 Vikram Kanigiri <vikram.kanigiri@arm.com>

Add API to return memory map on ARM platforms

Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
expect each platform to export its memory map in the `plat_arm_mmap`
data structure. Th

Add API to return memory map on ARM platforms

Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
expect each platform to export its memory map in the `plat_arm_mmap`
data structure. This approach does not scale well in case the memory
map cannot be determined until runtime. To cater for this possibility,
this patch introduces the plat_arm_get_mmap() API. It returns a
reference to the `plat_arm_mmap` by default but can be overridden
by a platform if required.

Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74

show more ...

0ab3f9a727-Jan-2016 Haojian Zhuang <haojian.zhuang@linaro.org>

arm: gpio: add pl061 driver

Add PL061 GPIO driver that is depend on gpio framework.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

1ffecc2427-Jan-2016 Haojian Zhuang <haojian.zhuang@linaro.org>

gpio: add gpio framework

Define the gpio ops in gpio driver.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

1...<<141142143144145146147148149150>>...159