1. 09 Jul, 2014 2 commits
    • 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
    • Dan Handley's avatar
      Refactor fvp_config into common platform header · 6f3b195a
      Dan Handley authored
      Changed the fvp_config array in fvp_common.c into a struct and
      moved into a new optional common platform header,
      include/plat/common/plat_config.h. Removed the config definitions
      in fvp_def.h and updated all references to the platform config.
      
      This makes the interface to the platform config cleaner and uses
      a little less RAM.
      
      Fixes ARM-software/tf-issues#180
      
      Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
      6f3b195a
  2. 01 Jul, 2014 2 commits
    • Sandrine Bailleux's avatar
      fvp: Properly detect the location of BL1 R/W data · 60633799
      Sandrine Bailleux authored
      There was already a rudimentary mechanism to detect whether BL1
      R/W data was loaded at the top or bottom of memory. Basically,
       - either BL1 was loaded at the very end of the trusted RAM
       - in all other cases BL1 was considered sitting at the bottom of
         the memory and the memory usage structure was updated accordingly,
         potentially resulting in critical memory waste.
      For instance, if BL1 R/W base address was set to
      (TZRAM_END - 4096 - bl1_size), it would virtually occupy the whole
      memory.
      
      This patch improves the mechanism to detect the location of BL1
      to avoid such scenarios.
      
      Change-Id: I224a9edf0fe8d34208545d84b28b63f2bb830d03
      60633799
    • Sandrine Bailleux's avatar
      Remove concept of top/bottom image loading · 8f55dfb4
      Sandrine Bailleux authored
      This concept is no longer required since we now support loading of
      images at fixed addresses only.
      
      The image loader now automatically detects the position of the image
      inside the current memory layout and updates the layout such that
      memory fragmentation is minimised.
      
      The 'attr' field of the meminfo data structure, which used to hold
      the bottom/top loading information, has been removed. Also the 'next'
      field has been removed as it wasn't used anywhere.
      
      The 'init_bl2_mem_layout()' function has been moved out of common
      code and put in BL1-specific code. It has also been renamed into
      'bl1_init_bl2_mem_layout'.
      
      Fixes ARM-software/tf-issues#109
      
      Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d
      8f55dfb4
  3. 27 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Support later revisions of the Foundation FVP · 90e31479
      Andrew Thoelke authored
      The code in the FVP port which checks the platform type and
      revision information in the SYS_ID register strictly supported
      only the first revision of the Base and Foundation FVPs.
      
      The current check also does not reflect the fact that the
      board revision field is 'local' to the board type (HBI field).
      
      Support for a new Foundation model is required now, and the
      checking code is relaxed to allow execution (with a diagnostic)
      on unrecognised revisions of the Base and Foundation FVP.
      
      Change-Id: I7cd3519dfb56954aafe5f52ce1fcea0ee257ba9f
      90e31479
  4. 24 Jun, 2014 4 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
    • Juan Castillo's avatar
      Remove all checkpatch errors from codebase · 4f2104ff
      Juan Castillo authored
      Exclude stdlib files because they do not follow kernel code style.
      
      Fixes ARM-software/tf-issues#73
      
      Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab
      4f2104ff
    • 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
    • Sandrine Bailleux's avatar
      fvp: Fix register name in 'plat_print_gic_regs' macro · 9edc8917
      Sandrine Bailleux authored
      The 'plat_print_gic_regs' macro was accessing the GICC_CTLR register
      using the GICD_CTLR offset. This still generates the right code in
      the end because GICD_CTLR == GICC_CTLR but this patch fixes it for
      the logic of the code.
      
      Change-Id: I7b17af50e587f07bec0e4c933e346088470c96f3
      9edc8917
  5. 23 Jun, 2014 2 commits
    • Andrew Thoelke's avatar
      Remove calling CPU mpidr from bakery lock API · 634ec6c2
      Andrew Thoelke authored
      The bakery lock code currently expects the calling code to pass
      the MPIDR_EL1 of the current CPU.
      
      This is not always done correctly. Also the change to provide
      inline access to system registers makes it more efficient for the
      bakery lock code to obtain the MPIDR_EL1 directly.
      
      This change removes the mpidr parameter from the bakery lock
      interface, and results in a code reduction of 160 bytes for the
      ARM FVP port.
      
      Fixes ARM-software/tf-issues#213
      
      Change-Id: I7ec7bd117bcc9794a0d948990fcf3336a367d543
      634ec6c2
    • Andrew Thoelke's avatar
      Correctly dimension the PSCI aff_map_node array · 6c0b45d1
      Andrew Thoelke authored
      The array of affinity nodes is currently allocated for 32 entries
      with the PSCI_NUM_AFFS value defined in psci.h. This is not enough
      for large systems, and will substantially over allocate the array
      for small systems.
      
      This patch introduces an optional platform definition
      PLATFORM_NUM_AFFS to platform_def.h. If defined this value is
      used for PSCI_NUM_AFFS, otherwise a value of two times the number
      of CPU cores is used.
      
      The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves
      nearly 1.5KB of memory.
      
      Fixes ARM-software/tf-issues#192
      
      Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445
      6c0b45d1
  6. 20 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Remove NSRAM from FVP memory map · 15f195bf
      Andrew Thoelke authored
      This memory is not used by the FVP port and requires an additional
      4KB translation table.
      
      This patch removes the entry from the memory map and reduces the
      number of allocated translation tables.
      
      Fixes ARM-software/tf-issues#196
      
      Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
      15f195bf
  7. 18 Jun, 2014 1 commit
    • Soby Mathew's avatar
      Remove re-initialisation of system timers after warm boot for FVP · b1e71b20
      Soby Mathew authored
      This patch removes the reinitialisation of memory mapped system timer
      registers after a warm boot for the FVP. The system timers in FVP are
      in the 'Always ON' power domain which meant the reinitialisation was
      redundant and it could have conflicted with the setup the normal
      world has done.
      
      The programming of CNTACR(x) and CNTNSAR, the system timer registers,
      are removed from the warm boot path with this patch.
      
      Fixes ARM-software/tf-issues#169
      
      Change-Id: Ie982eb03d1836b15ef3cf1568de2ea68a08b443e
      b1e71b20
  8. 16 Jun, 2014 1 commit
  9. 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
  10. 05 Jun, 2014 1 commit
  11. 02 Jun, 2014 1 commit
    • Lin Ma's avatar
      Enable mapping higher physical address · f984ce84
      Lin Ma authored
      Current ATF uses a direct physical-to-virtual mapping, that is, a physical
      address is mapped to the same address in the virtual space. For example,
      physical address 0x8000_0000 is mapped to 0x8000_0000 virtual. This
      approach works fine for FVP as all its physical addresses fall into 0 to
      4GB range. But for other platform where all I/O addresses are 48-bit long,
      If we follow the same direct mapping, we would need virtual address range
      from 0 to 0x8fff_ffff_ffff, which is about 144TB. This requires a
      significant amount of memory for MMU tables and it is not necessary to use
      that much virtual space in ATF.
      
      The patch is to enable mapping a physical address range to an arbitrary
      virtual address range (instead of flat mapping)
      Changed "base" to "base_va" and added "base_pa" in mmap_region_t and
      modified functions such as mmap_add_region and init_xlation_table etc.
      Fixes ARM-software/tf-issues#158
      f984ce84
  12. 29 May, 2014 1 commit
    • Andrew Thoelke's avatar
      Allow platform parameter X1 to be passed to BL3-1 · 03462671
      Andrew Thoelke authored
      bl2_main() was overwriting any platform set X1 parameter for BL3-1
      with the value zero.
      
      This patch ensure that any platform set value is correctly passed
      to BL3-1. The FVP port adds a check to verify this parameter is
      being passed correctly.
      
      Fixes ARM-software/tf-issues#173
      
      Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
      03462671
  13. 27 May, 2014 1 commit
    • Dan Handley's avatar
      Further renames of platform porting functions · 9865ac15
      Dan Handley authored
      Rename the ic_* platform porting functions to plat_ic_* to be
      consistent with the other functions in platform.h. Also rename
      bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info()
      and remove the duplicate declaration in bl31.h.
      
      Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84
      9865ac15
  14. 23 May, 2014 9 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
    • Dan Handley's avatar
      Move BL porting functions into platform.h · dec5e0d1
      Dan Handley authored
      Some platform porting functions were in BL specific header files.
      These have been moved to platform.h so that all porting functions
      are in the same place. The functions are now grouped by BL.
      Obsolete BL headers files have been removed.
      
      Also, the weak declaration of the init_bl2_mem_layout() function
      has been moved out the header file and into the source file
      (bl_common.c) using the more succinct #pragma syntax. This
      mitigates the risk of 2 weak definitions being created and the
      wrong one being picked up by the compiler.
      
      Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
      dec5e0d1
    • Dan Handley's avatar
      Split platform.h into separate headers · 5f0cdb05
      Dan Handley authored
      Previously, platform.h contained many declarations and definitions
      used for different purposes. This file has been split so that:
      
      * Platform definitions used by common code that must be defined
        by the platform are now in platform_def.h. The exact include
        path is exported through $PLAT_INCLUDES in the platform makefile.
      
      * Platform definitions specific to the FVP platform are now in
        /plat/fvp/fvp_def.h.
      
      * Platform API declarations specific to the FVP platform are now
        in /plat/fvp/fvp_private.h.
      
      * The remaining platform API declarations that must be ported by
        each platform are still in platform.h but this file has been
        moved to /include/plat/common since this can be shared by all
        platforms.
      
      Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
      5f0cdb05
    • Dan Handley's avatar
      Remove unused data declarations · 7a9a5f2d
      Dan Handley authored
      Some data variables were declared but not used. These have been
      removed.
      
      Change-Id: I038632af3c32d88984cd25b886c43ff763269bf9
      7a9a5f2d
    • Dan Handley's avatar
      Remove extern keyword from function declarations · c6bc0710
      Dan Handley authored
      Function declarations implicitly have external linkage so do not
      need the extern keyword.
      
      Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32
      c6bc0710
    • Sandrine Bailleux's avatar
      Make the memory layout more flexible · a37255a2
      Sandrine Bailleux authored
      Currently the platform code gets to define the base address of each
      boot loader image. However, the linker scripts couteract this
      flexibility by enforcing a fixed overall layout of the different
      images. For example, they require that the BL3-1 image sits below
      the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way
      that it violates this constraint makes the build fail at link-time.
      
      This patch requires the platform code to now define a limit address
      for each image. The linker scripts check that the image fits within
      these bounds so they don't rely anymore on the position of a given
      image in regard to the others.
      
      Fixes ARM-software/tf-issues#163
      
      Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
      a37255a2
    • Sandrine Bailleux's avatar
      Make BL1 RO and RW base addresses configurable · 4f59d835
      Sandrine Bailleux authored
      BL1 RO and RW base address used to be fixed, respectively to the first
      address of the Trusted ROM and the first address of the Trusted RAM.
      
      Introduce new platform defines to configure the BL1 RO and RW base
      addresses.
      
      Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6
      4f59d835
    • Andrew Thoelke's avatar
      Limit BL3-1 read/write access to SRAM · 445fe84f
      Andrew Thoelke authored
      At present BL3-1 has access to all of the SRAM, including
      regions that are mapped as read-only and non-cacheable by other
      firmware images.
      
      This patch restricts BL3-1 to only be able to read/write from
      memory used for its own data sections
      
      Change-Id: I26cda1b9ba803d91a9eacda768f3ce7032c6db94
      
      Conflicts:
      
      	plat/fvp/bl31_plat_setup.c
      445fe84f
  15. 22 May, 2014 10 commits
    • Achin Gupta's avatar
      Add support for synchronous FIQ handling in TSP · 6cf89021
      Achin Gupta authored
      This patch adds support in the TSP for handling S-EL1 interrupts
      handed over by the TSPD. It includes GIC support in its platform port,
      updates various statistics related to FIQ handling, exports an entry
      point that the TSPD can use to hand over interrupts and defines the
      handover protocol w.r.t what context is the TSP expected to preserve
      and the state in which the entry point is invoked by the TSPD.
      
      Change-Id: I93b22e5a8133400e4da366f5fc862f871038df39
      6cf89021
    • Achin Gupta's avatar
      Introduce platform api to access an ARM GIC · dcc1816c
      Achin Gupta authored
      This patch introduces a set of functions which allow generic firmware
      code e.g. the interrupt management framework to access the platform
      interrupt controller. APIs for finding the type and id of the highest
      pending interrupt, acknowledging and EOIing an interrupt and finding
      the security state of an interrupt have been added. It is assumed that
      the platform interrupt controller implements the v2.0 of the ARM GIC
      architecture specification. Support for v3.0 of the specification for
      managing interrupts in EL3 and the platform port will be added in the
      future.
      
      Change-Id: Ib3a01c2cf3e3ab27806930f1be79db2b29f91bcf
      dcc1816c
    • 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
    • Sandrine Bailleux's avatar
      TSP: Let the platform decide which secure memory to use · 2467f70f
      Sandrine Bailleux authored
      The TSP's linker script used to assume that the TSP would
      execute from secure DRAM. Although it is currently the case
      on FVPs, platforms are free to use any secure memory they wish.
      
      This patch introduces the flexibility to load the TSP into any
      secure memory. The platform code gets to specify the extents of
      this memory in the platform header file, as well as the BL3-2 image
      limit address. The latter definition allows to check in a generic way
      that the BL3-2 image fits in its bounds.
      
      Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c
      2467f70f
    • Juan Castillo's avatar
      Reserve some DDR DRAM for secure use on FVP platforms · 364daf93
      Juan Castillo authored
      TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and
      the rest of DRAM as non-secure. Non-secure software must not attempt to
      access the 16MB secure area.
      
      Device tree files (sources and binaries) have been updated to match this
      configuration, removing that memory from the Linux physical memory map.
      
      To use UEFI and Linux with this patch, the latest version of UEFI and
      the updated device tree files are required. Check the user guide in the
      documentation for more details.
      
      Replaced magic numbers with #define for memory region definition in the
      platform security initialization function.
      
      Fixes ARM-software/tf-issues#149
      
      Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
      364daf93
    • 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
    • Vikram Kanigiri's avatar
      Rework memory information passing to BL3-x images · 6871c5d3
      Vikram Kanigiri authored
      The issues addressed in this patch are:
      
      1. Remove meminfo_t from the common interfaces in BL3-x,
      expecting that platform code will find a suitable mechanism
      to determine the memory extents in these images and provide
      it to the BL3-x images.
      
      2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x
      code as the images use link-time information to determine
      memory extents.
      
      meminfo_t is still used by common interface in BL1/BL2 for
      loading images
      
      Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f
      6871c5d3
    • Vikram Kanigiri's avatar
      Populate BL31 input parameters as per new spec · 4112bfa0
      Vikram Kanigiri authored
      This patch is based on spec published at
      https://github.com/ARM-software/tf-issues/issues/133
      
      It rearranges the bl31_args struct into
      bl31_params and bl31_plat_params which provide the
      information needed for Trusted firmware and platform
      specific data via x0 and x1
      
      On the FVP platform BL3-1 params and BL3-1 plat params
      and its constituents are stored at the start of TZDRAM.
      
      The information about memory availability and size for
      BL3-1, BL3-2 and BL3-3 is moved into platform specific data.
      
      Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9
      4112bfa0
    • Vikram Kanigiri's avatar
      Rework handover interface between BL stages · 29fb905d
      Vikram Kanigiri authored
      This patch reworks the handover interface from: BL1 to BL2 and
      BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el()
      and run_image() functions as they catered for code paths that were
      never exercised.
      BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same
      by calling run_image(). Similarly, BL2 issues the SMC to transfer
      execution to BL3-1 through BL1 directly. Only x0 and x1 are used
      to pass arguments to BL31. These arguments and parameters for
      running BL3-1 are passed through a reference to a
      'el_change_info_t' structure. They were being passed value in
      general purpose registers earlier.
      
      Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1
      29fb905d
  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. 12 May, 2014 1 commit
    • Andrew Thoelke's avatar
      Fixes for TZC configuration on FVP · 84dbf6ff
      Andrew Thoelke authored
      The TZC configuration on FVP was incorrectly allowing both secure
      and non-secure accesses to the DRAM, which can cause aliasing
      problems for software. It was also not enabling virtio access on
      some models.
      
      This patch fixes both of those issues. The patch also enabless
      non-secure access to the DDR RAM for all devices with defined IDs.
      
      The third region of DDR RAM has been removed from the configuration
      as this is not used in any of the FVP models.
      
      Fixes ARM-software/tf-issues#150
      Fixes ARM-software/tf-issues#151
      
      Change-Id: I60ad5daaf55e14f178affb8afd95d17e7537abd7
      84dbf6ff