1. 09 Dec, 2015 9 commits
    • danh-arm's avatar
      Merge pull request #458 from soby-mathew/sm/rem_tzc_base_assert · 7e473eae
      danh-arm authored
      Remove the assert for TZC base during initialization
      7e473eae
    • danh-arm's avatar
      Merge pull request #457 from soby-mathew/sm/fix_fpregs_restore · c7488966
      danh-arm authored
      Fix issue in Floating point register restore
      c7488966
    • danh-arm's avatar
      Merge pull request #456 from soby-mathew/sm/gicv3-tsp-plat-changes-v2 · 4ca473db
      danh-arm authored
      Modify TSP and ARM standard platforms for new GIC drivers v2
      4ca473db
    • danh-arm's avatar
      Merge pull request #455 from jcastillo-arm/jc/fvp_delay_timer · 8d297cc9
      danh-arm authored
      Fix SP804 delay timer on FVP
      8d297cc9
    • Soby Mathew's avatar
      Fix issue in Floating point register restore · 817ac8d1
      Soby Mathew authored
      The `fpregs_context_restore()` function used to restore the floating point
      regsiter context had a typo error wherein it was doing `str` instead of
      `ldr` for a register. This issue remained undetected becuase none of the ARM
      Standard development platforms save and restore the floating point register
      context when a context switch is done. This patch corrects the issue.
      
      Change-Id: Id178e0ba254a5e0a4a844f54b39d71dc34e0f6ea
      817ac8d1
    • Soby Mathew's avatar
      TSP: Allow preemption of synchronous S-EL1 interrupt handling · 63b8440f
      Soby Mathew authored
      Earlier the TSP only ever expected to be preempted during Standard SMC
      processing. If a S-EL1 interrupt triggered while in the normal world, it
      will routed to S-EL1 `synchronously` for handling. The `synchronous` S-EL1
      interrupt handler `tsp_sel1_intr_entry` used to panic if this S-EL1 interrupt
      was preempted by another higher priority pending interrupt which should be
      handled in EL3 e.g. Group0 interrupt in GICv3.
      
      With this patch, the `tsp_sel1_intr_entry` now expects `TSP_PREEMPTED` as the
      return code from the `tsp_common_int_handler` in addition to 0 (interrupt
      successfully handled) and in both cases it issues an SMC with id
      `TSP_HANDLED_S_EL1_INTR`. The TSPD switches the context and returns back
      to normal world. In case a higher priority EL3 interrupt was pending, the
      execution will be routed to EL3 where interrupt will be handled. On return
      back to normal world, the pending S-EL1 interrupt which was preempted will
      get routed to S-EL1 to be handled `synchronously` via `tsp_sel1_intr_entry`.
      
      Change-Id: I2087c7fedb37746fbd9200cdda9b6dba93e16201
      63b8440f
    • Soby Mathew's avatar
      Enable support for EL3 interrupt in IMF · 4e0e0f44
      Soby Mathew authored
      This patch enables support for EL3 interrupts in the Interrupt Management
      Framework (IMF) of ARM Trusted Firmware. Please note that although the
      registration of the EL3 interrupt type is now supported, it has not been
      tested on any of the ARM Standard platforms.
      
      Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1
      4e0e0f44
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
    • Soby Mathew's avatar
      Prepare platforms to use refactored ARM GIC drivers · f14d1886
      Soby Mathew authored
      This patch adds platform helpers for the new GICv2 and GICv3 drivers in
      plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
      file in their build according to the GIC driver to be used. The existing
      plat_gic.c is only meant for the legacy GIC driver.
      
      In the case of ARM platforms, the major changes are as follows:
      
      1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
         interface register values has been modified to detect the type of CPU
         interface being used (System register or memory mappped interface) before
         using the right interface to print the registers.
      
      2. The power management helper function that is called after a core is powered
         up has been further refactored. This is to highlight that the per-cpu
         distributor interface should be initialised only when the core was originally
         powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
         was used.
      
      3. In the case of CSS platforms, the system power domain restore helper
         `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
         handler as the system power domain is always expected to be initialized when
         the `on_finish` handler is invoked.
      
      Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
      f14d1886
  2. 08 Dec, 2015 4 commits
  3. 04 Dec, 2015 5 commits
    • Varun Wadekar's avatar
      Tegra: remove support for legacy platform APIs · 71cb26ea
      Varun Wadekar authored
      
      
      This patch modifies the Tegra port to support the new platform
      APIs so that we can disable the compat layer. This includes
      modifications to the power management and platform topology code.
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      71cb26ea
    • Soby Mathew's avatar
      Enable use of FIQs and IRQs as TSP interrupts · 02446137
      Soby Mathew authored
      On a GICv2 system, interrupts that should be handled in the secure world are
      typically signalled as FIQs. On a GICv3 system, these interrupts are signalled
      as IRQs instead. The mechanism for handling both types of interrupts is the same
      in both cases. This patch enables the TSP to run on a GICv3 system by:
      
      1. adding support for handling IRQs in the exception handling code.
      2. removing use of "fiq" in the names of data structures, macros and functions.
      
      The build option TSPD_ROUTE_IRQ_TO_EL3 is deprecated and is replaced with a
      new build flag TSP_NS_INTR_ASYNC_PREEMPT. For compatibility reasons, if the
      former build flag is defined, it will be used to define the value for the
      new build flag. The documentation is also updated accordingly.
      
      Change-Id: I1807d371f41c3656322dd259340a57649833065e
      02446137
    • Soby Mathew's avatar
      Unify interrupt return paths from TSP into the TSPD · 404dba53
      Soby Mathew authored
      The TSP is expected to pass control back to EL3 if it gets preempted due to
      an interrupt while handling a Standard SMC in the following scenarios:
      
      1. An FIQ preempts Standard SMC execution and that FIQ is not a TSP Secure
         timer interrupt or is preempted by a higher priority interrupt by the time
         the TSP acknowledges it. In this case, the TSP issues an SMC with the ID
         as `TSP_EL3_FIQ`. Currently this case is never expected to happen as only
         the TSP Secure Timer is expected to generate FIQ.
      
      2. An IRQ preempts Standard SMC execution and in this case the TSP issues
         an SMC with the ID as `TSP_PREEMPTED`.
      
      In both the cases, the TSPD hands control back to the normal world and returns
      returns an error code to the normal world to indicate that the standard SMC it
      had issued has been preempted but not completed.
      
      This patch unifies the handling of these two cases in the TSPD and ensures that
      the TSP only uses TSP_PREEMPTED instead of separate SMC IDs. Also instead of 2
      separate error codes, SMC_PREEMPTED and TSP_EL3_FIQ, only SMC_PREEMPTED is
      returned as error code back to the normal world.
      
      Background information: On a GICv3 system, when the secure world has affinity
      routing enabled, in 2. an FIQ will preempt TSP execution instead of an IRQ. The
      FIQ could be a result of a Group 0 or a Group 1 NS interrupt. In both case, the
      TSPD passes control back to the normal world upon receipt of the TSP_PREEMPTED
      SMC. A Group 0 interrupt will immediately preempt execution to EL3 where it
      will be handled. This allows for unified interrupt handling in TSP for both
      GICv3 and GICv2 systems.
      
      Change-Id: I9895344db74b188021e3f6a694701ad272fb40d4
      404dba53
    • Soby Mathew's avatar
      Rename GICv3 interrupt group macros · 03ffb6bd
      Soby Mathew authored
      This patch renames the GICv3 interrupt group macros from
      INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0,
      INTR_GROUP1S and INTR_GROUP1NS respectively.
      
      Change-Id: I40c66f589ce6234fa42205adcd91f7d6ad8f33d4
      03ffb6bd
    • Juan Castillo's avatar
      Fix SP804 delay timer on FVP · 540a5ba8
      Juan Castillo authored
      This patch fixes several issues with the SP804 delay timer on FVP:
      
      * By default, the SP804 dual timer on FVP runs at 32 KHz. In order
        to run the timer at 35 MHz (as specified in the FVP user manual)
        the Overwrite bit in the SP810 control register must be set.
      
      * The CLKMULT and CLKDIV definitions are mixed up:
      
            delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)
      
        From the delay function:
      
            delta_us = (delta * ops->clk_mult) / ops->clk_div;
      
        Matching both expressions:
      
            1 / f(MHz) = ops->clk_mult / ops->clk_div
      
        And consequently:
      
            f(MHz) = ops->clk_div / ops->clk_mult
      
        Which, for a 35 MHz timer, translates to:
      
            ops->clk_div = 35
            ops->clk_mult = 1
      
      * The comment in the delay timer header file has been corrected:
        The ratio of the multiplier and the divider is the clock period
        in microseconds, not the frequency.
      
      Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
      540a5ba8
  4. 02 Dec, 2015 5 commits
    • danh-arm's avatar
      Merge pull request #446 from vikramkanigiri/vk/tzc-400 · f3974ea5
      danh-arm authored
      Fix TZC-400 peripheral detection
      f3974ea5
    • danh-arm's avatar
      Merge pull request #449 from jcastillo-arm/jc/tbb_oid · 3138dac6
      danh-arm authored
      TBB: add ARM OIDs
      3138dac6
    • danh-arm's avatar
      Merge pull request #444 from jcastillo-arm/jc/tbb_wdog · 38d8fddf
      danh-arm authored
      Jc/tbb wdog
      38d8fddf
    • Juan Castillo's avatar
      TBB: add Trusted Watchdog support on ARM platforms · 7b4c1405
      Juan Castillo authored
      This patch adds watchdog support on ARM platforms (FVP and Juno).
      A secure instance of SP805 is used as Trusted Watchdog. It is
      entirely managed in BL1, being enabled in the early platform setup
      hook and disabled in the exit hook. By default, the watchdog is
      enabled in every build (even when TBB is disabled).
      
      A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
      has been introduced to allow the user to disable the watchdog at
      build time. This feature may be used for testing or debugging
      purposes.
      
      Specific error handlers for Juno and FVP are also provided in this
      patch. These handlers will be called after an image load or
      authentication error. On FVP, the Table of Contents (ToC) in the FIP
      is erased. On Juno, the corresponding error code is stored in the
      V2M Non-Volatile flags register. In both cases, the CPU spins until
      a watchdog reset is generated after 256 seconds (as specified in
      the TBBR document).
      
      Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
      7b4c1405
    • Juan Castillo's avatar
      TBB: add ARM OIDs · bf6863c6
      Juan Castillo authored
      This patch adds ARM specific OIDs which will be used to extract
      the extension data from the certificates. These OIDs are arranged
      as a subtree whose root node has been specifically allocated for
      ARM Ltd.
      
          { iso(1) identified-organization(3) dod(6) internet(1)
            private(4) enterprise(1) 4128 }
      
      Change-Id: Ice20b3c8a31ddefe9102f3bd42f7429986f3ac34
      bf6863c6
  5. 01 Dec, 2015 3 commits
  6. 27 Nov, 2015 3 commits
    • Vikram Kanigiri's avatar
      Fix TZC-400 peripheral detection · 609ebce4
      Vikram Kanigiri authored
      The TZC-400 driver implementation incorrectly uses the component
      ID registers to detect the TZC-400 peripheral. As all ARM
      peripherals share the same component ID, it doesn't allow to
      uniquely identify the TZC-400 peripheral. This patch fixes the
      TZC-400 driver by relying on the `part_number_0` and
      `part_number_1` fields in the `PID` registers instead.
      The `tzc_read_component_id` function has been replaced by
      `tzc_read_peripheral_id`, which reads the 'part_number' values
      and compares them with the TZC-400 peripheral ID.
      
      Also, it adds a debug assertion to detect when the TZC driver
      initialisation function is called multiple times.
      
      Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6
      609ebce4
    • Juan Castillo's avatar
      Add a simple ARM SP805 watchdog driver · 38041973
      Juan Castillo authored
      Based on SP805 Programmer's model (ARM DDI 0270B). This driver
      provides three public APIs:
      
          void sp805_start(uintptr_t base, unsigned long ticks);
          void sp805_stop(uintptr_t base);
          void sp805_refresh(uintptr_t base, unsigned long ticks);
      
      Upon start, the watchdog starts counting down from the number of
      ticks specified. When the count reaches 0 an interrupt is triggered.
      The watchdog restarts counting down from the number of ticks
      specified. If the count reaches 0 again, the system is reset. A
      mechanism to handle the interrupt has not been implemented. Instead,
      the API to refresh the watchdog should be used instead to prevent a
      system reset.
      
      Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab
      38041973
    • Juan Castillo's avatar
      Add basic NOR flash driver for ARM platforms · 9784dbda
      Juan Castillo authored
      FVP and Juno platforms include a NOR flash memory to store and
      load the FIP, the kernel or a ramdisk. This NOR flash is arranged
      as 2 x 16 bit flash devices and can be programmed using CFI
      standard commands.
      
      This patch provides a basic API to write single 32 bit words of
      data into the NOR flash. Functions to lock/unlock blocks against
      erase or write operations are also provided.
      
      Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
      9784dbda
  7. 26 Nov, 2015 11 commits
    • Sandrine Bailleux's avatar
      User Guide: Remove reference to porting guide · dc2d4038
      Sandrine Bailleux authored
      The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
      the platform porting layer are simple enough to be described in the
      User Guide directly. This patch removes the reference to the Porting
      Guide.
      
      Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d
      dc2d4038
    • 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
      Document the EL3 payload support · aba2f1e0
      Sandrine Bailleux authored
       - Document the new build option EL3_PAYLOAD_BASE
      
       - Document the EL3 payload boot flow
      
       - Document the FVP model parameters to boot an EL3 payload
      
      Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37
      aba2f1e0
    • Sandrine Bailleux's avatar
      FVP: Do not power off secondary CPUs when booting an EL3 payload · cdf14088
      Sandrine Bailleux authored
      Normally, in the FVP port, secondary CPUs are immediately powered
      down if they are powered on at reset. However, when booting an EL3
      payload, we need to keep them powered on as the requirement is for
      all CPUs to enter the EL3 payload image. This patch puts them in a
      holding pen instead of powering them off.
      
      Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
      cdf14088
    • Sandrine Bailleux's avatar
      CSS: Put secondary CPUs in a pen when booting an EL3 payload · 2bc42067
      Sandrine Bailleux authored
      By default, only the primary CPU is powered on by SCP on CSS
      platforms. Secondary CPUs are then powered on later using PSCI
      calls.
      
      However, it is possible to power on more than one CPU at boot time
      using platform specific settings. In this case, several CPUs will
      enter the Trusted Firmware and execute the cold boot path code.
      This is currently not supported and secondary CPUs will panic.
      
      This patch preserves this behaviour in the normal boot flow.
      However, when booting an EL3 payload, secondary CPUs are now held in
      a pen until their mailbox is populated, at which point they jump to
      this address. Note that, since all CPUs share the same mailbox, they
      will all be released from their holding pen at the same time and the
      EL3 payload is responsible to arbitrate execution between CPUs if
      required.
      
      Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9
      2bc42067
    • Sandrine Bailleux's avatar
      CSS: Enable booting of EL3 payloads · 4c117f6c
      Sandrine Bailleux authored
      This patch adds support for booting EL3 payloads on CSS platforms,
      for example Juno. In this scenario, the Trusted Firmware follows
      its normal boot flow up to the point where it would normally pass
      control to the BL31 image. At this point, it jumps to the EL3
      payload entry point address instead.
      
      Before handing over to the EL3 payload, the data SCP writes for AP
      at the beginning of the Trusted SRAM is restored, i.e. we zero the
      first 128 bytes and restore the SCP Boot configuration. The latter
      is saved before transferring the BL30 image to SCP and is restored
      just after the transfer (in BL2). The goal is to make it appear that
      the EL3 payload is the first piece of software to run on the target.
      
      The BL31 entrypoint info structure is updated to make the primary
      CPU jump to the EL3 payload instead of the BL31 image.
      
      The mailbox is populated with the EL3 payload entrypoint address,
      which releases the secondary CPUs out of their holding pen (if the
      SCP has powered them on). The arm_program_trusted_mailbox() function
      has been exported for this purpose.
      
      The TZC-400 configuration in BL2 is simplified: it grants secure
      access only to the whole DRAM. Other security initialization is
      unchanged.
      
      This alternative boot flow is disabled by default. A new build option
      EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
      payload's entry point address. The build system has been modified
      such that BL31 and BL33 are not compiled and/or not put in the FIP in
      this case, as those images are not used in this boot flow.
      
      Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
      4c117f6c
    • 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
    • Soby Mathew's avatar
      Remove the IMF_READ_INTERRUPT_ID build option · 54718418
      Soby Mathew authored
      The IMF_READ_INTERRUPT_ID build option enables a feature where the interrupt
      ID of the highest priority pending interrupt is passed as a parameter to the
      interrupt handler registered for that type of interrupt. This additional read
      of highest pending interrupt id from GIC is problematic as it is possible that
      the original interrupt may get deasserted and another interrupt of different
      type maybe become the highest pending interrupt. Hence it is safer to prevent
      such behaviour by removing the IMF_READ_INTERRUPT_ID build option.
      
      The `id` parameter of the interrupt handler `interrupt_type_handler_t` is
      now made a reserved parameter with this patch. It will always contain
      INTR_ID_UNAVAILABLE.
      
      Fixes ARM-software/tf-issues#307
      
      Change-Id: I2173aae1dd37edad7ba6bdfb1a99868635fa34de
      54718418
    • Achin Gupta's avatar
      Merge pull request #439 from soby-mathew/sm/new-gic-driver · b39908af
      Achin Gupta authored
      Introduce new GICv3 and GICv2 drivers
      b39908af
    • Soby Mathew's avatar
      Deprecate the GIC Legacy driver. · 23a45010
      Soby Mathew authored
      This patch deprecates the legacy ARM GIC driver and related header files
      (arm_gic.h, gic_v2.h, gic_v3.h). For GICv2 systems, platform ports should
      use the GICv2 driver in include/drivers/arm/gicv2.h and for GICv3 systems,
      platform ports should use the GICv3 driver in include/drivers/arm/gicv3.h
      
      NOTE: The ARM Legacy GIC drivers have been deprecated with this patch.
      Platform ports are encouraged to migrate to the new GIC drivers.
      
      Change-Id: Ic0460ef0427b54a6aac476279a7f29b81943e942
      23a45010