Merge changes from topic "fix-for-hash-lengths" into integration
* changes:
fix(auth): allow hashes of different lengths
feat(juno): add mbedtls_asn1_get_len symbol in ROMlib
feat(fvp): add mbedtls_asn1_get_len symbol in ROMlib
diff --git a/docs/design/cpu-specific-build-macros.rst b/docs/design/cpu-specific-build-macros.rst
index 758d62b..ecbefdd 100644
--- a/docs/design/cpu-specific-build-macros.rst
+++ b/docs/design/cpu-specific-build-macros.rst
@@ -53,7 +53,7 @@
errata workaround is ``ERRATA_<Processor name>_<ID>``, where the ``Processor name``
is for example ``A57`` for the ``Cortex_A57`` CPU.
-Refer to :ref:`firmware_design_cpu_errata_reporting` for information on how to
+Refer to :ref:`firmware_design_cpu_errata_implementation` for information on how to
write errata workaround functions.
All workarounds are disabled by default. The platform is responsible for
diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst
index 50839bd..131cca1 100644
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@@ -9,12 +9,12 @@
to the stage where it hands-off control to firmware running in the normal
world in DRAM. This is the cold boot path.
-TF-A also implements the `Power State Coordination Interface PDD`_ as a
-runtime service. PSCI is the interface from normal world software to firmware
-implementing power management use-cases (for example, secondary CPU boot,
-hotplug and idle). Normal world software can access TF-A runtime services via
-the Arm SMC (Secure Monitor Call) instruction. The SMC instruction must be
-used as mandated by the SMC Calling Convention (`SMCCC`_).
+TF-A also implements the `PSCI`_ as a runtime service. PSCI is the interface
+from normal world software to firmware implementing power management use-cases
+(for example, secondary CPU boot, hotplug and idle). Normal world software can
+access TF-A runtime services via the Arm SMC (Secure Monitor Call) instruction.
+The SMC instruction must be used as mandated by the SMC Calling Convention
+(`SMCCC`_).
TF-A implements a framework for configuring and managing interrupts generated
in either security state. The details of the interrupt management framework
@@ -400,8 +400,7 @@
memory with the entrypoint and Saved Program Status Register (``SPSR``) of the
normal world software image. The entrypoint is the load address of the BL33
image. The ``SPSR`` is determined as specified in Section 5.13 of the
-`Power State Coordination Interface PDD`_. This information is passed to the
-EL3 Runtime Software.
+`PSCI`_. This information is passed to the EL3 Runtime Software.
AArch64 BL31 (EL3 Runtime Software) execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -952,8 +951,8 @@
The PSCI v1.1 specification categorizes APIs as optional and mandatory. All the
mandatory APIs in PSCI v1.1, PSCI v1.0 and in PSCI v0.2 draft specification
-`Power State Coordination Interface PDD`_ are implemented. The table lists
-the PSCI v1.1 APIs and their support in generic code.
+`PSCI`_ are implemented. The table lists the PSCI v1.1 APIs and their support
+in generic code.
An API implementation might have a dependency on platform code e.g. CPU_SUSPEND
requires the platform to export a part of the implementation. Hence the level
@@ -1245,8 +1244,9 @@
handling functions.
Details for implementing a CPU specific reset handler can be found in
-Section 8. Details for implementing a platform specific reset handler can be
-found in the :ref:`Porting Guide` (see the ``plat_reset_handler()`` function).
+:ref:`firmware_design_cpu_specific_reset_handling`. Details for implementing a
+platform specific reset handler can be found in the :ref:`Porting Guide` (see
+the``plat_reset_handler()`` function).
When adding functionality to a reset handler, keep in mind that if a different
reset handling behavior is required between the first and the subsequent
@@ -1340,12 +1340,38 @@
the platform makefile. The generic CPU specific operations framework code exists
in ``lib/cpus/aarch64/cpu_helpers.S``.
+CPU PCS
+~~~~~~~
+
+All assembly functions in CPU files are asked to follow a modified version of
+the Procedure Call Standard (PCS) in their internals. This is done to ensure
+calling these functions from outside the file doesn't unexpectedly corrupt
+registers in the very early environment and to help the internals to be easier
+to understand. Please see the :ref:`firmware_design_cpu_errata_implementation`
+for any function specific restrictions.
+
++--------------+---------------------------------+
+| register | use |
++==============+=================================+
+| x0 - x15 | scratch |
++--------------+---------------------------------+
+| x16, x17 | do not use (used by the linker) |
++--------------+---------------------------------+
+| x18 | do not use (platform register) |
++--------------+---------------------------------+
+| x19 - x28 | callee saved |
++--------------+---------------------------------+
+| x29, x30 | FP, LR |
++--------------+---------------------------------+
+
+.. _firmware_design_cpu_specific_reset_handling:
+
CPU specific Reset Handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~
After a reset, the state of the CPU when it calls generic reset handler is:
-MMU turned off, both instruction and data caches turned off and not part
-of any coherency domain.
+MMU turned off, both instruction and data caches turned off, not part
+of any coherency domain and no stack.
The BL entrypoint code first invokes the ``plat_reset_handler()`` to allow
the platform to perform any system initialization required and any system
@@ -1355,10 +1381,9 @@
in midr are used to find the matching ``cpu_ops`` entry. The ``reset_func()`` in
the returned ``cpu_ops`` is then invoked which executes the required reset
handling for that CPU and also any errata workarounds enabled by the platform.
-This function must preserve the values of general purpose registers x20 to x29.
-Refer to Section "Guidelines for Reset Handlers" for general guidelines
-regarding placement of code in a reset handler.
+It should be defined using the ``cpu_reset_func_{start,end}`` macros and its
+body may only clobber x0 to x14 with x14 being the cpu_rev parameter.
CPU specific power down sequence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1391,10 +1416,10 @@
be reported and a pointer to the ASCII list of register names in a format
expected by the crash reporting framework.
-.. _firmware_design_cpu_errata_reporting:
+.. _firmware_design_cpu_errata_implementation:
-CPU errata status reporting
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+CPU errata implementation
+~~~~~~~~~~~~~~~~~~~~~~~~~
Errata workarounds for CPUs supported in TF-A are applied during both cold and
warm boots, shortly after reset. Individual Errata workarounds are enabled as
@@ -1402,59 +1427,92 @@
therefore some are enabled by default, others not. Platform ports shall
override build options to enable or disable errata as appropriate. The CPU
drivers take care of applying errata workarounds that are enabled and applicable
-to a given CPU. Refer to :ref:`arm_cpu_macros_errata_workarounds` for more
-information.
+to a given CPU.
-Functions in CPU drivers that apply errata workaround must follow the
-conventions listed below.
+Each erratum has a build flag in ``lib/cpus/cpu-ops.mk`` of the form:
+``ERRATA_<cpu_num>_<erratum_id>``. It also has a short description in
+:ref:`arm_cpu_macros_errata_workarounds` on when it should apply.
-The errata workaround must be authored as two separate functions:
+Errata framework
+^^^^^^^^^^^^^^^^
-- One that checks for errata. This function must determine whether that errata
- applies to the current CPU. Typically this involves matching the current
- CPUs revision and variant against a value that's known to be affected by the
- errata. If the function determines that the errata applies to this CPU, it
- must return ``ERRATA_APPLIES``; otherwise, it must return
- ``ERRATA_NOT_APPLIES``. The utility functions ``cpu_get_rev_var`` and
- ``cpu_rev_var_ls`` functions may come in handy for this purpose.
+The errata framework is a convention and a small library to allow errata to be
+automatically discovered. It enables compliant errata to be automatically
+applied and reported at runtime (either by status reporting or the errata ABI).
-For an errata identified as ``E``, the check function must be named
-``check_errata_E``.
+To write a compliant mitigation for erratum number ``erratum_id`` on a cpu that
+declared itself (with ``declare_cpu_ops``) as ``cpu_name`` one needs 3 things:
-This function will be invoked at different times, both from assembly and from
-C run time. Therefore it must follow AAPCS, and must not use stack.
+#. A CPU revision checker function: ``check_erratum_<cpu_name>_<erratum_id>``
-- Another one that applies the errata workaround. This function would call the
- check function described above, and applies errata workaround if required.
+ It should check whether this erratum applies on this revision of this CPU.
+ It will be called with the CPU revision as its first parameter (x0) and
+ should return one of ``ERRATA_APPLIES`` or ``ERRATA_NOT_APPLIES``.
-CPU drivers that apply errata workaround can optionally implement an assembly
-function that report the status of errata workarounds pertaining to that CPU.
-For a driver that registers the CPU, for example, ``cpux`` via ``declare_cpu_ops``
-macro, the errata reporting function, if it exists, must be named
-``cpux_errata_report``. This function will always be called with MMU enabled; it
-must follow AAPCS and may use stack.
+ It may only clobber x0 to x4. The rest should be treated as callee-saved.
+
+#. A workaround function: ``erratum_<cpu_name>_<erratum_id>_wa``
+
+ It should obtain the cpu revision (with ``cpu_get_rev_var``), call its
+ revision checker, and perform the mitigation, should the erratum apply.
+
+ It may only clobber x0 to x8. The rest should be treated as callee-saved.
+
+#. Register itself to the framework
+
+ Do this with
+ ``add_erratum_entry <cpu_name>, ERRATUM(<erratum_id>), <errata_flag>``
+ where the ``errata_flag`` is the enable flag in ``cpu-ops.mk`` described
+ above.
+
+See the next section on how to do this easily.
+
+.. note::
+
+ CVEs have the format ``CVE_<year>_<number>``. To fit them in the framework, the
+ ``erratum_id`` for the checker and the workaround functions become the
+ ``number`` part of its name and the ``ERRATUM(<number>)`` part of the
+ registration should instead be ``CVE(<year>, <number>)``. In the extremely
+ unlikely scenario where a CVE and an erratum numbers clash, the CVE number
+ should be prefixed with a zero.
+
+ Also, their build flag should be ``WORKAROUND_CVE_<year>_<number>``.
+
+.. note::
+
+ AArch32 uses the legacy convention. The checker function has the format
+ ``check_errata_<erratum_id>`` and the workaround has the format
+ ``errata_<cpu_number>_<erratum_id>_wa`` where ``cpu_number`` is the shortform
+ letter and number name of the CPU.
+
+ For CVEs the ``erratum_id`` also becomes ``cve_<year>_<number>``.
+
+Errata framework helpers
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Writing these errata involves lots of boilerplate and repetitive code. On
+AArch64 there are helpers to omit most of this. They are located in
+``include/lib/cpus/aarch64/cpu_macros.S`` and the preferred way to implement
+errata. Please see their comments on how to use them.
+
+The most common type of erratum workaround, one that just sets a "chicken" bit
+in some arbitrary register, would have an implementation for the Cortex-A77,
+erratum #1925769 like::
+
+ workaround_reset_start cortex_a77, ERRATUM(1925769), ERRATA_A77_1925769
+ sysreg_bit_set CORTEX_A77_CPUECTLR_EL1, CORTEX_A77_CPUECTLR_EL1_BIT_8
+ workaround_reset_end cortex_a77, ERRATUM(1925769)
+
+ check_erratum_ls cortex_a77, ERRATUM(1925769), CPU_REV(1, 1)
+
+Status reporting
+^^^^^^^^^^^^^^^^
In a debug build of TF-A, on a CPU that comes out of reset, both BL1 and the
-runtime firmware (BL31 in AArch64, and BL32 in AArch32) will invoke errata
-status reporting function, if one exists, for that type of CPU.
-
-To report the status of each errata workaround, the function shall use the
-assembler macro ``report_errata``, passing it:
-
-- The build option that enables the errata;
-
-- The name of the CPU: this must be the same identifier that CPU driver
- registered itself with, using ``declare_cpu_ops``;
-
-- And the errata identifier: the identifier must match what's used in the
- errata's check function described above.
-
-The errata status reporting function will be called once per CPU type/errata
-combination during the software's active life time.
-
-It's expected that whenever an errata workaround is submitted to TF-A, the
-errata reporting function is appropriately extended to report its status as
-well.
+runtime firmware (BL31 in AArch64, and BL32 in AArch32) will invoke a generic
+errata status reporting function. It will read the ``errata_entries`` list of
+that cpu and will report whether each known erratum was applied and, if not,
+whether it should have been.
Reporting the status of errata workaround is for informational purpose only; it
has no functional significance.
@@ -2731,7 +2789,7 @@
- `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D)`_
-- `Power State Coordination Interface PDD`_
+- `PSCI`_
- `SMC Calling Convention`_
@@ -2741,10 +2799,8 @@
*Copyright (c) 2013-2023, Arm Limited and Contributors. All rights reserved.*
-.. _Power State Coordination Interface PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
.. _SMCCC: https://developer.arm.com/docs/den0028/latest
-.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
-.. _Power State Coordination Interface PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
+.. _PSCI: https://developer.arm.com/documentation/den0022/latest/
.. _Arm ARM: https://developer.arm.com/docs/ddi0487/latest
.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest
.. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst
index 4eafb39..c8ff7d5 100644
--- a/docs/getting_started/build-options.rst
+++ b/docs/getting_started/build-options.rst
@@ -531,7 +531,8 @@
through feature specific build flags are supported by the PE or not by
validating them either at boot phase or at runtime based on the value
possessed by the feature flag (0 to 2) and report error messages at an early
- stage.
+ stage. This flag will also enable errata ordering checking for ``DEBUG``
+ builds.
This prevents and benefits us from EL3 runtime exceptions during context save
and restore routines guarded by these build flags. Henceforth validating them
diff --git a/docs/getting_started/psci-lib-integration-guide.rst b/docs/getting_started/psci-lib-integration-guide.rst
index 4d690a9..7e4b0db 100644
--- a/docs/getting_started/psci-lib-integration-guide.rst
+++ b/docs/getting_started/psci-lib-integration-guide.rst
@@ -3,7 +3,7 @@
This document describes the PSCI library interface with a focus on how to
integrate with a suitable Trusted OS for an Armv8-A AArch32 system. The PSCI
-Library implements the PSCI Standard as described in `PSCI spec`_ and is meant
+Library implements the PSCI Standard as described in `PSCI`_ and is meant
to be integrated with EL3 Runtime Software which invokes the PSCI Library
interface appropriately. **EL3 Runtime Software** refers to software executing
at the highest secure privileged mode, which is EL3 in AArch64 or Secure SVC/
@@ -74,7 +74,7 @@
---------------------------
PSCI library is in charge of initializing/restoring the non-secure CPU system
-registers according to `PSCI specification`_ during cold/warm boot.
+registers according to `PSCI`_ during cold/warm boot.
This is referred to as ``PSCI CPU Context Management``. Registers that need to
be preserved across CPU power down/power up cycles are maintained in
``cpu_context_t`` data structure. The initialization of other non-secure CPU
@@ -120,8 +120,8 @@
PSCI Library Interface
----------------------
-The PSCI library implements the `PSCI Specification`_. The interfaces
-to this library are declared in ``psci_lib.h`` and are as listed below:
+The PSCI library implements the `PSCI`_. The interfaces to this library are
+declared in ``psci_lib.h`` and are as listed below:
.. code:: c
@@ -254,7 +254,7 @@
argument) determines the PSCI API to be called. The ``x1`` to ``x4`` (2nd to 5th
arguments), are the values of the registers r1 - r4 (in AArch32) or x1 - x4
(in AArch64) when the SMC is received. These are the arguments to PSCI API as
-described in `PSCI spec`_. The 'flags' (8th argument) is a bit field parameter
+described in `PSCI`_. The 'flags' (8th argument) is a bit field parameter
and is detailed in 'smccc.h' header. It includes whether the call is from the
secure or non-secure world. The ``cookie`` (6th argument) and the ``handle``
(7th argument) are not used and are reserved for future use.
@@ -273,7 +273,7 @@
Return : void
This function performs the warm boot initialization/restoration as mandated by
-`PSCI spec`_. For AArch32, on wakeup from power down the CPU resets to secure SVC
+`PSCI`_. For AArch32, on wakeup from power down the CPU resets to secure SVC
mode and the EL3 Runtime Software must perform the prerequisite initializations
mentioned at top of this section. This function must be called with Data cache
disabled (unless build option ``HW_ASSISTED_COHERENCY`` is enabled) but with MMU
@@ -496,7 +496,7 @@
This callback is called in response to PSCI_MIGRATE_INFO_TYPE or
PSCI_MIGRATE_INFO_UP_CPU APIs. The return value of this callback must
correspond to the return value of PSCI_MIGRATE_INFO_TYPE API as described
- in `PSCI spec`_. If the secure payload is a Uniprocessor (UP)
+ in `PSCI`_. If the secure payload is a Uniprocessor (UP)
implementation, then it must update the mpidr of the CPU it is resident in
via ``resident_cpu`` (first argument). The updates to ``resident_cpu`` is
ignored if the secure payload is a multiprocessor (MP) implementation.
@@ -528,9 +528,7 @@
--------------
-*Copyright (c) 2016-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2016-2023, Arm Limited and Contributors. All rights reserved.*
-.. _PSCI spec: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
+.. _PSCI: https://developer.arm.com/documentation/den0022/latest/
.. _SMCCC: https://developer.arm.com/docs/den0028/latest
-.. _PSCI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
-.. _PSCI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
diff --git a/docs/getting_started/rt-svc-writers-guide.rst b/docs/getting_started/rt-svc-writers-guide.rst
index 5a4be4d..fe64558 100644
--- a/docs/getting_started/rt-svc-writers-guide.rst
+++ b/docs/getting_started/rt-svc-writers-guide.rst
@@ -314,7 +314,7 @@
--------------
-*Copyright (c) 2014-2021, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2023, Arm Limited and Contributors. All rights reserved.*
.. _SMCCC: https://developer.arm.com/docs/den0028/latest
-.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
+.. _PSCI: https://developer.arm.com/documentation/den0022/latest/
diff --git a/docs/index.rst b/docs/index.rst
index bce9bb7..a7a5993 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -90,7 +90,7 @@
.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile
.. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
-.. _Power State Coordination Interface (PSCI): http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
+.. _Power State Coordination Interface (PSCI): https://developer.arm.com/documentation/den0022/latest/
.. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
.. _System Control and Management Interface (SCMI): http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
.. _Software Delegated Exception Interface (SDEI): http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
diff --git a/docs/plat/arm/juno/index.rst b/docs/plat/arm/juno/index.rst
index ea7d11c..5320a3b 100644
--- a/docs/plat/arm/juno/index.rst
+++ b/docs/plat/arm/juno/index.rst
@@ -249,4 +249,4 @@
.. _build the binaries from source: https://github.com/ARM-software/SCP-firmware/blob/master/user_guide.md#scp-firmware-user-guide
.. _Arm Platforms Portal: https://community.arm.com/dev-platforms/
.. _Juno Getting Started Guide: https://developer.arm.com/documentation/den0928/f/?lang=en
-.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
+.. _PSCI: https://developer.arm.com/documentation/den0022/latest/
diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst
index 8182f91..b557a16 100644
--- a/docs/porting-guide.rst
+++ b/docs/porting-guide.rst
@@ -3668,7 +3668,7 @@
*Copyright (c) 2013-2023, Arm Limited and Contributors. All rights reserved.*
-.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
+.. _PSCI: https://developer.arm.com/documentation/den0022/latest/
.. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html
.. _3.0 (GICv3): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0069b/index.html
.. _FreeBSD: https://www.freebsd.org
diff --git a/include/lib/cpus/aarch64/cpu_macros.S b/include/lib/cpus/aarch64/cpu_macros.S
index 724624c..404b7f9 100644
--- a/include/lib/cpus/aarch64/cpu_macros.S
+++ b/include/lib/cpus/aarch64/cpu_macros.S
@@ -427,6 +427,23 @@
.endm
/*
+ * Clear a bit in a system register. Can clear multiple bits but is limited by
+ * the way the BIC instrucion encodes them.
+ *
+ * see sysreg_bit_set for usage
+ */
+.macro sysreg_bit_clear _reg:req, _bit:req
+ mrs x1, \_reg
+ bic x1, x1, #\_bit
+ msr \_reg, x1
+.endm
+
+.macro override_vector_table _table:req
+ adr x1, \_table
+ msr vbar_el3, x1
+.endm
+
+/*
* Apply erratum
*
* _cpu:
@@ -497,6 +514,27 @@
endfunc check_erratum_\_cpu\()_\_id
.endm
+.macro check_erratum_chosen _cpu:req, _cve:req, _id:req, _chosen:req
+ func check_erratum_\_cpu\()_\_id
+ .if \_chosen
+ mov x0, #ERRATA_APPLIES
+ .else
+ mov x0, #ERRATA_MISSING
+ .endif
+ ret
+ endfunc check_erratum_\_cpu\()_\_id
+.endm
+
+/* provide a shorthand for the name format for annoying errata */
+.macro check_erratum_custom_start _cpu:req, _cve:req, _id:req
+ func check_erratum_\_cpu\()_\_id
+.endm
+
+.macro check_erratum_custom_end _cpu:req, _cve:req, _id:req
+ endfunc check_erratum_\_cpu\()_\_id
+.endm
+
+
/*******************************************************************************
* CPU reset function wrapper
******************************************************************************/
diff --git a/include/lib/cpus/errata.h b/include/lib/cpus/errata.h
index f8f9555..b280435 100644
--- a/include/lib/cpus/errata.h
+++ b/include/lib/cpus/errata.h
@@ -64,6 +64,10 @@
#define CVE(year, id) year, id
#define NO_ISB 1
#define NO_ASSERT 0
+#define NO_APPLY_AT_RESET 0
+#define APPLY_AT_RESET 1
+/* useful for errata that end up always being worked around */
+#define ERRATUM_ALWAYS_CHOSEN 1
#endif /* __ASSEMBLER__ */
diff --git a/include/lib/smccc.h b/include/lib/smccc.h
index 63637d5..fb2b3a2 100644
--- a/include/lib/smccc.h
+++ b/include/lib/smccc.h
@@ -20,7 +20,7 @@
SMCCC_VERSION_MINOR_SHIFT))
#define SMCCC_MAJOR_VERSION U(1)
-#define SMCCC_MINOR_VERSION U(2)
+#define SMCCC_MINOR_VERSION U(4)
/*******************************************************************************
* Bit definitions inside the function id as per the SMC calling convention
diff --git a/lib/cpus/errata_report.c b/lib/cpus/errata_report.c
index a37ba81..4e9bdfc 100644
--- a/lib/cpus/errata_report.c
+++ b/lib/cpus/errata_report.c
@@ -34,38 +34,51 @@
#define CVE_FORMAT "%s: %s: CPU workaround for CVE %u_%u was %s\n"
#define ERRATUM_FORMAT "%s: %s: CPU workaround for erratum %u was %s\n"
-#define PRINT_STATUS_DISPATCH(status, ...) \
- do { \
- assert(status <= ERRATA_MISSING); \
- switch (status) { \
- case ERRATA_NOT_APPLIES: \
- VERBOSE(__VA_ARGS__, "not applied"); \
- break; \
- case ERRATA_APPLIES: \
- INFO(__VA_ARGS__, "applied"); \
- break; \
- case ERRATA_MISSING: \
- WARN(__VA_ARGS__, "missing!"); \
- break; \
- } \
- } while (0)
+static __unused void print_status(int status, char *cpu_str, uint16_t cve, uint32_t id)
+{
+ if (status == ERRATA_MISSING) {
+ if (cve) {
+ WARN(CVE_FORMAT, BL_STRING, cpu_str, cve, id, "missing!");
+ } else {
+ WARN(ERRATUM_FORMAT, BL_STRING, cpu_str, id, "missing!");
+ }
+ } else if (status == ERRATA_APPLIES) {
+ if (cve) {
+ INFO(CVE_FORMAT, BL_STRING, cpu_str, cve, id, "applied");
+ } else {
+ INFO(ERRATUM_FORMAT, BL_STRING, cpu_str, id, "applied");
+ }
+ } else {
+ if (cve) {
+ VERBOSE(CVE_FORMAT, BL_STRING, cpu_str, cve, id, "not applied");
+ } else {
+ VERBOSE(ERRATUM_FORMAT, BL_STRING, cpu_str, id, "not applied");
+ }
+ }
+}
#if !REPORT_ERRATA
void print_errata_status(void) {}
#else /* !REPORT_ERRATA */
-/* New errata status message printer */
+/*
+ * New errata status message printer
+ * The order checking function is hidden behind the FEATURE_DETECTION flag to
+ * save space. This functionality is only useful on development and platform
+ * bringup builds, when FEATURE_DETECTION should be used anyway
+ */
void __unused generic_errata_report(void)
{
struct cpu_ops *cpu_ops = get_cpu_ops_ptr();
struct erratum_entry *entry = cpu_ops->errata_list_start;
struct erratum_entry *end = cpu_ops->errata_list_end;
long rev_var = cpu_get_rev_var();
+#if FEATURE_DETECTION
uint32_t last_erratum_id = 0;
uint16_t last_cve_yr = 0;
bool check_cve = false;
- /* unused because assert goes away on release */
- bool failed __unused = false;
+ bool failed = false;
+#endif /* FEATURE_DETECTION */
for (; entry != end; entry += 1) {
uint64_t status = entry->check_func(rev_var);
@@ -81,10 +94,10 @@
status = ERRATA_MISSING;
}
- if (entry->cve) {
- PRINT_STATUS_DISPATCH(status, CVE_FORMAT, BL_STRING,
- cpu_ops->cpu_str, entry->cve, entry->id);
+ print_status(status, cpu_ops->cpu_str, entry->cve, entry->id);
+#if FEATURE_DETECTION
+ if (entry->cve) {
if (last_cve_yr > entry->cve ||
(last_cve_yr == entry->cve && last_erratum_id >= entry->id)) {
ERROR("CVE %u_%u was out of order!\n",
@@ -94,9 +107,6 @@
check_cve = true;
last_cve_yr = entry->cve;
} else {
- PRINT_STATUS_DISPATCH(status, ERRATUM_FORMAT, BL_STRING,
- cpu_ops->cpu_str, entry->id);
-
if (last_erratum_id >= entry->id || check_cve) {
ERROR("Erratum %u was out of order!\n",
entry->id);
@@ -104,13 +114,16 @@
}
}
last_erratum_id = entry->id;
+#endif /* FEATURE_DETECTION */
}
+#if FEATURE_DETECTION
/*
* enforce errata and CVEs are in ascending order and that CVEs are
* after errata
*/
assert(!failed);
+#endif /* FEATURE_DETECTION */
}
/*