History log of /rk3399_ARM-atf/bl2/aarch32/bl2_el3_exceptions.S (Results 1 – 6 of 6)
Revision Date Author Comments
# 4f2c4ecf 05-Oct-2022 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "aarch32_debug_aborts" into integration

* changes:
feat(stm32mp1): add plat_report_*_abort functions
feat(debug): add helpers for aborts on AARCH32
feat(debug): add AA

Merge changes from topic "aarch32_debug_aborts" into integration

* changes:
feat(stm32mp1): add plat_report_*_abort functions
feat(debug): add helpers for aborts on AARCH32
feat(debug): add AARCH32 CP15 fault registers

show more ...


# 6dc5979a 15-Feb-2019 Yann Gautier <yann.gautier@st.com>

feat(debug): add helpers for aborts on AARCH32

New helper functions are created to handle data & prefetch aborts
in AARCH32. They call platform functions, just like what
report_exception is doing.
A

feat(debug): add helpers for aborts on AARCH32

New helper functions are created to handle data & prefetch aborts
in AARCH32. They call platform functions, just like what
report_exception is doing.
As extended MSR/MRS instructions (to access lr_abt in monitor mode)
are only available if CPU (Armv7) has virtualization extension,
the functions branch to original report_exception handlers if this is
not the case.
Those new helpers are created mainly to distinguish data and prefetch
aborts, as they both share the same mode.
This adds 40 bytes of code.

Change-Id: I5dd31930344ad4e3a658f8a9d366a87a300aeb67
Signed-off-by: Yann Gautier <yann.gautier@st.com>

show more ...


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


# 0d3a27e7 19-Jan-2018 davidcunado-arm <david.cunado@arm.com>

Merge pull request #1200 from robertovargas-arm/bl2-el3

Add BL2_AT_EL3 build option


# b1d27b48 30-Oct-2017 Roberto Vargas <roberto.vargas@arm.com>

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
stages without need for BL1. This is not currently possible because
BL2 executes at S-EL1 and cannot jump straight to EL3.

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

show more ...