1. 22 May, 2014 1 commit
    • 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
  2. 09 May, 2014 1 commit
    • Sandrine Bailleux's avatar
      fvp: Provide per-EL MMU setup functions · b793e431
      Sandrine Bailleux authored
      Instead of having a single version of the MMU setup functions for all
      bootloader images that can execute either in EL3 or in EL1, provide
      separate functions for EL1 and EL3. Each bootloader image can then
      call the appropriate version of these functions. The aim is to reduce
      the amount of code compiled in each BL image by embedding only what's
      needed (e.g. BL1 to embed only EL3 variants).
      
      Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa
      b793e431
  3. 06 May, 2014 1 commit
    • Dan Handley's avatar
      Reduce deep nesting of header files · 97043ac9
      Dan Handley authored
      Reduce the number of header files included from other header
      files as much as possible without splitting the files. Use forward
      declarations where possible. This allows removal of some unnecessary
      "#ifndef __ASSEMBLY__" statements.
      
      Also, review the .c and .S files for which header files really need
      including and reorder the #include statements alphabetically.
      
      Fixes ARM-software/tf-issues#31
      
      Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
      97043ac9
  4. 26 Mar, 2014 1 commit
    • Andrew Thoelke's avatar
      Place assembler functions in separate sections · 0a30cf54
      Andrew Thoelke authored
      This extends the --gc-sections behaviour to the many assembler
      support functions in the firmware images by placing each function
      into its own code section. This is achieved by creating a 'func'
      macro used to declare each function label.
      
      Fixes ARM-software/tf-issues#80
      
      Change-Id: I301937b630add292d2dec6d2561a7fcfa6fec690
      0a30cf54
  5. 20 Feb, 2014 2 commits
    • Achin Gupta's avatar
      Rework arithmetic operations in Test Secure Payload · 916a2c1e
      Achin Gupta authored
      
      
      This patch reworks the service provided by the TSP to perform common
      arithmetic operations on a set of arguments provided by the non-secure
      world. For a addition, division, subtraction & multiplication operation
      requested on two arguments in x0 and x1 the steps are:
      
      1. TSPD saves the non-secure context and passes the operation and its
         arguments to the TSP.
      
      2. TSP asks the TSPD to return the same arguments once again. This
         exercises an additional SMC path.
      
      3. TSP now has two copies of both x0 and x1. It performs the operation
         on the corresponding copies i.e. in case of addition it returns x0+x0
         and x1+x1.
      
      4. TSPD receives the result, saves the secure context, restores the
         non-secure context and passes the result back to the non-secure
         client.
      
      Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b
      Co-authored-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      916a2c1e
    • Achin Gupta's avatar
      Add Test Secure Payload (BL3-2) image · 7c88f3f6
      Achin Gupta authored
      
      
      This patch adds a simple TSP as the BL3-2 image. The secure payload
      executes in S-EL1. It paves the way for the addition of the TSP
      dispatcher runtime service to BL3-1. The TSP and the dispatcher service
      will serve as an example of the runtime firmware's ability to toggle
      execution between the non-secure and secure states in response to SMC
      request from the non-secure state.  The TSP will be replaced by a
      Trusted OS in a real system.
      
      The TSP also exports a set of handlers which should be called in
      response to a PSCI power management event e.g a cpu being suspended or
      turned off. For now it runs out of Secure DRAM on the ARM FVP port and
      will be moved to Secure SRAM later. The default translation table setup
      code assumes that the caller is executing out of secure SRAM. Hence the
      TSP exports its own translation table setup function.
      
      The TSP only services Fast SMCs, is non-reentrant and non-interruptible.
      It does arithmetic operations on two sets of four operands, one set
      supplied by the non-secure client, and the other supplied by the TSP
      dispatcher in EL3. It returns the result according to the Secure Monitor
      Calling convention standard.
      
      This TSP has two functional entry points:
      
      - An initial, one-time entry point through which the TSP is initialized
        and prepares for receiving further requests from secure
        monitor/dispatcher
      
      - A fast SMC service entry point through which the TSP dispatcher
        requests secure services on behalf of the non-secure client
      
      Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931
      Co-authored-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      7c88f3f6