1. 20 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      Changes for new version of image loading in BL1/BL2 · 42019bf4
      Yatharth Kochar authored
      This patch adds changes in BL1 & BL2 to use new version
      of image loading to load the BL images.
      
      Following are the changes in BL1:
        -Use new version of load_auth_image() to load BL2
        -Modified `bl1_init_bl2_mem_layout()` to remove using
         `reserve_mem()` and to calculate `bl2_mem_layout`.
         `bl2_mem_layout` calculation now assumes that BL1 RW
         data is at the top of the bl1_mem_layout, which is more
         restrictive than the previous BL1 behaviour.
      
      Following are the changes in BL2:
        -The `bl2_main.c` is refactored and all the functions
         for loading BLxx images are now moved to `bl2_image_load.c`
         `bl2_main.c` now calls a top level `bl2_load_images()` to
         load all the images that are applicable in BL2.
        -Added new file `bl2_image_load_v2.c` that uses new version
         of image loading to load the BL images in BL2.
      
      All the above changes are conditionally compiled using the
      `LOAD_IMAGE_V2` flag.
      
      Change-Id: Ic6dcde5a484495bdc05526d9121c59fa50c1bf23
      42019bf4
  2. 22 Aug, 2016 1 commit
    • Yatharth Kochar's avatar
      Remove looping around `plat_report_exception` · 5bbc451e
      Yatharth Kochar authored
      This patch removes the tight loop that calls `plat_report_exception`
      in unhandled exceptions in AArch64 state.
      The new behaviour is to call the `plat_report_exception` only
      once followed by call to `plat_panic_handler`.
      This allows platforms to take platform-specific action when
      there is an unhandled exception, instead of always spinning
      in a tight loop.
      
      Note: This is a subtle break in behaviour for platforms that
            expect `plat_report_exception` to be continuously executed
            when there is an unhandled exception.
      
      Change-Id: Ie2453804b9b7caf9b010ee73e1a90eeb8384e4e8
      5bbc451e
  3. 09 Aug, 2016 1 commit
  4. 18 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce `el3_runtime` and `PSCI` libraries · 532ed618
      Soby Mathew authored
      This patch moves the PSCI services and BL31 frameworks like context
      management and per-cpu data into new library components `PSCI` and
      `el3_runtime` respectively. This enables PSCI to be built independently from
      BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
      PSCI library sources and gets included by `bl31.mk`. Other changes which
      are done as part of this patch are:
      
      * The runtime services framework is now moved to the `common/` folder to
        enable reuse.
      * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
        specific folder.
      * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
        to `plat/common` folder. The original file location now has a stub which
        just includes the file from new location to maintain platform compatibility.
      
      Most of the changes wouldn't affect platform builds as they just involve
      changes to the generic bl1.mk and bl31.mk makefiles.
      
      NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
      THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
      MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.
      
      Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
      532ed618
  5. 08 Jul, 2016 2 commits
    • Sandrine Bailleux's avatar
      Introduce SEPARATE_CODE_AND_RODATA build flag · 5d1c104f
      Sandrine Bailleux authored
      At the moment, all BL images share a similar memory layout: they start
      with their code section, followed by their read-only data section.
      The two sections are contiguous in memory. Therefore, the end of the
      code section and the beginning of the read-only data one might share
      a memory page. This forces both to be mapped with the same memory
      attributes. As the code needs to be executable, this means that the
      read-only data stored on the same memory page as the code are
      executable as well. This could potentially be exploited as part of
      a security attack.
      
      This patch introduces a new build flag called
      SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
      on separate memory pages. This in turn allows independent control of
      the access permissions for the code and read-only data.
      
      This has an impact on memory footprint, as padding bytes need to be
      introduced between the code and read-only data to ensure the
      segragation of the two. To limit the memory cost, the memory layout
      of the read-only section has been changed in this case.
      
       - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
         the read-only section still looks like this (padding omitted):
      
         |        ...        |
         +-------------------+
         | Exception vectors |
         +-------------------+
         |  Read-only data   |
         +-------------------+
         |       Code        |
         +-------------------+ BLx_BASE
      
         In this case, the linker script provides the limits of the whole
         read-only section.
      
       - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
         read-only data are swapped, such that the code and exception
         vectors are contiguous, followed by the read-only data. This
         gives the following new layout (padding omitted):
      
         |        ...        |
         +-------------------+
         |  Read-only data   |
         +-------------------+
         | Exception vectors |
         +-------------------+
         |       Code        |
         +-------------------+ BLx_BASE
      
         In this case, the linker script now exports 2 sets of addresses
         instead: the limits of the code and the limits of the read-only
         data. Refer to the Firmware Design guide for more details. This
         provides platform code with a finer-grained view of the image
         layout and allows it to map these 2 regions with the appropriate
         access permissions.
      
      Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
      
      Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
      5d1c104f
    • Sandrine Bailleux's avatar
      BL1: Add linker symbol identifying end of ROM content · c02fcc4a
      Sandrine Bailleux authored
      This patch adds a new linker symbol in BL1's linker script named
      '__BL1_ROM_END__', which marks the end of BL1's ROM content. This
      covers BL1's code, read-only data and read-write data to relocate
      in Trusted SRAM. The address of this new linker symbol is exported
      to C code through the 'BL1_ROM_END' macro.
      
      The section related to linker symbols in the Firmware Design guide
      has been updated and improved.
      
      Change-Id: I5c442ff497c78d865ffba1d7d044511c134e11c7
      c02fcc4a
  6. 03 Jun, 2016 1 commit
    • Soby Mathew's avatar
      Build option to include AArch32 registers in cpu context · 8cd16e6b
      Soby Mathew authored
      The system registers that are saved and restored in CPU context include
      AArch32 systems registers like SPSR_ABT, SPSR_UND, SPSR_IRQ, SPSR_FIQ,
      DACR32_EL2, IFSR32_EL2 and FPEXC32_EL2. Accessing these registers on an
      AArch64-only (i.e. on hardware that does not implement AArch32, or at
      least not at EL1 and higher ELs) platform leads to an exception. This patch
      introduces the build option `CTX_INCLUDE_AARCH32_REGS` to specify whether to
      include these AArch32 systems registers in the cpu context or not. By default
      this build option is set to 1 to ensure compatibility. AArch64-only platforms
      must set it to 0. A runtime check is added in BL1 and BL31 cold boot path to
      verify this.
      
      Fixes ARM-software/tf-issues#386
      
      Change-Id: I720cdbd7ed7f7d8516635a2ec80d025f478b95ee
      8cd16e6b
  7. 26 May, 2016 1 commit
    • Sandrine Bailleux's avatar
      Introduce some helper macros for exception vectors · e0ae9fab
      Sandrine Bailleux authored
      This patch introduces some assembler macros to simplify the
      declaration of the exception vectors. It abstracts the section
      the exception code is put into as well as the alignments
      constraints mandated by the ARMv8 architecture. For all TF images,
      the exception code has been updated to make use of these macros.
      
      This patch also updates some invalid comments in the exception
      vector code.
      
      Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
      e0ae9fab
  8. 30 Mar, 2016 1 commit
    • Gerald Lejeune's avatar
      Enable asynchronous abort exceptions during boot · adb4fcfb
      Gerald Lejeune authored
      
      
      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: default avatarGerald Lejeune <gerald.lejeune@st.com>
      adb4fcfb
  9. 22 Feb, 2016 1 commit
    • Yatharth Kochar's avatar
      Fix the inconsistencies in bl1_tbbr_image_descs[] · 843ddee4
      Yatharth Kochar authored
      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
      843ddee4
  10. 15 Dec, 2015 2 commits
    • Dan Handley's avatar
      FWU: Pass client cookie to FWU_SMC_UPDATE_DONE · 1f37b944
      Dan Handley authored
      The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
      an unused framework cookie through to the 1st argument in the
      platform function `bl1_plat_fwu_done`. The intent is to allow
      the SMC caller to pass a cookie through to this function.
      
      This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
      through to `bl1_plat_fwu_done`. The argument names are updated
      for clarity.
      
      Upstream platforms currently do not use this argument so no
      impact is expected.
      
      Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
      1f37b944
    • Dan Handley's avatar
      FWU: Remove image_id arg from FWU_SMC_IMAGE_RESUME · 28955d57
      Dan Handley authored
      The current implementation of FWU_SMC_IMAGE_RESUME when called
      from the normal world, uses the provided image_id argument to
      determine which secure image to resume into. This implies that
      the normal world has a choice of which secure image to resume
      into when in fact it is only possible to resume into the
      previously interrupted secure image.
      
      This patch removes the argument, tightens up the pre-conditions
      for the SMC and adds additional asserts.
      
      The pre-conditions for FWU_SMC_SEC_IMAGE_DONE are also
      tightened up.
      
      Change-Id: Ia5a46753bb01e8f8dad8a2999314f90db8f300e8
      28955d57
  11. 14 Dec, 2015 2 commits
    • Dan Handley's avatar
      FWU: Fix secure memory check in image auth · 03131c85
      Dan Handley authored
      The implementation of FWU_SMC_IMAGE_AUTH performs a number of
      pre-condition checks before authenticating the image. One of
      these checks calls `bl1_plat_mem_check()` to ensure the image
      source is mapped in when authenticating an image in place.
      The framework incorrectly passes the security state of the
      caller into this function instead of the security state of
      the source image.
      
      This patch corrects the defect. The defect would only
      manifest itself for secure world callers authenticating
      non-secure images in place, which is not done by current
      upstream platforms.
      
      Change-Id: I617c7b43e02ac7149f266aeaf3874316e62f3003
      03131c85
    • Juan Castillo's avatar
      Remove dashes from image names: 'BL3-x' --> 'BL3x' · d178637d
      Juan Castillo authored
      This patch removes the dash character from the image name, to
      follow the image terminology in the Trusted Firmware Wiki page:
      
          https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      Changes apply to output messages, comments and documentation.
      
      non-ARM platform files have been left unmodified.
      
      Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
      d178637d
  12. 09 Dec, 2015 4 commits
    • Yatharth Kochar's avatar
      FWU: Add Generic Firmware Update framework support in BL1 · 48bfb88e
      Yatharth Kochar authored
      Firmware update(a.k.a FWU) feature is part of the TBB architecture.
      BL1 is responsible for carrying out the FWU process if platform
      specific code detects that it is needed.
      
      This patch adds support for FWU feature support in BL1 which is
      included by enabling `TRUSTED_BOARD_BOOT` compile time flag.
      
      This patch adds bl1_fwu.c which contains all the core operations
      of FWU, which are; SMC handler, image copy, authentication, execution
      and resumption. It also adds bl1.h introducing #defines for all
      BL1 SMCs.
      
      Following platform porting functions are introduced:
      
      int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size,
      unsigned int flags);
      	This function can be used to add platform specific memory checks
      	for the provided base/size for the given security state.
      	The weak definition will invoke `assert()` and return -ENOMEM.
      
      __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved);
      	This function can be used to initiate platform specific procedure
      	to mark completion of the FWU process.
      	The weak definition waits forever calling `wfi()`.
      
      plat_bl1_common.c contains weak definitions for above functions.
      
      FWU process starts when platform detects it and return the image_id
      other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in
      `bl1_main()`.
      
      NOTE: User MUST provide platform specific real definition for
      bl1_plat_mem_check() in order to use it for Firmware update.
      
      Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
      48bfb88e
    • Yatharth Kochar's avatar
      Add descriptor based image management support in BL1 · 7baff11f
      Yatharth Kochar authored
      As of now BL1 loads and execute BL2 based on hard coded information
      provided in BL1. But due to addition of support for upcoming Firmware
      Update feature, BL1 now require more flexible approach to load and
      run different images using information provided by the platform.
      
      This patch adds new mechanism to load and execute images based on
      platform provided image id's. BL1 now queries the platform to fetch
      the image id of the next image to be loaded and executed. In order
      to achieve this, a new struct image_desc_t was added which holds the
      information about images, such as: ep_info and image_info.
      
      This patch introduces following platform porting functions:
      
      unsigned int bl1_plat_get_next_image_id(void);
      	This is used to identify the next image to be loaded
      	and executed by BL1.
      
      struct image_desc *bl1_plat_get_image_desc(unsigned int image_id);
      	This is used to retrieve the image_desc for given image_id.
      
      void bl1_plat_set_ep_info(unsigned int image_id,
      struct entry_point_info *ep_info);
      	This function allows platforms to update ep_info for given
      	image_id.
      
      The plat_bl1_common.c file provides default weak implementations of
      all above functions, the `bl1_plat_get_image_desc()` always return
      BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return
      BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns.
      These functions gets compiled into all BL1 platforms by default.
      
      Platform setup in BL1, using `bl1_platform_setup()`, is now done
      _after_ the initialization of authentication module. This change
      provides the opportunity to use authentication while doing the
      platform setup in BL1.
      
      In order to store secure/non-secure context, BL31 uses percpu_data[]
      to store context pointer for each core. In case of BL1 only the
      primary CPU will be active hence percpu_data[] is not required to
      store the context pointer.
      
      This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to
      store the context and context pointers respectively. It also also
      re-defines cm_get_context() and cm_set_context() for BL1 in
      bl1/bl1_context_mgmt.c.
      
      BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime
      environment, to support resuming execution from a previously saved
      context.
      
      NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS
            NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE
            THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()`
            INSTEAD TO MAINTAIN EXISTING BEHAVIOUR.
      
      Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
      7baff11f
    • Yatharth Kochar's avatar
      Move context management code to common location · bbf8f6f9
      Yatharth Kochar authored
      The upcoming Firmware Update feature needs transitioning across
      Secure/Normal worlds to complete the FWU process and hence requires
      context management code to perform this task.
      
      Currently context management code is part of BL31 stage only.
      This patch moves the code from (include)/bl31 to (include)/common.
      Some function declarations/definitions and macros have also moved
      to different files to help code sharing.
      
      Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
      bbf8f6f9
    • Yatharth Kochar's avatar
      Remove `RUN_IMAGE` usage as opcode passed to next EL. · 5698c5b3
      Yatharth Kochar authored
      The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to
      make a request to BL1 to execute BL31. But BL2 also uses it as
      opcode to check if it is allowed to execute which is not the
      intended usage of `RUN_IMAGE` SMC.
      
      This patch removes the usage of `RUN_IMAGE` as opcode passed to
      next EL to check if it is allowed to execute.
      
      Change-Id: I6aebe0415ade3f43401a4c8a323457f032673657
      5698c5b3
  13. 26 Nov, 2015 3 commits
    • Sandrine Bailleux's avatar
      Introduce COLD_BOOT_SINGLE_CPU build option · a9bec67d
      Sandrine Bailleux authored
      This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
      which allows platforms that only release a single CPU out of reset to
      slightly optimise their cold boot code, both in terms of code size
      and performance.
      
      COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
      may release several CPUs out of reset. In this case, the cold reset
      code needs to coordinate all CPUs via the usual primary/secondary
      CPU distinction.
      
      If a platform guarantees that only a single CPU will ever be released
      out of reset, there is no need to arbitrate execution ; the notion of
      primary and secondary CPUs itself no longer exists. Such platforms
      may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
      primary/secondary CPU identification in the cold reset code.
      
      All ARM standard platforms can release several CPUs out of reset
      so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
      Juno, bringing up more than one CPU at reset should only be attempted
      when booting an EL3 payload, as it is not fully supported in the
      normal boot flow.
      
      For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
      APIs become optional:
        - plat_secondary_cold_boot_setup();
        - plat_is_my_cpu_primary().
      The Porting Guide has been updated to reflect that.
      
      User Guide updated as well.
      
      Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
      a9bec67d
    • Sandrine Bailleux's avatar
      Pass the entry point info to bl1_plat_prepare_exit() · 862b5dc2
      Sandrine Bailleux authored
      This patch modifies the prototype of the bl1_plat_prepare_exit()
      platform API to pass the address of the entry point info structure
      received from BL2. The structure contains information that can be
      useful, depending on the kind of clean up or bookkeeping operations
      to perform.
      
      The weak implementation of this function ignores this argument to
      preserve platform backwards compatibility.
      
      NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
      FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.
      
      Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
      862b5dc2
    • Sandrine Bailleux's avatar
      Introduce SPIN_ON_BL1_EXIT build flag · 35e8c766
      Sandrine Bailleux authored
      This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
      puts an infinite loop in BL1. It is intended to help debugging
      the post-BL2 phase of the Trusted Firmware by stopping execution
      in BL1 just before handing over to BL31. At this point, the
      developer may take control of the target using a debugger.
      
      This feature is disabled by default and can be enabled by
      rebuilding BL1 with SPIN_ON_BL1_EXIT=1.
      
      User Guide updated accordingly.
      
      Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c
      35e8c766
  14. 02 Nov, 2015 2 commits
    • Sandrine Bailleux's avatar
      Improve display_boot_progress() function · ee5c2b13
      Sandrine Bailleux authored
       - Remove out-dated information about the use of printf() in the
         function comment.
      
       - Make the argument const, as the function doesn't need to modify it.
      
       - Rename the function into bl1_print_bl31_ep_info() to make its
         purpose clearer.
      
      Change-Id: I2a9d215a37f0ec11aefce0c5c9e050473b7a6b25
      ee5c2b13
    • Sandrine Bailleux's avatar
      Introduce print_entry_point_info() function · 68a68c92
      Sandrine Bailleux authored
      This patch introduces a new function called 'print_entry_point_info'
      that prints an entry_point_t structure for debugging purposes.
      As such, it can be used to display the entry point address, SPSR and
      arguments passed from a firmware image to the next one.
      
      This function is now called in the following images transitions:
       - BL1 to BL2
       - BL1 to BL31
       - BL31 to the next image (typically BL32 or BL33)
      
      The following changes have been introduced:
      
       - Fix the output format of the SPSR value : SPSR is a 32-bit value,
         not a 64-bit one.
      
       - Print all arguments values.
         The entry_point_info_t structure allows to pass up to 8 arguments.
         In most cases, only the first 2 arguments were printed.
         print_entry_point_info() now prints all of them as 'VERBOSE'
         traces.
      
      Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a
      68a68c92
  15. 28 Oct, 2015 1 commit
    • Juan Castillo's avatar
      Add optional platform error handler API · 40fc6cd1
      Juan Castillo authored
      This patch adds an optional API to the platform port:
      
          void plat_error_handler(int err) __dead2;
      
      The platform error handler is called when there is a specific error
      condition after which Trusted Firmware cannot continue. While panic()
      simply prints the crash report (if enabled) and spins, the platform
      error handler can be used to hand control over to the platform port
      so it can perform specific bookeeping or post-error actions (for
      example, reset the system). This function must not return.
      
      The parameter indicates the type of error using standard codes from
      errno.h. Possible errors reported by the generic code are:
      
          -EAUTH  : a certificate or image could not be authenticated
                    (when Trusted Board Boot is enabled)
          -ENOENT : the requested image or certificate could not be found
                    or an IO error was detected
          -ENOMEM : resources exhausted. Trusted Firmware does not use
                    dynamic memory, so this error is usually an indication
                    of an incorrect array size
      
      A default weak implementation of this function has been provided.
      It simply implements an infinite loop.
      
      Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
      40fc6cd1
  16. 20 Oct, 2015 1 commit
    • Juan Castillo's avatar
      Add optional bl1_plat_prepare_exit() API · e3f67124
      Juan Castillo authored
      This patch adds an optional API to the platform port:
      
          void bl1_plat_prepare_exit(void);
      
      This function is called prior to exiting BL1 in response to the
      RUN_IMAGE_SMC request raised by BL2. It should be used to perform
      platform specific clean up or bookkeeping operations before
      transferring control to the next image.
      
      A weak empty definition of this function has been provided to
      preserve platform backwards compatibility.
      
      Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1
      e3f67124
  17. 19 Oct, 2015 1 commit
    • Sandrine Bailleux's avatar
      Break down BL1 AArch64 synchronous exception handler · 1fe4d453
      Sandrine Bailleux authored
      The AArch64 synchronous exception vector code in BL1 is almost
      reaching its architectural limit of 32 instructions. This means
      there is very little space for this code to grow.
      
      This patch reduces the size of the exception vector code by
      moving most of its code in a function to which we branch from
      SynchronousExceptionA64.
      
      Change-Id: Ib35351767a685fb2c2398029d32e54026194f7ed
      1fe4d453
  18. 02 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Ensure BL2 security state is secure · a2f8b166
      Vikram Kanigiri authored
      BL2 loads secure runtime code(BL3-1, BL3-2) and hence it has to
      run in secure world otherwise BL3-1/BL3-2 have to execute from
      non-secure memory. Hence, This patch removes the change_security_state()
      call in bl1_run_bl2() and replaces it with an assert to confirm
      the BL2 as secure.
      
      Fixes ARM-software/tf-issues#314
      
      Change-Id: I611b83f5c4090e58a76a2e950b0d797b46df3c29
      a2f8b166
  19. 25 Jun, 2015 3 commits
    • Juan Castillo's avatar
      TBB: switch to the new authentication framework · 1779ba6b
      Juan Castillo authored
      This patch modifies the Trusted Board Boot implementation to use
      the new authentication framework, making use of the authentication
      module, the cryto module and the image parser module to
      authenticate the images in the Chain of Trust.
      
      A new function 'load_auth_image()' has been implemented. When TBB
      is enabled, this function will call the authentication module to
      authenticate parent images following the CoT up to the root of
      trust to finally load and authenticate the requested image.
      
      The platform is responsible for picking up the right makefiles to
      build the corresponding cryptographic and image parser libraries.
      ARM platforms use the mbedTLS based libraries.
      
      The platform may also specify what key algorithm should be used
      to sign the certificates. This is done by declaring the 'KEY_ALG'
      variable in the platform makefile. FVP and Juno use ECDSA keys.
      
      On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
      each to accommodate the ECDSA code.
      
      REMOVED BUILD OPTIONS:
      
        * 'AUTH_MOD'
      
      Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
      1779ba6b
    • Juan Castillo's avatar
      TBB: add authentication framework · 05799ae0
      Juan Castillo authored
      This patch adds the authentication framework that will be used as
      the base to implement Trusted Board Boot in the Trusted Firmware.
      The framework comprises the following modules:
      
      - Image Parser Module (IPM)
      
          This module is responsible for interpreting images, check
          their integrity and extract authentication information from
          them during Trusted Board Boot.
      
          The module currently supports three types of images i.e.
          raw binaries, X509v3 certificates and any type specific to
          a platform. An image parser library must be registered for
          each image type (the only exception is the raw image parser,
          which is included in the main module by default).
      
          Each parser library (if used) must export a structure in a
          specific linker section which contains function pointers to:
      
              1. Initialize the library
              2. Check the integrity of the image type supported by
                 the library
              3. Extract authentication information from the image
      
      - Cryptographic Module (CM)
      
          This module is responsible for verifying digital signatures
          and hashes. It relies on an external cryptographic library
          to perform the cryptographic operations.
      
          To register a cryptographic library, the library must use the
          REGISTER_CRYPTO_LIB macro, passing function pointers to:
      
              1. Initialize the library
              2. Verify a digital signature
              3. Verify a hash
      
          Failing to register a cryptographic library will generate
          a build time error.
      
      - Authentication Module (AM)
      
          This module provides methods to authenticate an image, like
          hash comparison or digital signatures. It uses the image parser
          module to extract authentication parameters, the crypto module
          to perform cryptographic operations and the Chain of Trust to
          authenticate the images.
      
          The Chain of Trust (CoT) is a data structure that defines the
          dependencies between images and the authentication methods
          that must be followed to authenticate an image.
      
      The Chain of Trust, when added, must provide a header file named
      cot_def.h with the following definitions:
      
      - COT_MAX_VERIFIED_PARAMS
      
          Integer value indicating the maximum number of authentication
          parameters an image can present. This value will be used by the
          authentication module to allocate the memory required to load
          the parameters in the image descriptor.
      
      Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178
      05799ae0
    • Juan Castillo's avatar
      Use numbers to identify images instead of names · 16948ae1
      Juan Castillo authored
      The Trusted firmware code identifies BL images by name. The platform
      port defines a name for each image e.g. the IO framework uses this
      mechanism in the platform function plat_get_image_source(). For
      a given image name, it returns the handle to the image file which
      involves comparing images names. In addition, if the image is
      packaged in a FIP, a name comparison is required to find the UUID
      for the image. This method is not optimal.
      
      This patch changes the interface between the generic and platform
      code with regard to identifying images. The platform port must now
      allocate a unique number (ID) for every image. The generic code will
      use the image ID instead of the name to access its attributes.
      
      As a result, the plat_get_image_source() function now takes an image
      ID as an input parameter. The organisation of data structures within
      the IO framework has been rationalised to use an image ID as an index
      into an array which contains attributes of the image such as UUID and
      name. This prevents the name comparisons.
      
      A new type 'io_uuid_spec_t' has been introduced in the IO framework
      to specify images identified by UUID (i.e. when the image is contained
      in a FIP file). There is no longer need to maintain a look-up table
      [iname_name --> uuid] in the io_fip driver code.
      
      Because image names are no longer mandatory in the platform port, the
      debug messages in the generic code will show the image identifier
      instead of the file name. The platforms that support semihosting to
      load images (i.e. FVP) must provide the file names as definitions
      private to the platform.
      
      The ARM platform ports and documentation have been updated accordingly.
      All ARM platforms reuse the image IDs defined in the platform common
      code. These IDs will be used to access other attributes of an image in
      subsequent patches.
      
      IMPORTANT: applying this patch breaks compatibility for platforms that
      use TF BL1 or BL2 images or the image loading code. The platform port
      must be updated to match the new interface.
      
      Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
      16948ae1
  20. 19 Jun, 2015 1 commit
    • Andrew Thoelke's avatar
      Fix incorrect assertions in bl1_main() · 354ab57d
      Andrew Thoelke authored
      The validation of the caching enable state in bl1_main() was
      incorrect resulting in the state not being checked. Using the right
      operator fixes this.
      
      Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51
      354ab57d
  21. 04 Jun, 2015 2 commits
    • Sandrine Bailleux's avatar
      Introduce PROGRAMMABLE_RESET_ADDRESS build option · bf031bba
      Sandrine Bailleux authored
      This patch introduces a new platform build option, called
      PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
      a programmable or fixed reset vector address.
      
      If the reset vector address is fixed then the code relies on the
      platform_get_entrypoint() mailbox mechanism to figure out where
      it is supposed to jump. On the other hand, if it is programmable
      then it is assumed that the platform code will program directly
      the right address into the RVBAR register (instead of using the
      mailbox redirection) so the mailbox is ignored in this case.
      
      Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
      bf031bba
    • Sandrine Bailleux's avatar
      Rationalize reset handling code · 52010cc7
      Sandrine Bailleux authored
      The attempt to run the CPU reset code as soon as possible after reset
      results in highly complex conditional code relating to the
      RESET_TO_BL31 option.
      
      This patch relaxes this requirement a little. In the BL1, BL3-1 and
      PSCI entrypoints code, the sequence of operations is now as follows:
       1) Detect whether it is a cold or warm boot;
       2) For cold boot, detect whether it is the primary or a secondary
          CPU. This is needed to handle multiple CPUs entering cold reset
          simultaneously;
       3) Run the CPU init code.
      
      This patch also abstracts the EL3 registers initialisation done by
      the BL1, BL3-1 and PSCI entrypoints into common code.
      
      This improves code re-use and consolidates the code flows for
      different types of systems.
      
      NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
      NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
      FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
      OTHERWISE, SECONDARY CPUS WILL PANIC.
      
      Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
      52010cc7
  22. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Remove use of PLATFORM_CACHE_LINE_SIZE · ce4c820d
      Dan Handley authored
      The required platform constant PLATFORM_CACHE_LINE_SIZE is
      unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
      same information. CACHE_WRITEBACK_GRANULE is preferred since this
      is an architecturally defined term and allows comparison with the
      corresponding hardware register value.
      
      Replace all usage of PLATFORM_CACHE_LINE_SIZE with
      CACHE_WRITEBACK_GRANULE.
      
      Also, add a runtime assert in BL1 to check that the provided
      CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
      
      Change-Id: If87286be78068424217b9f3689be358356500dcd
      ce4c820d
  23. 08 Apr, 2015 1 commit
    • Kévin Petit's avatar
      Add support to indicate size and end of assembly functions · 8b779620
      Kévin Petit authored
      
      
      In order for the symbol table in the ELF file to contain the size of
      functions written in assembly, it is necessary to report it to the
      assembler using the .size directive.
      
      To fulfil the above requirements, this patch introduces an 'endfunc'
      macro which contains the .endfunc and .size directives. It also adds
      a .func directive to the 'func' assembler macro.
      
      The .func/.endfunc have been used so the assembler can fail if
      endfunc is omitted.
      
      Fixes ARM-Software/tf-issues#295
      
      Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
      Signed-off-by: default avatarKévin Petit <kevin.petit@arm.com>
      8b779620
  24. 28 Jan, 2015 1 commit
    • Juan Castillo's avatar
      TBB: authenticate BL2 image and certificate · 01df3c14
      Juan Castillo authored
      This patch adds support to authenticate the BL2 content certificate
      and image using the authentication module in BL1.
      
      The FIP driver has been extended to include the BL2 certificate
      UUID.
      
      FVP and Juno ports include the BL2 certificate FIP file
      definition.
      
      Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
      01df3c14
  25. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
  26. 19 Sep, 2014 1 commit
    • Juan Castillo's avatar
      Fix LENGTH attribute value in linker scripts · d7fbf132
      Juan Castillo authored
      This patch fixes the incorrect value of the LENGTH attribute in
      the linker scripts. This attribute must define the memory size, not
      the limit address.
      
      Fixes ARM-software/tf-issues#252
      
      Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
      d7fbf132
  27. 27 Aug, 2014 1 commit
  28. 20 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Introduce framework for CPU specific operations · 9b476841
      Soby Mathew authored
      This patch introduces a framework which will allow CPUs to perform
      implementation defined actions after a CPU reset, during a CPU or cluster power
      down, and when a crash occurs. CPU specific reset handlers have been implemented
      in this patch. Other handlers will be implemented in subsequent patches.
      
      Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
      
      Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
      9b476841