Report errata workaround status to console

The errata reporting policy is as follows:

  - If an errata workaround is enabled

    - If it applies (i.e. the CPU is affected by the errata), an INFO
      message is printed, confirming that the errata workaround has been
      applied.

    - If it does not apply, a VERBOSE message is printed, confirming
      that the errata workaround has been skipped.

  - If an errata workaround is not enabled, but would have applied had
    it been, a WARN message is printed, alerting that errata workaround
    is missing.

The CPU errata messages are printed by both BL1 (primary CPU only) and
runtime firmware on debug builds, once for each CPU/errata combination.

Relevant output from Juno r1 console when ARM Trusted Firmware is built
with PLAT=juno LOG_LEVEL=50 DEBUG=1:

  VERBOSE: BL1: cortex_a57: errata workaround for 806969 was not applied
  VERBOSE: BL1: cortex_a57: errata workaround for 813420 was not applied
  INFO:    BL1: cortex_a57: errata workaround for disable_ldnp_overread was applied
  WARNING: BL1: cortex_a57: errata workaround for 826974 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 826977 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 828024 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 829520 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 833471 was missing!
  ...
  VERBOSE: BL31: cortex_a57: errata workaround for 806969 was not applied
  VERBOSE: BL31: cortex_a57: errata workaround for 813420 was not applied
  INFO:    BL31: cortex_a57: errata workaround for disable_ldnp_overread was applied
  WARNING: BL31: cortex_a57: errata workaround for 826974 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 826977 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 828024 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 829520 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 833471 was missing!
  ...
  VERBOSE: BL31: cortex_a53: errata workaround for 826319 was not applied
  INFO:    BL31: cortex_a53: errata workaround for disable_non_temporal_hint was applied

Also update documentation.

Change-Id: Iccf059d3348adb876ca121cdf5207bdbbacf2aba
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/52569
Tested-by: iSoC Platform CI <ykjenk@marvell.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>

2 files changed, 74 insertions, 1 deletions

diff --git a/docs/cpu-specific-build-macros.md b/docs/cpu-specific-build-macros.md
index df2fbd86..a743487f 100644
--- a/docs/cpu-specific-build-macros.md
+++ b/docs/cpu-specific-build-macros.md
@@ -34,6 +34,9 @@ errata notice document. The format of the define used to enable/disable the
 errata workaround is `ERRATA_<Processor name>_<ID>`, where the `Processor name`
 is for example `A57` for the `Cortex_A57` CPU.
 
+Refer to the section _CPU errata status reporting_ in [Firmware Design
+guide][Firmware Design] for information on to write errata workaround functions.
+
 All workarounds are disabled by default. The platform is responsible for
 enabling these workarounds according to its requirement by defining the
 errata workaround build flags in the platform specific makefile. In case
@@ -116,3 +119,4 @@ _Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved._
 [A57 SW Optimization Guide]: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
 [A53 Errata Notice]:         http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html
 [A57 Errata Notice]:         http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/cortex_a57_mpcore_software_developers_errata_notice.pdf
+[Firmware Design]:           firmware-design.md
diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index abe7dc5a..945db4d5 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -1087,7 +1087,7 @@ already been performed and act as appropriate. Possible courses of actions are,
 e.g. skip the action the second time, or undo/redo it.
 
 8.  CPU specific operations framework
------------------------------
+-------------------------------------
 
 Certain aspects of the ARMv8 architecture are implementation defined,
 that is, certain behaviours are not architecturally defined, but must be defined
@@ -1102,6 +1102,8 @@ behaviour. The categories are:
 
 3.  Processor specific register dumping as a part of crash reporting.
 
+4.  Errata status reporting.
+
 Each of the above categories fulfils a different requirement.
 
 1.  allows any processor specific initialization before the caches and MMU
@@ -1115,6 +1117,9 @@ Each of the above categories fulfils a different requirement.
     in the event of a crash, for example Cortex-A53 has registers which
     can expose the data cache contents.
 
+4.  allows a processor to define a function that inspects and reports the status
+    of all errata workarounds on that processor.
+
 Please note that only 2. is mandated by the TRM.
 
 The CPU specific operations framework scales to accommodate a large number of
@@ -1184,6 +1189,70 @@ reporting framework calls `do_cpu_reg_dump` which retrieves the matching
 be reported and a pointer to the ASCII list of register names in a format
 expected by the crash reporting framework.
 
+### CPU errata status reporting
+
+Errata workarounds for CPUs supported in ARM Trusted Firmware are applied during
+both cold and warm boots, shortly after reset. Individual Errata workarounds are
+enabled as build options. Some errata workarounds have potential run-time
+implications; 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 the section titled _CPU Errata Workarounds_ in [CPUBM]
+for more information.
+
+Functions in CPU drivers that apply errata workaround must follow the
+conventions listed below.
+
+The errata workaround must be authored as two separate functions:
+
+* 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.
+
+  For an errata identified as `E`, the check function must be named
+  `check_errata_E`.
+
+  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.
+
+* Another one that applies the errata workaround. This function would call the
+  check function described above, and applies errata workaround if required.
+
+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.
+
+In a debug build of ARM Trusted Firmware, on a CPU that comes out of reset, both
+BL1 and the run time 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 ARM Trusted
+Firmware, the errata reporting function is appropriately extended to report its
+status as well.
+
+Reporting the status of errata workaround is for informational purpose only; it
+has no functional significance.
 
 9. Memory layout of BL images
 -----------------------------