1. 27 Feb, 2019 1 commit
    • Antonio Nino Diaz's avatar
      BL1: Enable pointer authentication support · cd7d6b0e
      Antonio Nino Diaz authored
      
      
      The size increase after enabling options related to ARMv8.3-PAuth is:
      
      +----------------------------+-------+-------+-------+--------+
      |                            |  text |  bss  |  data | rodata |
      +----------------------------+-------+-------+-------+--------+
      | CTX_INCLUDE_PAUTH_REGS = 1 |  +108 |  +192 |   +0  |   +0   |
      |                            |  0.5% |  0.8% |       |        |
      +----------------------------+-------+-------+-------+--------+
      | ENABLE_PAUTH = 1           |  +748 |  +192 |  +16  |   +0   |
      |                            |  3.7% |  0.8% |  7.0% |        |
      +----------------------------+-------+-------+-------+--------+
      
      Results calculated with the following build configuration:
      
          make PLAT=fvp SPD=tspd DEBUG=1 \
          SDEI_SUPPORT=1                 \
          EL3_EXCEPTION_HANDLING=1       \
          TSP_NS_INTR_ASYNC_PREEMPT=1    \
          CTX_INCLUDE_PAUTH_REGS=1       \
          ENABLE_PAUTH=1
      
      Change-Id: I3a7d02feb6a6d212be32a01432b0c7c1a261f567
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      cd7d6b0e
  2. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  3. 01 Nov, 2018 1 commit
  4. 11 Jul, 2018 1 commit
    • Roberto Vargas's avatar
      Add end_vector_entry assembler macro · a9203eda
      Roberto Vargas authored
      
      
      Check_vector_size checks if the size of the vector fits
      in the size reserved for it. This check creates problems in
      the Clang assembler. A new macro, end_vector_entry, is added
      and check_vector_size is deprecated.
      
      This new macro fills the current exception vector until the next
      exception vector. If the size of the current vector is bigger
      than 32 instructions then it gives an error.
      
      Change-Id: Ie8545cf1003a1e31656a1018dd6b4c28a4eaf671
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      a9203eda
  5. 21 Mar, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Rename 'smcc' to 'smccc' · 085e80ec
      Antonio Nino Diaz authored
      
      
      When the source code says 'SMCC' it is talking about the SMC Calling
      Convention. The correct acronym is SMCCC. This affects a few definitions
      and file names.
      
      Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S)
      but the old files have been kept for compatibility, they include the
      new ones with an ERROR_DEPRECATED guard.
      
      Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      085e80ec
  6. 21 Feb, 2018 1 commit
  7. 12 Jul, 2017 1 commit
    • Isla Mitchell's avatar
      Fix order of #includes · 2a4b4b71
      Isla Mitchell authored
      
      
      This fix modifies the order of system includes to meet the ARM TF coding
      standard. There are some exceptions in order to retain header groupings,
      minimise changes to imported headers, and where there are headers within
      the #if and #ifndef statements.
      
      Change-Id: I65085a142ba6a83792b26efb47df1329153f1624
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      2a4b4b71
  8. 23 Jun, 2017 1 commit
  9. 21 Jun, 2017 1 commit
    • David Cunado's avatar
      Fully initialise essential control registers · 18f2efd6
      David Cunado authored
      
      
      This patch updates the el3_arch_init_common macro so that it fully
      initialises essential control registers rather then relying on hardware
      to set the reset values.
      
      The context management functions are also updated to fully initialise
      the appropriate control registers when initialising the non-secure and
      secure context structures and when preparing to leave EL3 for a lower
      EL.
      
      This gives better alignement with the ARM ARM which states that software
      must initialise RES0 and RES1 fields with 0 / 1.
      
      This patch also corrects the following typos:
      
      "NASCR definitions" -> "NSACR definitions"
      
      Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      18f2efd6
  10. 03 May, 2017 1 commit
  11. 02 May, 2017 1 commit
  12. 05 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Define and use no_ret macro where no return is expected · a806dad5
      Jeenu Viswambharan authored
      
      
      There are many instances in ARM Trusted Firmware where control is
      transferred to functions from which return isn't expected. Such jumps
      are made using 'bl' instruction to provide the callee with the location
      from which it was jumped to. Additionally, debuggers infer the caller by
      examining where 'lr' register points to. If a 'bl' of the nature
      described above falls at the end of an assembly function, 'lr' will be
      left pointing to a location outside of the function range. This misleads
      the debugger back trace.
      
      This patch defines a 'no_ret' macro to be used when jumping to functions
      from which return isn't expected. The macro ensures to use 'bl'
      instruction for the jump, and also, for debug builds, places a 'nop'
      instruction immediately thereafter (unless instructed otherwise) so as
      to leave 'lr' pointing within the function range.
      
      Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a806dad5
  13. 21 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      AArch32: Add generic changes in BL1 · f3b4914b
      Yatharth Kochar authored
      This patch adds generic changes in BL1 to support AArch32 state.
      New AArch32 specific assembly/C files are introduced and
      some files are moved to AArch32/64 specific folders.
      BL1 for AArch64 is refactored but functionally identical.
      BL1 executes in Secure Monitor mode in AArch32 state.
      
      NOTE: BL1 in AArch32 state ONLY handles BL1_RUN_IMAGE SMC.
      
      Change-Id: I6e2296374c7efbf3cf2aa1a0ce8de0732d8c98a5
      f3b4914b
  14. 22 Aug, 2016 1 commit
    • Yatharth Kochar's avatar
      Remove looping around `plat_report_exception` · 5bbc451e
      Yatharth Kochar authored
      This patch removes the tight loop that calls `plat_report_exception`
      in unhandled exceptions in AArch64 state.
      The new behaviour is to call the `plat_report_exception` only
      once followed by call to `plat_panic_handler`.
      This allows platforms to take platform-specific action when
      there is an unhandled exception, instead of always spinning
      in a tight loop.
      
      Note: This is a subtle break in behaviour for platforms that
            expect `plat_report_exception` to be continuously executed
            when there is an unhandled exception.
      
      Change-Id: Ie2453804b9b7caf9b010ee73e1a90eeb8384e4e8
      5bbc451e
  15. 26 May, 2016 1 commit
    • Sandrine Bailleux's avatar
      Introduce some helper macros for exception vectors · e0ae9fab
      Sandrine Bailleux authored
      This patch introduces some assembler macros to simplify the
      declaration of the exception vectors. It abstracts the section
      the exception code is put into as well as the alignments
      constraints mandated by the ARMv8 architecture. For all TF images,
      the exception code has been updated to make use of these macros.
      
      This patch also updates some invalid comments in the exception
      vector code.
      
      Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
      e0ae9fab
  16. 30 Mar, 2016 1 commit
    • Gerald Lejeune's avatar
      Enable asynchronous abort exceptions during boot · adb4fcfb
      Gerald Lejeune authored
      
      
      Asynchronous abort exceptions generated by the platform during cold boot are
      not taken in EL3 unless SCR_EL3.EA is set.
      
      Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
      initialisation. Further write accesses to SCR_EL3 preserve these bits during
      cold boot.
      
      A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
      being trapped by EL3 after cold boot or not.
      
      For further reference SError Interrupts are also known as asynchronous external
      aborts.
      
      On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
      EL3 whatever the SCR_EL3.EA value is.
      
      Fixes arm-software/tf-issues#368
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      adb4fcfb
  17. 09 Dec, 2015 3 commits
    • Yatharth Kochar's avatar
      FWU: Add Generic Firmware Update framework support in BL1 · 48bfb88e
      Yatharth Kochar authored
      Firmware update(a.k.a FWU) feature is part of the TBB architecture.
      BL1 is responsible for carrying out the FWU process if platform
      specific code detects that it is needed.
      
      This patch adds support for FWU feature support in BL1 which is
      included by enabling `TRUSTED_BOARD_BOOT` compile time flag.
      
      This patch adds bl1_fwu.c which contains all the core operations
      of FWU, which are; SMC handler, image copy, authentication, execution
      and resumption. It also adds bl1.h introducing #defines for all
      BL1 SMCs.
      
      Following platform porting functions are introduced:
      
      int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size,
      unsigned int flags);
      	This function can be used to add platform specific memory checks
      	for the provided base/size for the given security state.
      	The weak definition will invoke `assert()` and return -ENOMEM.
      
      __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved);
      	This function can be used to initiate platform specific procedure
      	to mark completion of the FWU process.
      	The weak definition waits forever calling `wfi()`.
      
      plat_bl1_common.c contains weak definitions for above functions.
      
      FWU process starts when platform detects it and return the image_id
      other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in
      `bl1_main()`.
      
      NOTE: User MUST provide platform specific real definition for
      bl1_plat_mem_check() in order to use it for Firmware update.
      
      Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
      48bfb88e
    • Yatharth Kochar's avatar
      Add descriptor based image management support in BL1 · 7baff11f
      Yatharth Kochar authored
      As of now BL1 loads and execute BL2 based on hard coded information
      provided in BL1. But due to addition of support for upcoming Firmware
      Update feature, BL1 now require more flexible approach to load and
      run different images using information provided by the platform.
      
      This patch adds new mechanism to load and execute images based on
      platform provided image id's. BL1 now queries the platform to fetch
      the image id of the next image to be loaded and executed. In order
      to achieve this, a new struct image_desc_t was added which holds the
      information about images, such as: ep_info and image_info.
      
      This patch introduces following platform porting functions:
      
      unsigned int bl1_plat_get_next_image_id(void);
      	This is used to identify the next image to be loaded
      	and executed by BL1.
      
      struct image_desc *bl1_plat_get_image_desc(unsigned int image_id);
      	This is used to retrieve the image_desc for given image_id.
      
      void bl1_plat_set_ep_info(unsigned int image_id,
      struct entry_point_info *ep_info);
      	This function allows platforms to update ep_info for given
      	image_id.
      
      The plat_bl1_common.c file provides default weak implementations of
      all above functions, the `bl1_plat_get_image_desc()` always return
      BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return
      BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns.
      These functions gets compiled into all BL1 platforms by default.
      
      Platform setup in BL1, using `bl1_platform_setup()`, is now done
      _after_ the initialization of authentication module. This change
      provides the opportunity to use authentication while doing the
      platform setup in BL1.
      
      In order to store secure/non-secure context, BL31 uses percpu_data[]
      to store context pointer for each core. In case of BL1 only the
      primary CPU will be active hence percpu_data[] is not required to
      store the context pointer.
      
      This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to
      store the context and context pointers respectively. It also also
      re-defines cm_get_context() and cm_set_context() for BL1 in
      bl1/bl1_context_mgmt.c.
      
      BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime
      environment, to support resuming execution from a previously saved
      context.
      
      NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS
            NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE
            THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()`
            INSTEAD TO MAINTAIN EXISTING BEHAVIOUR.
      
      Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
      7baff11f
    • Yatharth Kochar's avatar
      Move context management code to common location · bbf8f6f9
      Yatharth Kochar authored
      The upcoming Firmware Update feature needs transitioning across
      Secure/Normal worlds to complete the FWU process and hence requires
      context management code to perform this task.
      
      Currently context management code is part of BL31 stage only.
      This patch moves the code from (include)/bl31 to (include)/common.
      Some function declarations/definitions and macros have also moved
      to different files to help code sharing.
      
      Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
      bbf8f6f9
  18. 26 Nov, 2015 3 commits
    • Sandrine Bailleux's avatar
      Introduce COLD_BOOT_SINGLE_CPU build option · a9bec67d
      Sandrine Bailleux authored
      This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
      which allows platforms that only release a single CPU out of reset to
      slightly optimise their cold boot code, both in terms of code size
      and performance.
      
      COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
      may release several CPUs out of reset. In this case, the cold reset
      code needs to coordinate all CPUs via the usual primary/secondary
      CPU distinction.
      
      If a platform guarantees that only a single CPU will ever be released
      out of reset, there is no need to arbitrate execution ; the notion of
      primary and secondary CPUs itself no longer exists. Such platforms
      may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
      primary/secondary CPU identification in the cold reset code.
      
      All ARM standard platforms can release several CPUs out of reset
      so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
      Juno, bringing up more than one CPU at reset should only be attempted
      when booting an EL3 payload, as it is not fully supported in the
      normal boot flow.
      
      For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
      APIs become optional:
        - plat_secondary_cold_boot_setup();
        - plat_is_my_cpu_primary().
      The Porting Guide has been updated to reflect that.
      
      User Guide updated as well.
      
      Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
      a9bec67d
    • Sandrine Bailleux's avatar
      Pass the entry point info to bl1_plat_prepare_exit() · 862b5dc2
      Sandrine Bailleux authored
      This patch modifies the prototype of the bl1_plat_prepare_exit()
      platform API to pass the address of the entry point info structure
      received from BL2. The structure contains information that can be
      useful, depending on the kind of clean up or bookkeeping operations
      to perform.
      
      The weak implementation of this function ignores this argument to
      preserve platform backwards compatibility.
      
      NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
      FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.
      
      Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
      862b5dc2
    • Sandrine Bailleux's avatar
      Introduce SPIN_ON_BL1_EXIT build flag · 35e8c766
      Sandrine Bailleux authored
      This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
      puts an infinite loop in BL1. It is intended to help debugging
      the post-BL2 phase of the Trusted Firmware by stopping execution
      in BL1 just before handing over to BL31. At this point, the
      developer may take control of the target using a debugger.
      
      This feature is disabled by default and can be enabled by
      rebuilding BL1 with SPIN_ON_BL1_EXIT=1.
      
      User Guide updated accordingly.
      
      Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c
      35e8c766
  19. 02 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      Improve display_boot_progress() function · ee5c2b13
      Sandrine Bailleux authored
       - Remove out-dated information about the use of printf() in the
         function comment.
      
       - Make the argument const, as the function doesn't need to modify it.
      
       - Rename the function into bl1_print_bl31_ep_info() to make its
         purpose clearer.
      
      Change-Id: I2a9d215a37f0ec11aefce0c5c9e050473b7a6b25
      ee5c2b13
  20. 20 Oct, 2015 1 commit
    • Juan Castillo's avatar
      Add optional bl1_plat_prepare_exit() API · e3f67124
      Juan Castillo authored
      This patch adds an optional API to the platform port:
      
          void bl1_plat_prepare_exit(void);
      
      This function is called prior to exiting BL1 in response to the
      RUN_IMAGE_SMC request raised by BL2. It should be used to perform
      platform specific clean up or bookkeeping operations before
      transferring control to the next image.
      
      A weak empty definition of this function has been provided to
      preserve platform backwards compatibility.
      
      Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1
      e3f67124
  21. 19 Oct, 2015 1 commit
    • Sandrine Bailleux's avatar
      Break down BL1 AArch64 synchronous exception handler · 1fe4d453
      Sandrine Bailleux authored
      The AArch64 synchronous exception vector code in BL1 is almost
      reaching its architectural limit of 32 instructions. This means
      there is very little space for this code to grow.
      
      This patch reduces the size of the exception vector code by
      moving most of its code in a function to which we branch from
      SynchronousExceptionA64.
      
      Change-Id: Ib35351767a685fb2c2398029d32e54026194f7ed
      1fe4d453
  22. 04 Jun, 2015 2 commits
    • Sandrine Bailleux's avatar
      Introduce PROGRAMMABLE_RESET_ADDRESS build option · bf031bba
      Sandrine Bailleux authored
      This patch introduces a new platform build option, called
      PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
      a programmable or fixed reset vector address.
      
      If the reset vector address is fixed then the code relies on the
      platform_get_entrypoint() mailbox mechanism to figure out where
      it is supposed to jump. On the other hand, if it is programmable
      then it is assumed that the platform code will program directly
      the right address into the RVBAR register (instead of using the
      mailbox redirection) so the mailbox is ignored in this case.
      
      Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
      bf031bba
    • Sandrine Bailleux's avatar
      Rationalize reset handling code · 52010cc7
      Sandrine Bailleux authored
      The attempt to run the CPU reset code as soon as possible after reset
      results in highly complex conditional code relating to the
      RESET_TO_BL31 option.
      
      This patch relaxes this requirement a little. In the BL1, BL3-1 and
      PSCI entrypoints code, the sequence of operations is now as follows:
       1) Detect whether it is a cold or warm boot;
       2) For cold boot, detect whether it is the primary or a secondary
          CPU. This is needed to handle multiple CPUs entering cold reset
          simultaneously;
       3) Run the CPU init code.
      
      This patch also abstracts the EL3 registers initialisation done by
      the BL1, BL3-1 and PSCI entrypoints into common code.
      
      This improves code re-use and consolidates the code flows for
      different types of systems.
      
      NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
      NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
      FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
      OTHERWISE, SECONDARY CPUS WILL PANIC.
      
      Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
      52010cc7
  23. 08 Apr, 2015 1 commit
    • Kévin Petit's avatar
      Add support to indicate size and end of assembly functions · 8b779620
      Kévin Petit authored
      
      
      In order for the symbol table in the ELF file to contain the size of
      functions written in assembly, it is necessary to report it to the
      assembler using the .size directive.
      
      To fulfil the above requirements, this patch introduces an 'endfunc'
      macro which contains the .endfunc and .size directives. It also adds
      a .func directive to the 'func' assembler macro.
      
      The .func/.endfunc have been used so the assembler can fail if
      endfunc is omitted.
      
      Fixes ARM-Software/tf-issues#295
      
      Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
      Signed-off-by: default avatarKévin Petit <kevin.petit@arm.com>
      8b779620
  24. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
  25. 27 Aug, 2014 1 commit
  26. 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
  27. 15 Aug, 2014 1 commit
    • Achin Gupta's avatar
      Unmask SError interrupt and clear SCR_EL3.EA bit · 0c8d4fef
      Achin Gupta authored
      This patch disables routing of external aborts from lower exception levels to
      EL3 and ensures that a SError interrupt generated as a result of execution in
      EL3 is taken locally instead of a lower exception level.
      
      The SError interrupt is enabled in the TSP code only when the operation has not
      been directly initiated by the normal world. This is to prevent the possibility
      of an asynchronous external abort which originated in normal world from being
      taken when execution is in S-EL1.
      
      Fixes ARM-software/tf-issues#153
      
      Change-Id: I157b996c75996d12fd86d27e98bc73dd8bce6cd5
      0c8d4fef
  28. 28 Jul, 2014 1 commit
    • Achin Gupta's avatar
      Simplify management of SCTLR_EL3 and SCTLR_EL1 · ec3c1003
      Achin Gupta authored
      This patch reworks the manner in which the M,A, C, SA, I, WXN & EE bits of
      SCTLR_EL3 & SCTLR_EL1 are managed. The EE bit is cleared immediately after reset
      in EL3. The I, A and SA bits are set next in EL3 and immediately upon entry in
      S-EL1. These bits are no longer managed in the blX_arch_setup() functions. They
      do not have to be saved and restored either. The M, WXN and optionally the C
      bit are set in the enable_mmu_elX() function. This is done during both the warm
      and cold boot paths.
      
      Fixes ARM-software/tf-issues#226
      
      Change-Id: Ie894d1a07b8697c116960d858cd138c50bc7a069
      ec3c1003
  29. 19 Jul, 2014 1 commit
    • Achin Gupta's avatar
      Remove coherent stack usage from the cold boot path · 754a2b7a
      Achin Gupta authored
      This patch reworks the cold boot path across the BL1, BL2, BL3-1 and BL3-2 boot
      loader stages to not use stacks allocated in coherent memory for early platform
      setup and enabling the MMU. Stacks allocated in normal memory are used instead.
      
      Attributes for stack memory change from nGnRnE when the MMU is disabled to
      Normal WBWA Inner-shareable when the MMU and data cache are enabled. It is
      possible for the CPU to read stale stack memory after the MMU is enabled from
      another CPUs cache. Hence, it is unsafe to turn on the MMU and data cache while
      using normal stacks when multiple CPUs are a part of the same coherency
      domain. It is safe to do so in the cold boot path as only the primary cpu
      executes it. The secondary cpus are in a quiescent state.
      
      This patch does not remove the allocation of coherent stack memory. That is done
      in a subsequent patch.
      
      Change-Id: I12c80b7c7ab23506d425c5b3a8a7de693498f830
      754a2b7a
  30. 24 Jun, 2014 2 commits
  31. 23 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Initialise CPU contexts from entry_point_info · 167a9357
      Andrew Thoelke authored
      Consolidate all BL3-1 CPU context initialization for cold boot, PSCI
      and SPDs into two functions:
      *  The first uses entry_point_info to initialize the relevant
         cpu_context for first entry into a lower exception level on a CPU
      *  The second populates the EL1 and EL2 system registers as needed
         from the cpu_context to ensure correct entry into the lower EL
      
      This patch alters the way that BL3-1 determines which exception level
      is used when first entering EL1 or EL2 during cold boot - this is now
      fully determined by the SPSR value in the entry_point_info for BL3-3,
      as set up by the platform code in BL2 (or otherwise provided to BL3-1).
      
      In the situation that EL1 (or svc mode) is selected for a processor
      that supports EL2, the context management code will now configure all
      essential EL2 register state to ensure correct execution of EL1. This
      allows the platform code to run non-secure EL1 payloads directly
      without requiring a small EL2 stub or OS loader.
      
      Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f
      167a9357
  32. 22 May, 2014 3 commits
    • 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
      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