Merge pull request #9 from jmarinho/master

Remove TF-A related nomenclature from the spec.

source/chapter1-about.rst

@@ -36,7 +36,7 @@ rest of the document.
 
 The intent of this document is to provide guidelines for firmware updates that will protect the
 device against bricking and rollback attacks. The update itself may occur from the non-secure world
-(BL33) or the secure world (BL32) depending on the implementation and the hardware requirements.
+(Non-secure firmware) or the secure world (Secure firmware) depending on the implementation and the hardware requirements.
 
 
 *Comments or change requests can be sent to `boot-architecture@lists.linaro.org`.*
@@ -59,9 +59,9 @@ Assumptions
 - Update capsules are designed and deployed to target systems using a mechanism outside the
   scope of this document.  [#UEFICapsuleUpdateNote]_
 - We assume that the masked ROM can load TF-A from a dual image.  In case the masked ROM can not
-  boot with an alternative location, similar functionality can be added to BL2.
-  In that case updating of BL2 should be disallowed from OTA
-  update.  In person update of BL2 may be possible and may require extra
+  boot with an alternative location, similar functionality can be added to Secondary bootloader stage.
+  In that case updating of Secondary bootloader stage should be disallowed from OTA
+  update.  In person update of Secondary bootloader stage may be possible and may require extra
   tools or procedures but that is out of the scope of this document.
 - Update process can target a single firmware component or multiple components.  Updating multiple
   components and multiplexing boot combinations can be very challenging.  In this document we treat
@@ -88,7 +88,7 @@ Instead of having each firmware component non-volatile counter (used for rollbac
 increased upon successful update, we can leave the counter untouched until the operating system
 has reached a verdict.  If the OS decides the current state is operational it will signal via UEFI
 services and send capsule update indicating the transaction is successful.
-The firmware running in BL33 will, on next reboot, signal the individual firmware binaries to
+The Non-secure firmware will, on next reboot, signal the individual firmware binaries to
 increase their rollback counter to the correct value.  This assumes A/B partitions for all
 firmware components and a TF-A upgrade mechanism that supports this functionality.
 

source/chapter2-uefi.rst

@@ -39,7 +39,7 @@ EFI_FIRMWARE_IMAGE_DESCRIPTOR provided by FMP.GetImageInfo().
 The resource entry field FwClass must be set  to “ESRT_FW_TYPE_SYSTEMFIRMWARE”
 The fields LowestSupportedVersion, FwVersion are provided by
 - the Secure World FWU when Secure world is responsible for the update
-- BL33 if Non-Secure world is responsible for the update
+- Non-secure firmware if Non-Secure world is responsible for the update
 
 LastAttemptStatus is expected to be information kept by the UEFI implementation. This can partially
 rely on information provided by early platform bootstages [FWU]_.

source/chapter3-fwupdate.rst

@@ -21,7 +21,7 @@ The FWU metadata [FWU]_ is managed by the FWU Implementation in the Secure world
 When the flash is owned by the Secure World, the FMP communicates with the FWU Implementation 
 in the secure world using the FF-A Firmware Update ABI [FWU]_
 
-The FWU Implementation provides BL33 with a list of all FW images handled by it.  The information 
+The FWU Implementation provides Non-secure firmware with a list of all FW images handled by it.  The information 
 is provided via the image directory [#FFANote]_.
 
 .. [#FFANote] image directory is a stream of data structured as an array of image entries [FWU]_.
@@ -119,8 +119,8 @@ Post-capsule install reboot success
 #. OS install the image acceptance capsule when all acceptance tests pass
 #. Firmware processes the image acceptance capsule and updates the boot bank
 #. Rollback counter updates
-    * If BL33 can update the rollback counter(s) directly, it should do it on the fly
-    * Otherwise, on the next reboot BL2 must detect the new version 
+    * If the Non-secure firmware can update the rollback counter(s) directly, it should do it on the fly
+    * Otherwise, on the next reboot Secure firmware must detect the new version 
       (rollback counter < fw rollback counter)and update the rollback counter(s) accordingly.
 
 Post-capsule install reboot fails before UEFI

source/conventions.rst

@@ -31,20 +31,23 @@ This document uses the following terms and abbreviations.
    EBBR
       Embedded Base Boot Requirements
 
-   Boot Loader stage 1 (BL1)
-      AP Trusted ROM
+   ROM
+      Read only memory
 
-   Boot Loader stage 2 (BL2)
-      Trusted Boot Firmware
+   Immutable bootloader stage (Immutable stage)
+      First bootloader stage, generally stored in a ROM -- equatable to BL1 in TF-A or u-boot-spl.
 
-   Boot Loader stage 3-1 (BL31)
-      EL3 Runtime Firmware
+   Secondary bootloader stage (Secondary stage)
+      Optional bootloader stage that executes following the immutable stage -- equatable to BL2 in TF-A.
 
-   Boot Loader stage 3-2 (BL32)
-      Secure-EL1 Payload (optional)
+   Monitor Firmware
+      EL3 Runtime Firmware -- refered to as BL31 in TF-A.
 
-   Boot Loader stage 3-3 (BL33)
-      Non-trusted Firmware
+   Secure firmware
+      Firmware executing at S-EL2 and/or S-EL1 -- BL32 in the TF-A context. The Secure payload can be composed of different binaries.
+
+   Non-secure firmware
+      Firmware executing at EL2 or EL1 -- BL33 in the TF-A context.
 
    SCP Firmware
       System Control Processor firmware