1. 28 Jul, 2014 1 commit
    • Juan Castillo's avatar
      Rework incorrect use of assert() and panic() in codebase · d3280beb
      Juan Castillo authored
      Assert a valid security state using the macro sec_state_is_valid().
      Replace assert() with panic() in those cases that might arise
      because of runtime errors and not programming errors.
      Replace panic() with assert() in those cases that might arise
      because of programming errors.
      
      Fixes ARM-software/tf-issues#96
      
      Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5
      d3280beb
  2. 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
  3. 16 Jul, 2014 1 commit
    • Juan Castillo's avatar
      FVP: Ensure system reset wake-up results in cold boot · 08783e43
      Juan Castillo authored
      platform_get_entrypoint() did not consider that a wakeup due to
      System Reset Pin (by reading the power controller's PSYSR) requires
      a cold boot. As a result, the code would execute the warm boot path
      and eventually panic because entrypoint mailboxes are empty.
      
      This patch ensures that the following wake-up reasons result in cold
      boot:
        - Cold Power-on
        - System Reset Pin (includes reset by software)
      
      Fixes ARM-software/tf-issues#217
      
      Change-Id: I65ae0a0f7a46548b575900a5aac107d352b0e2cd
      08783e43
  4. 10 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      fvp: Reuse BL1 and BL2 memory through image overlaying · a1b6db6c
      Sandrine Bailleux authored
      This patch re-organizes the memory layout on FVP as to give the
      BL3-2 image as much memory as possible.
      
      Considering these two facts:
       - not all images need to live in memory at the same time. Once
         in BL3-1, the memory used by BL1 and BL2 can be reclaimed.
       - when BL2 loads the BL3-1 and BL3-2 images, it only considers the
         PROGBITS sections of those 2 images. The memory occupied by the
         NOBITS sections will be touched only at execution of the BL3-x
         images;
      Then it is possible to choose the different base addresses such that
      the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2.
      
      On FVP we choose to put:
       - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS
         sections overlaying BL1;
       - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections
         overlaying BL2;
      
      This is illustrated by the following diagram:
      
      0x0404_0000 ------------    ------------------
                  |   BL1    | <= |  BL3-1 NOBITS  |
                  ------------ <= ------------------
                  |          | <= | BL3-1 PROGBITS |
                  ------------    ------------------
                  |   BL2    | <= |  BL3-2 NOBITS  |
                  ------------ <= ------------------
                  |          | <= | BL3-2 PROGBITS |
      0x0400_0000 ------------    ------------------
      
      New platform-specific constants have been introduced to easily check
      at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite
      BL1 and BL2. These are optional and the platform code is free to define
      them or not. If not defined, the linker won't attempt to check
      image overlaying.
      
      Fixes ARM-software/tf-issues#117
      
      Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
      a1b6db6c
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 16 Jun, 2014 1 commit
  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. 05 Jun, 2014 1 commit
  15. 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
  16. 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
  17. 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
  18. 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
  19. 22 May, 2014 8 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