1. 09 Mar, 2016 3 commits
  2. 22 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rationalise MMU and Page table related constants on ARM platforms · c64a0448
      Vikram Kanigiri authored
      `board_arm_def.h` contains multiple definitions of
      `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
      memory usage depending upon the chosen build configuration. To ease
      maintenance of these constants, this patch replaces their multiple
      definitions with a single set of definitions that will work on all ARM
      platforms.
      
      Platforms can override the defaults with optimal values by enabling the
      `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
      the Juno ADP port.
      
      Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
      future ARM platforms.
      
      Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
      c64a0448
  3. 19 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Allow multi cluster topology definitions for ARM platforms · 0108047a
      Soby Mathew authored
      The common topology description helper funtions and macros for
      ARM Standard platforms assumed a dual cluster system. This is not
      flexible enough to scale to multi cluster platforms. This patch does
      the following changes for more flexibility in defining topology:
      
      1. The `plat_get_power_domain_tree_desc()` definition is moved from
         `arm_topology.c` to platform specific files, that is `fvp_topology.c`
         and `juno_topology.c`. Similarly the common definition of the porting
         macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
         specific `platform_def.h` header.
      
      2. The ARM common layer porting macros which were dual cluster specific
         are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
         which must be defined by each ARM standard platform.
      
      3. A new mandatory ARM common layer porting API
         `plat_arm_get_cluster_core_count()` is introduced to enable the common
         implementation of `arm_check_mpidr()` to validate MPIDR.
      
      4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
         introduced which allows the user to specify the cluster count to be
         used to build the topology tree within Trusted Firmare. This enables
         Trusted Firmware to be built for multi cluster FVP models.
      
      Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
      0108047a
  4. 18 Feb, 2016 1 commit
    • Juan Castillo's avatar
      ARM platforms: rationalise memory attributes of shared memory · 74eb26e4
      Juan Castillo authored
      The shared memory region on ARM platforms contains the mailboxes and,
      on Juno, the payload area for communication with the SCP. This shared
      memory may be configured as normal memory or device memory at build
      time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
      Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
      When set as normal memory, the platform port performs the corresponding
      cache maintenance operations. From a functional point of view, this is
      the equivalent of setting the shared memory as device memory, so there
      is no need to maintain both options.
      
      This patch removes the option to specify the shared memory as normal
      memory on ARM platforms. Shared memory is always treated as device
      memory. Cache maintenance operations are no longer needed and have
      been replaced by data memory barriers to guarantee that payload and
      MHU are accessed in the right order.
      
      Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
      74eb26e4
  5. 17 Feb, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Fix gpio includes of mt8173 platform to avoid collision. · e0ea0928
      Antonio Nino Diaz authored
      All files including plat/mediatek/mt8173/drivers/gpio/gpio.h were
      using system includes instead of user includes, which may cause the
      wrong version of the header to be included. Said includes have been
      changed to user includes to make sure that the included file is the
      wanted one.
      
      Change-Id: I29bdfe96fbd9a7900875e2357bbb43f3ea431fa5
      e0ea0928
  6. 16 Feb, 2016 2 commits
    • Vikram Kanigiri's avatar
      Rework use of interconnect drivers · 6355f234
      Vikram Kanigiri authored
      ARM Trusted Firmware supports 2 different interconnect peripheral
      drivers: CCI and CCN. ARM platforms are implemented using either of the
      interconnect peripherals.
      
      This patch adds a layer of abstraction to help ARM platform ports to
      choose the right interconnect driver and corresponding platform support.
      This is as described below:
      
      1. A set of ARM common functions have been implemented to initialise an
      interconnect and for entering/exiting a cluster from coherency. These
      functions are prefixed as "plat_arm_interconnect_". Weak definitions of
      these functions have been provided for each type of driver.
      
      2.`plat_print_interconnect_regs` macro used for printing CCI registers is
      moved from a common arm_macros.S to cci_macros.S.
      
      3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
      is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
      
      Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
      6355f234
    • Vikram Kanigiri's avatar
      Make SCP_BL2(U) image loading configurable on CSS platforms · 7fb9a32d
      Vikram Kanigiri authored
      Current code mandates loading of SCP_BL2/SCP_BL2U images for all
      CSS platforms. On future ARM CSS platforms, the Application
      Processor (AP) might not need to load these images. So, these
      items can be removed from the FIP on those platforms.
      
      BL2 tries to load  SCP_BL2/SCP_BL2U images if their base
      addresses are defined causing boot error if the images are not
      found in FIP.
      
      This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
      to `1` does:
      1. Adds SCP_BL2, SCP_BL2U images to FIP.
      2. Defines the base addresses of these images so that AP loads
         them.
      
      And vice-versa if it is set to `0`. The default value is set to
      `1`.
      
      Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
      7fb9a32d
  7. 15 Feb, 2016 3 commits
    • Vikram Kanigiri's avatar
      Perform security setup separately for each ARM platform · a9cc84d7
      Vikram Kanigiri authored
      Prior to this patch, it was assumed that on all ARM platforms the bare
      minimal security setup required is to program TrustZone protection. This
      would always be done by programming the TZC-400 which was assumed to be
      present in all ARM platforms. The weak definition of
      platform_arm_security_setup() in plat/arm/common/arm_security.c
      reflected these assumptions.
      
      In reality, each ARM platform either decides at runtime whether
      TrustZone protection needs to be programmed (e.g. FVPs) or performs
      some security setup in addition to programming TrustZone protection
      (e.g. NIC setup on Juno). As a result, the weak definition of
      plat_arm_security_setup() is always overridden.
      
      When a platform needs to program TrustZone protection and implements the
      TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is
      also possible to program TrustZone protection through other peripherals
      that include a TrustZone controller e.g. DMC-500. The programmer's
      interface is slightly different across these various peripherals.
      
      In order to satisfy the above requirements, this patch makes the
      following changes to the way security setup is done on ARM platforms.
      
      1. arm_security.c retains the definition of arm_tzc_setup() and has been
         renamed to arm_tzc400.c. This is to reflect the reliance on the
         TZC-400 peripheral to perform TrustZone programming. The new file is
         not automatically included in all platform ports through
         arm_common.mk. Each platform must include it explicitly in a platform
         specific makefile if needed.
      
         This approach enables introduction of similar library code to program
         TrustZone protection using a different peripheral. This code would be
         used by the subset of ARM platforms that implement this peripheral.
      
      2. Due to #1 above, existing platforms which implements the TZC-400 have been
         updated to include the necessary files for both BL2, BL2U and BL31
         images.
      
      Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
      a9cc84d7
    • Vikram Kanigiri's avatar
      Support for varying BOM/SCPI protocol base addresses in ARM platforms · 8e083ecd
      Vikram Kanigiri authored
      Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
      for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
      cater for future ARM platforms this is made platform specific.
      Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
      platform specific.
      
      Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
      8e083ecd
    • Vikram Kanigiri's avatar
      Add API to return memory map on ARM platforms · 65cb1c4c
      Vikram Kanigiri authored
      Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
      expect each platform to export its memory map in the `plat_arm_mmap`
      data structure. This approach does not scale well in case the memory
      map cannot be determined until runtime. To cater for this possibility,
      this patch introduces the plat_arm_get_mmap() API. It returns a
      reference to the `plat_arm_mmap` by default but can be overridden
      by a platform if required.
      
      Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74
      65cb1c4c
  8. 11 Feb, 2016 2 commits
    • Vikram Kanigiri's avatar
      Add support for SSC_VERSION register on CSS platforms · 421295a0
      Vikram Kanigiri authored
      Each ARM Compute Subsystem based platform implements a System Security
      Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
      information to identify the platform. This enables ARM Trusted Firmware
      to compile in support for multiple ARM platforms and choose one at
      runtime. This patch adds macros to enable access to this register.
      Each platform is expected to export its PART_NUMBER separately.
      
      Additionally, it also adds juno part number.
      
      Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
      421295a0
    • Vikram Kanigiri's avatar
      Re-factor definition of some macros on ARM platforms · ecf70f7b
      Vikram Kanigiri authored
      This patch moves the definition of some macros used only on
      ARM platforms from common headers to platform specific headers.
      It also forces all ARM standard platforms to have distinct
      definitions (even if they are usually the same).
       1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
           moved from `css_def.h` to `platform_def.h`.
       2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
          to platform specific header `platform_def.h` on Juno and
          renamed as `PLAT_ARM_MHU_BASE`.
       3. To cater for different sizes of BL images, new macros like
          `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
          ARM platforms need to define them for each image.
      
      Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
      ecf70f7b
  9. 05 Feb, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove non-ASCII character from comment · 8ccca412
      Antonio Nino Diaz authored
      Replaced a long dash in a comment by the ASCII character '-'. Support
      for multibyte character in the source character set is not enforced by
      the C99 standard. To maximize compatibility with C processing tools
      (e.g. compilers or static code analysis tools), they should be removed.
      
      Change-Id: Ie318e380d3b44755109f042a76ebfd2229f42ae3
      8ccca412
  10. 01 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Use tf_printf() for debug logs from xlat_tables.c · d30ac1c3
      Soby Mathew authored
      The debug prints used to debug translation table setup in xlat_tables.c
      used the `printf()` standard library function instead of the stack
      optimized `tf_printf()` API. DEBUG_XLAT_TABLE option was used to enable
      debug logs within xlat_tables.c and it configured a much larger stack
      size for the platform in case it was enabled. This patch modifies these
      debug prints within xlat_tables.c to use tf_printf() and modifies the format
      specifiers to be compatible with tf_printf(). The debug prints are now enabled
      if the VERBOSE prints are enabled in Trusted Firmware via LOG_LEVEL build
      option.
      
      The much larger stack size definition when DEBUG_XLAT_TABLE is defined
      is no longer required and the platform ports are modified to remove this
      stack size definition.
      
      Change-Id: I2f7d77ea12a04b827fa15e2adc3125b1175e4c23
      d30ac1c3
  11. 26 Jan, 2016 7 commits
  12. 21 Jan, 2016 1 commit
    • Juan Castillo's avatar
      Disable PL011 UART before configuring it · 9400b40e
      Juan Castillo authored
      The PL011 TRM (ARM DDI 0183G) specifies that the UART must be
      disabled before any of the control registers are programmed. The
      PL011 driver included in TF does not disable the UART, so the
      initialization in BL2 and BL31 is violating this requirement
      (and potentially in BL1 if the UART is enabled after reset).
      
      This patch modifies the initialization function in the PL011
      console driver to disable the UART before programming the
      control registers.
      
      Register clobber list and documentation updated.
      
      Fixes ARM-software/tf-issues#300
      
      Change-Id: I839b2d681d48b03f821ac53663a6a78e8b30a1a1
      9400b40e
  13. 20 Jan, 2016 1 commit
    • Juan Castillo's avatar
      ARM plat: add build option to unlock access to non-secure timer · 0e5dcdd2
      Juan Castillo authored
      Currently, Trusted Firmware on ARM platforms unlocks access to the
      timer frame registers that will be used by the Non-Secure world. This
      unlock operation should be done by the Non-Secure software itself,
      instead of relying on secure firmware settings.
      
      This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR'
      to unlock access to the timer frame by setting the corresponding
      bits in the CNTACR<N> register. The frame id <N> is defined by
      'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer
      access).
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#170
      
      Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
      0e5dcdd2
  14. 14 Jan, 2016 1 commit
  15. 13 Jan, 2016 1 commit
    • Sandrine Bailleux's avatar
      FVP: Compile ARM Cortex-A72 CPU support in · b13ed5ef
      Sandrine Bailleux authored
      This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP.
      This allows the same TF binaries to run on a Cortex-A72 based FVP
      without recompiling them.
      
      Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
      b13ed5ef
  16. 12 Jan, 2016 1 commit
  17. 05 Jan, 2016 1 commit
    • Juan Castillo's avatar
      Apply TBBR naming convention to the fip_create options · 8f0617ef
      Juan Castillo authored
      The fip_create tool specifies images in the command line using the
      ARM TF naming convention (--bl2, --bl31, etc), while the cert_create
      tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double
      convention is confusing and should be aligned.
      
      This patch updates the fip_create command line options to follow the
      TBBR naming convention. Usage examples in the User Guide have been
      also updated.
      
      NOTE: users that build the FIP by calling the fip_create tool directly
      from the command line must update the command line options in their
      scripts. Users that build the FIP by invoking the main ARM TF Makefile
      should not notice any difference.
      
      Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
      8f0617ef
  18. 21 Dec, 2015 2 commits
  19. 15 Dec, 2015 1 commit
    • 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
  20. 14 Dec, 2015 3 commits
    • 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
    • Juan Castillo's avatar
      Replace all SCP FW (BL0, BL3-0) references · f59821d5
      Juan Castillo authored
      This patch replaces all references to the SCP Firmware (BL0, BL30,
      BL3-0, bl30) with the image terminology detailed in the TF wiki
      (https://github.com/ARM-software/arm-trusted-firmware/wiki):
      
          BL0          -->  SCP_BL1
          BL30, BL3-0  -->  SCP_BL2
          bl30         -->  scp_bl2
      
      This change affects code, documentation, build system, tools and
      platform ports that load SCP firmware. ARM plaforms have been
      updated to the new porting API.
      
      IMPORTANT: build option to specify the SCP FW image has changed:
      
          BL30 --> SCP_BL2
      
      IMPORTANT: This patch breaks compatibility for platforms that use BL2
      to load SCP firmware. Affected platforms must be updated as follows:
      
          BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
          BL30_BASE --> SCP_BL2_BASE
          bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
          bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
      
      Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
      f59821d5
    • Juan Castillo's avatar
      TBB: apply TBBR naming convention to certificates and extensions · 516beb58
      Juan Castillo authored
      This patch applies the TBBR naming convention to the certificates
      and the corresponding extensions defined by the CoT:
      
          * Certificate UUID names
          * Certificate identifier names
          * OID names
      
      Changes apply to:
      
          * Generic code (variables and defines)
          * The default certificate identifiers provided in the generic
            code
          * Build system
          * ARM platforms port
          * cert_create tool internal definitions
          * fip_create and cert_create tools command line options
          * Documentation
      
      IMPORTANT: this change breaks the compatibility with platforms
      that use TBBR. The platform will need to adapt the identifiers
      and OIDs to the TBBR naming convention introduced by this patch:
      
      Certificate UUIDs:
      
          UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT
          UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT
          UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT
          UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT
          UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT
      
      Certificate identifiers:
      
          BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID
          BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID
          BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID
          BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID
          BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID
          BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID
          BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID
          BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID
          BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID
      
      OIDs:
      
          TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID
          NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID
          BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID
          TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID
          NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID
          BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID
          BL30_HASH_OID --> SCP_FW_HASH_OID
          BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID
          BL31_HASH_OID --> SOC_AP_FW_HASH_OID
          BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID
          BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID
          BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID
          BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID
          BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID
          SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID
          NS_BL2U_HASH_OID --> FWU_HASH_OID
      
      Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
      516beb58
  21. 09 Dec, 2015 5 commits
    • Yatharth Kochar's avatar
      FWU: Add support for `fwu_fip` target · 0191262d
      Yatharth Kochar authored
      Firmware update feature needs a new FIP called `fwu_fip.bin` that
      includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images
      along with the FWU_CERT certificate in order for NS_BL1U to load
      the images and help the Firmware update process to complete.
      
      This patch adds the capability to support the new target `fwu_fip`
      which includes above mentioned FWU images in the make files.
      
      The new target of `fwu_fip` and its dependencies are included for
      compilation only when `TRUSTED_BOARD_BOOT` is defined.
      
      Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc
      0191262d
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL2U for ARM platforms · dcda29f6
      Yatharth Kochar authored
      This patch adds support for Firmware update in BL2U for ARM
      platforms such that TZC initialization is performed on all
      ARM platforms and (optionally) transfer of SCP_BL2U image on
      ARM CSS platforms.
      
      BL2U specific functions are added to handle early_platform and
      plat_arch setup. The MMU is configured to map in the BL2U
      code/data area and other required memory.
      
      Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
      dcda29f6
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL1 for ARM platforms · 436223de
      Yatharth Kochar authored
      This patch adds Firmware Update support for ARM platforms.
      
      New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
      platform specific Firmware update code.
      
      BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
      authenticating NS_BL2U image(For both FVP and JUNO platform).
      
      Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
      436223de
    • 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