1. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c
    • Dan Handley's avatar
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  2. 16 Mar, 2015 1 commit
  3. 28 Jan, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add a platform specific function to validate the ROTPK · 6eadf762
      Juan Castillo authored
      This patch adds the function plat_match_rotpk() to the platform
      porting layer to provide a Root Of Trust Public key (ROTPK)
      verification mechanism. This function is called during the
      Trusted Board Boot process and receives a supposed valid copy
      of the ROTPK as a parameter, usually obtained from an external
      source (for instance, a certificate). It returns 0 (success) if
      that key matches the actual ROTPK stored in the system or any
      other value otherwise.
      
      The mechanism to access the actual ROTPK stored in the system
      is platform specific and should be implemented as part of this
      function. The format of the ROTPK is also platform specific
      (to save memory, some platforms might store a hash of the key
      instead of the whole key).
      
      TRUSTED_BOARD_BOOT build option has been added to allow the user
      to enable the Trusted Board Boot features. The implementation of
      the plat_match_rotpk() funtion is mandatory when Trusted Board
      Boot is enabled.
      
      For development purposes, FVP and Juno ports provide a dummy
      function that returns always success (valid key). A safe trusted
      boot implementation should provide a proper matching function.
      
      Documentation updated accordingly.
      
      Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
      6eadf762
  4. 26 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: Allow BL3-2 to sit in the secure region of DRAM · 513dd3a0
      Juan Castillo authored
      This patch allows the secure payload (BL3-2) to be loaded in the
      DRAM region secured by the TrustZone controller (top 16 MB of DRAM1).
      
      The location of BL3-2 can be selected at build time by setting the
      build flag FVP_TSP_RAM_LOCATION to one of the following options:
      
        - 'tsram' : Trusted SRAM (this is the default option)
        - 'tdram' : Trusted DRAM
        - 'dram'  : Secure region in DRAM1 (top 16MB configured by the
                    TrustZone controller)
      
      The number of MMU tables in BL3-2 depends on its location in
      memory: 3 in case it is loaded in DRAM, 2 otherwise.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#212
      
      Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
      513dd3a0
  5. 22 Oct, 2014 1 commit
    • Juan Castillo's avatar
      FVP: keep shared data in Trusted SRAM · 20d51cad
      Juan Castillo authored
      This patch deprecates the build option to relocate the shared data
      into Trusted DRAM in FVP. After this change, shared data is always
      located at the base of Trusted SRAM. This reduces the complexity
      of the memory map and the number of combinations in the build
      options.
      
      Fixes ARM-software/tf-issues#257
      
      Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
      20d51cad
  6. 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
  7. 14 Aug, 2014 2 commits
    • Dan Handley's avatar
      Move IO storage source to drivers directory · 935db693
      Dan Handley authored
      Move the remaining IO storage source file (io_storage.c) from the
      lib to the drivers directory. This requires that platform ports
      explicitly add this file to the list of source files.
      
      Also move the IO header files to a new sub-directory, include/io.
      
      Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
      935db693
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  8. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  9. 28 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Introduce asm console functions in TF · fce5f750
      Soby Mathew authored
      This patch replaces the pl011 console family of functions
      with their equivalents defined in assembly. The baud rate is
      defined by the PL011_BAUDRATE macro and IBRD and FBRD values
      for pl011 are computed statically. This patch will enable
      us to invoke the console functions without the C Runtime Stack.
      
      Change-Id: Ic3f7b7370ded38bf9020bf746b362081b76642c7
      fce5f750
  10. 17 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      Define ARM_GIC_ARCH default value for all platforms · 2b98e789
      Sandrine Bailleux authored
      The ARM_GIC_ARCH build option was supposed to default to 2 on all
      platforms. However, the default value was set in the FVP makefile
      so for all other platforms it wasn't even defined.
      
      This patch moves the default value to the main Makefile. The platform
      port can then override it if needed.
      
      Change-Id: I8e2da1cce7ffa3ed18814bbdcbcf2578101f18a6
      2b98e789
  11. 09 Jul, 2014 1 commit
    • Dan Handley's avatar
      Refactor fvp gic code to be a generic driver · 1e8c5c4f
      Dan Handley authored
      Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
      GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
      specific inputs in the arm_gic_setup() function so that the driver
      has no explicit dependency on platform code.
      
      Provide weak implementations of the platform interrupt controller
      API in a new file, plat/common/plat_gic.c. These simply call through
      to the ARM GIC driver.
      
      Move the only remaining FVP GIC function, fvp_gic_init() to
      plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c
      
      Fixes ARM-software/tf-issues#182
      
      Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
      1e8c5c4f
  12. 24 Jun, 2014 2 commits
    • Andrew Thoelke's avatar
      Inline the mmio accessor functions · 5e113753
      Andrew Thoelke authored
      Making the simple mmio_read_*() and mmio_write_*() functions inline
      saves 360 bytes of code in FVP release build.
      
      Fixes ARM-software/tf-issues#210
      
      Change-Id: I65134f9069f3b2d8821d882daaa5fdfe16355e2f
      5e113753
    • Vikram Kanigiri's avatar
      Simplify entry point information generation code on FVP · 03396c43
      Vikram Kanigiri authored
      This patch reworks FVP specific code responsible for determining
      the entry point information for BL3-2 and BL3-3 stages when BL3-1
      is configured as the reset handler.
      
      Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec
      03396c43
  13. 10 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Make system register functions inline assembly · 5c3272a7
      Andrew Thoelke authored
      Replace the current out-of-line assembler implementations of
      the system register and system instruction operations with
      inline assembler.
      
      This enables better compiler optimisation and code generation
      when accessing system registers.
      
      Fixes ARM-software/tf-issues#91
      
      Change-Id: I149af3a94e1e5e5140a3e44b9abfc37ba2324476
      5c3272a7
  14. 23 May, 2014 2 commits
    • Dan Handley's avatar
      Add enable mmu platform porting interfaces · dff8e47a
      Dan Handley authored
      Previously, the enable_mmu_elX() functions were implicitly part of
      the platform porting layer since they were included by generic
      code. These functions have been placed behind 2 new platform
      functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu().
      These are weakly defined so that they can be optionally overridden
      by platform ports.
      
      Also, the enable_mmu_elX() functions have been moved to
      lib/aarch64/xlat_tables.c for optional re-use by platform ports.
      These functions are tightly coupled with the translation table
      initialization code.
      
      Fixes ARM-software/tf-issues#152
      
      Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
      dff8e47a
    • Dan Handley's avatar
      Rename FVP specific files and functions · 17a387ad
      Dan Handley authored
      FVP specific files and functions containing the word "plat" have been
      renamed to use the word "fvp" to distinguish them from the common
      platform functionality and porting functions.
      
      Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
      17a387ad
  15. 22 May, 2014 3 commits
    • Achin Gupta's avatar
      Introduce interrupt registration framework in BL3-1 · e1333f75
      Achin Gupta authored
      This patch introduces a framework for registering interrupts routed to
      EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and
      FIQ bits and the security state an interrupt is generated in. The
      framework recognizes three type of interrupts depending upon which
      exception level and security state they should be handled in
      i.e. Secure EL1 interrupts, Non-secure interrupts and EL3
      interrupts. It provides an API and macros that allow a runtime service
      to register an handler for a type of interrupt and specify the routing
      model. The framework validates the routing model and uses the context
      management framework to ensure that it is applied to the SCR_EL3 prior
      to entry into the target security state. It saves the handler in
      internal data structures. An API is provided to retrieve the handler
      when an interrupt of a particular type is asserted. Registration is
      expected to be done once by the primary CPU. The same handler and
      routing model is used for all CPUs.
      
      Support for EL3 interrupts will be added to the framework in the
      future. A makefile flag has been added to allow the FVP port choose
      between ARM GIC v2 and v3 support in EL3. The latter version is
      currently unsupported.
      
      A framework for handling interrupts in BL3-1 will be introduced in
      subsequent patches. The default routing model in the absence of any
      handlers expects no interrupts to be routed to EL3.
      
      Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
      e1333f75
    • Sandrine Bailleux's avatar
      fvp: Move TSP from Secure DRAM to Secure SRAM · 53514b29
      Sandrine Bailleux authored
      The TSP used to execute from secure DRAM on the FVPs because there was
      not enough space in Trusted SRAM to fit it in. Thanks to recent RAM
      usage enhancements being implemented, we have made enough savings for
      the TSP to execute in SRAM.
      
      However, there is no contiguous free chunk of SRAM big enough to hold
      the TSP. Therefore, the different bootloader images need to be moved
      around to reduce memory fragmentation. This patch keeps the overall
      memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and
      BL3-1 in between) but moves the base addresses of all the bootloader
      images in such a way that:
       - memory fragmentation is reduced enough to fit BL3-2 in;
       - new base addresses are suitable for release builds as well as debug
         ones;
       - each image has a few extra kilobytes for future growth.
         BL3-1 and BL3-2 are the images which received the biggest slice
         of the cake since they will most probably grow the most.
      
      A few useful numbers for reference (valid at the time of this patch):
              |-----------------------|-------------------------------
              |  image size (debug)   |  extra space for the future
      --------|-----------------------|-------------------------------
      BL1 R/W |         20 KB         |            4 KB
      BL2     |         44 KB         |            4 KB
      BL3-1   |        108 KB         |           12 KB
      BL3-2   |         56 KB         |            8 KB
      --------|-----------------------|-------------------------------
      Total   |        228 KB         |           28 KB       = 256 KB
      --------|-----------------------|-------------------------------
      
      Although on FVPs the TSP now executes from Trusted SRAM by default,
      this patch keeps the option to execute it from Trusted DRAM. This is
      controlled by the build configuration 'TSP_RAM_LOCATION'.
      
      Fixes ARM-Software/tf-issues#81
      
      Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
      53514b29
    • Vikram Kanigiri's avatar
      Add support for BL3-1 as a reset vector · dbad1bac
      Vikram Kanigiri authored
      This change adds optional reset vector support to BL3-1
      which means BL3-1 entry point can detect cold/warm boot,
      initialise primary cpu, set up cci and mail box.
      
      When using BL3-1 as a reset vector it is assumed that
      the BL3-1 platform code can determine the location of
      the BL3-2 images, or load them as there are no parameters
      that can be passed to BL3-1 at reset.
      
      It also fixes the incorrect initialisation of mailbox
      registers on the FVP platform
      
      This feature can be enabled by building the code with
      make variable RESET_TO_BL31 set as 1
      
      Fixes ARM-software/TF-issues#133
      Fixes ARM-software/TF-issues#20
      
      Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
      dbad1bac
  16. 16 May, 2014 1 commit
    • Soby Mathew's avatar
      Rework BL3-1 unhandled exception handling and reporting · a43d431b
      Soby Mathew authored
      This patch implements the register reporting when unhandled exceptions are
      taken in BL3-1. Unhandled exceptions will result in a dump of registers
      to the console, before halting execution by that CPU. The Crash Stack,
      previously called the Exception Stack, is used for this activity.
      This stack is used to preserve the CPU context and runtime stack
      contents for debugging and analysis.
      
      This also introduces the per_cpu_ptr_cache, referenced by tpidr_el3,
      to provide easy access to some of BL3-1 per-cpu data structures.
      Initially, this is used to provide a pointer to the Crash stack.
      
      panic() now prints the the error file and line number in Debug mode
      and prints the PC value in release mode.
      
      The Exception Stack is renamed to Crash Stack with this patch.
      The original intention of exception stack is no longer valid
      since we intend to support several valid exceptions like IRQ
      and FIQ in the trusted firmware context. This stack is now
      utilized for dumping and reporting the system state when a
      crash happens and hence the rename.
      
      Fixes ARM-software/tf-issues#79 Improve reporting of unhandled exception
      
      Change-Id: I260791dc05536b78547412d147193cdccae7811a
      a43d431b
  17. 06 May, 2014 3 commits
    • Dan Handley's avatar
      Remove vpath usage in makefiles · bee82417
      Dan Handley authored
      Remove all usage of the vpath keyword in makefiles as it was prone
      to mistakes. Specify the relative paths to source files instead.
      
      Also reorder source files in makefiles alphabetically.
      
      Fixes ARM-software/tf-issues#121
      
      Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
      bee82417
    • Dan Handley's avatar
      Move FVP power driver to FVP platform · e8246c07
      Dan Handley authored
      Move the FVP power driver to a directory under the FVP platform
      port as this is not a generically usable driver.
      
      Change-Id: Ibc78bd88752eb3e3964336741488349ac345f4f0
      e8246c07
    • Dan Handley's avatar
      Move include and source files to logical locations · 4ecca339
      Dan Handley authored
      Move almost all system include files to a logical sub-directory
      under ./include. The only remaining system include directories
      not under ./include are specific to the platform. Move the
      corresponding source files to match the include directory
      structure.
      
      Also remove pm.h as it is no longer used.
      
      Change-Id: Ie5ea6368ec5fad459f3e8a802ad129135527f0b3
      4ecca339
  18. 24 Apr, 2014 1 commit
    • Harry Liebel's avatar
      Enable secure memory support for FVPs · f2199d95
      Harry Liebel authored
      - Use the TrustZone controller on Base FVP to program DRAM access
        permissions. By default no access to DRAM is allowed if
        'secure memory' is enabled on the Base FVP.
      - The Foundation FVP does not have a TrustZone controller but instead
        has fixed access permissions.
      - Update FDTs for Linux to use timers at the correct security level.
      - Starting the FVPs with 'secure memory' disabled is also supported.
      
      Limitations:
      Virtio currently uses a reserved NSAID. This will be corrected in
      future FVP releases.
      
      Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
      f2199d95
  19. 15 Apr, 2014 1 commit
    • Andrew Thoelke's avatar
      Allocate single stacks for BL1 and BL2 · 2bf28e62
      Andrew Thoelke authored
      The BL images share common stack management code which provides
      one coherent and one cacheable stack for every CPU. BL1 and BL2
      just execute on the primary CPU during boot and do not require
      the additional CPU stacks. This patch provides separate stack
      support code for UP and MP images, substantially reducing the
      RAM usage for BL1 and BL2 for the FVP platform.
      
      This patch also provides macros for declaring stacks and
      calculating stack base addresses to improve consistency where
      this has to be done in the firmware.
      
      The stack allocation source files are now included via
      platform.mk rather than the common BLx makefiles. This allows
      each platform to select the appropriate MP/UP stack support
      for each BL image.
      
      Each platform makefile must be updated when including this
      commit.
      
      Fixes ARM-software/tf-issues#76
      
      Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
      2bf28e62
  20. 14 Apr, 2014 1 commit
    • Dan Handley's avatar
      Move console.c to pl011 specific driver location · d72f6e31
      Dan Handley authored
      Rename drivers/console/console.c to
      drivers/arm/peripherals/pl011/pl011_console.c. This makes it clear
      that this is a pl011 specific console implementation.
      
      Fixes ARM-software/tf-issues#129
      
      Change-Id: Ie2f8109602134c5b86993e32452c70734c45a3ed
      d72f6e31
  21. 26 Mar, 2014 1 commit
    • Soby Mathew's avatar
      Move console functions out of pl011.c · c1df3be7
      Soby Mathew authored
      This commit isolates the accessor functions in pl011.c and builds
      a wrapper layer for console functions.
      
      This also modifies the console driver to use the pl011 FIFO.
      
      Fixes ARM-software/tf-issues#63
      
      Change-Id: I3b402171cd14a927831bf5e5d4bb310b6da0e9a8
      c1df3be7
  22. 05 Mar, 2014 2 commits
    • Jon Medhurst's avatar
      fvp: Make use of the generic MMU translation table setup code · 38aa76a8
      Jon Medhurst authored
      
      
      Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      38aa76a8
    • Jon Medhurst's avatar
      Update Makefiles to get proper dependency checking working. · 6d55d109
      Jon Medhurst authored
      
      
      This change requires all platforms to now specify a list of source files
      rather than object files.
      
      New source files should preferably be specified by using the path as
      well and we should add this in the future for all files so we can remove
      use of vpath. This is desirable because vpath hides issues like the fact
      that BL2 currently pulls in a BL1 file bl1/aarch64/early_exceptions.S
      and if in the future we added bl2/aarch64/early_exceptions.S then it's
      likely only one of the two version would be used for both bootloaders.
      
      This change also removes the 'dump' build target and simply gets
      bootloaders to always generate a dump file. At the same time the -x
      option is added so the section headers and symbols table are listed.
      
      Fixes ARM-software/tf-issues#11
      
      Change-Id: Ie38f7be76fed95756c8576cf3f3ea3b7015a18dc
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      6d55d109
  23. 20 Feb, 2014 1 commit
    • Achin Gupta's avatar
      Factor out translation table setup in ARM FVP port · a0cd989d
      Achin Gupta authored
      This patch factors out the ARM FVP specific code to create MMU
      translation tables so that it is possible for a boot loader stage to
      create a different set of tables instead of using the default ones.
      The default translation tables are created with the assumption that
      the calling boot loader stage executes out of secure SRAM. This might
      not be true for the BL3_2 stage in the future.
      
      A boot loader stage can define the `fill_xlation_tables()` function as
      per its requirements. It returns a reference to the level 1
      translation table which is used by the common platform code to setup
      the TTBR_EL3.
      
      This patch is a temporary solution before a larger rework of
      translation table creation logic is introduced.
      
      Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
      a0cd989d
  24. 17 Feb, 2014 2 commits
    • Harry Liebel's avatar
      Add Firmware Image Package (FIP) driver · 561cd33e
      Harry Liebel authored
      The Firmware Image Package (FIP) driver allows for data to be loaded
      from a FIP on platform storage. The FVP supports loading bootloader
      images from a FIP located in NOR FLASH.
      
      The implemented FVP policy states that bootloader images will be
      loaded from a FIP in NOR FLASH if available and fall back to loading
      individual images from semi-hosting.
      
      NOTE:
      - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured
        to run from the BL33_BASE address. This is currently set to
        DRAM_BASE+128MB for the FVP.
      
      Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
      561cd33e
    • James Morrissey's avatar
      Implement load_image in terms of IO abstraction · 9d72b4ea
      James Morrissey authored
      The modified implementation uses the IO abstraction rather than
      making direct semi-hosting calls.  The semi-hosting driver is now
      registered for the FVP platform during initialisation of each boot
      stage where it is used.  Additionally, the FVP platform includes a
      straightforward implementation of 'plat_get_image_source' which
      provides a generic means for the 'load_image' function to determine
      how to access the image data.
      
      Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
      9d72b4ea
  25. 20 Jan, 2014 3 commits
  26. 17 Jan, 2014 3 commits
    • Harry Liebel's avatar
      Probe for GICv3 re-distributors on core bring-up · eaec590e
      Harry Liebel authored
      The GICv3 distributor can have more ports than CPUs are available in
      the system. Probe all re-distributors and use the matching affinity
      levels as specified by each core and re-distributor to decide which
      re-distributor to use with which CPU core.
      
      If a core cannot be matched with a re-distributor, the core panics and
      is placed in an endless loop.
      
      Change-Id: Ie393cfe07c7449a2383959e3c968664882e18afc
      eaec590e
    • Dan Handley's avatar
      Update year in copyright text to 2014 · e83b0cad
      Dan Handley authored
      Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
      e83b0cad
    • Ian Spray's avatar
      Move GIC setup to a separate file · 8468739c
      Ian Spray authored
      GIC setup code which used to be in bl31_plat_setup.c is now in fvp_gic.c
      to simplify future changes to other bootloader stages.  This patch moves
      code from bl31_plat_setup.c to fvp_gic.c, simplifies the include file
      list for bl31_plat_setup.c, moves GIC declarations from the bl31.h header
      file into the platform.h, and reworks files according to coding style
      guide.
      
      Change-Id: I48d82a4ba33e7114dcc88f9ca98767a06cf8f417
      8468739c