1. 25 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Sanitise includes · bd9344f6
      Antonio Nino Diaz authored
      
      
      Use full include paths like it is done for common includes.
      
      This cleanup was started in commit d40e0e08283a ("Sanitise includes
      across codebase"), but it only cleaned common files and drivers. This
      patch does the same to Arm platforms.
      
      Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      bd9344f6
  2. 15 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Fix header dependencies · 234bc7f8
      Antonio Nino Diaz authored
      
      
      From now on, platform_def.h must include any header with definitions that
      are platform-specific (like arm_def.h) and the included headers mustn't
      include back platform_def.h, and shouldn't be used by other files. Only
      platform_def.h should be included in other files. This will ensure that all
      needed definitions are present, rather than needing to include all the
      headers in all the definitions' headers just in case.
      
      This also prevents problems like cyclic dependencies.
      
      Change-Id: I9d3cf4d1de4b956fa035c79545222697acdaf5ca
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      234bc7f8
  3. 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
  4. 26 Feb, 2018 3 commits
    • Soby Mathew's avatar
      Dynamic cfg: MISRA fixes · da5f2745
      Soby Mathew authored
      
      
      Change-Id: I1d85b76af002b8b672fcaeca94939b7420bc8243
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      da5f2745
    • Soby Mathew's avatar
      ARM Platforms: Load HW_CONFIG in BL2 · cab0b5b0
      Soby Mathew authored
      
      
      The patch adds the necessary changes to load HW_CONFIG in BL2 for
      ARM Platforms :
      
      1. The load address of HW_CONFIG is specified via the `hw_config_addr`
      property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size`
      property defines the maximum size to be expected for the HW_CONFIG.
      The `arm_dyn_cfg_helpers.c` and corresponding header implements
      utility functions to parse these DT properties defined.
      The `arm_dyn_cfg.c` implements wrappers to these helpers to enable
      them to be invoked from ARM platform layer.
      
      2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is
      the list of images to be loaded by BL2.
      
      3. The `libfdt` sources are now included when BL2 is built
      
      4. A new helper `populate_next_bl_params_config()` is introduced in
      desc_image_load.c to populate the subsequent executable BL images
      with the `hw_config` and the corresponding `fw_config` if available.
      The `plat_get_next_bl_params()` API for ARM platforms is modified to
      invoke this new helper.
      
      5. The implementation of `bl2_early_platform_setup2()` is modified to
      consider `arg0` as well in addition to `arg1` passed from BL1.
      
      6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt.
      
      Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      cab0b5b0
    • Soby Mathew's avatar
      ARM Platforms: Migrate to new BL handover interface · 0c306cc0
      Soby Mathew authored
      
      
      This patch migrates the ARM Standard platforms to the new BL
      handover interface. The arm_blx_early_platform_setup() functions
      are also modified to take in 4 arguments. The `ARM_BL31_PLAT_PARAM_VAL`
      value passed to BL31 from BL2 is now in arg3 in preparation of dynamic
      configuration arguments.
      
      Change-Id: I33e8e61325a19e7a7127b1ff203c3b86921bf153
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      0c306cc0
  5. 03 May, 2017 1 commit
  6. 20 May, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Replace SP804 timer by generic delay timer on FVP · 32cd95f0
      Antonio Nino Diaz authored
      Added a build flag to select the generic delay timer on FVP instead
      of the SP804 timer. By default, the generic one will be selected. The
      user guide has been updated.
      
      Change-Id: Ica34425c6d4ed95a187b529c612f6d3b26b78bc6
      32cd95f0
  7. 04 Dec, 2015 1 commit
    • Juan Castillo's avatar
      Fix SP804 delay timer on FVP · 540a5ba8
      Juan Castillo authored
      This patch fixes several issues with the SP804 delay timer on FVP:
      
      * By default, the SP804 dual timer on FVP runs at 32 KHz. In order
        to run the timer at 35 MHz (as specified in the FVP user manual)
        the Overwrite bit in the SP810 control register must be set.
      
      * The CLKMULT and CLKDIV definitions are mixed up:
      
            delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)
      
        From the delay function:
      
            delta_us = (delta * ops->clk_mult) / ops->clk_div;
      
        Matching both expressions:
      
            1 / f(MHz) = ops->clk_mult / ops->clk_div
      
        And consequently:
      
            f(MHz) = ops->clk_div / ops->clk_mult
      
        Which, for a 35 MHz timer, translates to:
      
            ops->clk_div = 35
            ops->clk_mult = 1
      
      * The comment in the delay timer header file has been corrected:
        The ratio of the multiplier and the divider is the clock period
        in microseconds, not the frequency.
      
      Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
      540a5ba8
  8. 18 Jun, 2015 1 commit
    • Ryan Harkin's avatar
      FVP: Add SP804 delay timer · b49b3221
      Ryan Harkin authored
      
      
      Add SP804 delay timer support to the FVP BSP.
      
      This commit simply provides the 3 constants needed by the SP804
      delay timer driver and calls sp804_timer_init() in
      bl2_platform_setup(). The BSP does not currently use the delay
      timer functions.
      
      Note that the FVP SP804 is a normal world accessible peripheral
      and should not be used by the secure world after transition
      to the normal world.
      
      Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
      Co-authored-by: default avatarDan Handley <dan.handley@arm.com>
      b49b3221
  9. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c
    • Dan Handley's avatar
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  10. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Remove use of PLATFORM_CACHE_LINE_SIZE · ce4c820d
      Dan Handley authored
      The required platform constant PLATFORM_CACHE_LINE_SIZE is
      unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
      same information. CACHE_WRITEBACK_GRANULE is preferred since this
      is an architecturally defined term and allows comparison with the
      corresponding hardware register value.
      
      Replace all usage of PLATFORM_CACHE_LINE_SIZE with
      CACHE_WRITEBACK_GRANULE.
      
      Also, add a runtime assert in BL1 to check that the provided
      CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
      
      Change-Id: If87286be78068424217b9f3689be358356500dcd
      ce4c820d
  11. 28 Jan, 2015 1 commit
  12. 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
  13. 21 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: map non-secure DRAM1 in the MMU · 6fd9eaf3
      Juan Castillo authored
      This patch maps the non-secure region of DRAM1 in the MMU. The
      non-secure region comprises the whole DRAM1 (0x80000000 -
      0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff).
      The TrustZone controller configures this 16 MB region as secure
      memory, so it can not be accessed in non-secure mode.
      
      The number of MMU tables in BL2 has been increased to 3 because
      the new size of the non-secure region in DRAM requires an extra L2
      table.
      
      Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
      6fd9eaf3
  14. 22 Oct, 2014 1 commit
    • Juan Castillo's avatar
      FVP: keep shared data in Trusted SRAM · 20d51cad
      Juan Castillo authored
      This patch deprecates the build option to relocate the shared data
      into Trusted DRAM in FVP. After this change, shared data is always
      located at the base of Trusted SRAM. This reduces the complexity
      of the memory map and the number of combinations in the build
      options.
      
      Fixes ARM-software/tf-issues#257
      
      Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
      20d51cad
  15. 14 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  16. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  17. 28 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Parametrize baudrate and UART clock during console_init() · 462c8350
      Soby Mathew authored
      This patch adds baud rate and UART clock frequency as parameters
      to the pl011 driver api console_init(). This allows each platform
      to specify UART clock and baud rate according to their specific
      hardware implementation.
      
      Fixes ARM-software/tf-issues#215
      
      Change-Id: Id13eef70a1c530e709b34dd1e6eb84db0797ced2
      462c8350
  18. 01 Jul, 2014 1 commit
    • 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
  19. 24 Jun, 2014 2 commits
  20. 05 Jun, 2014 1 commit
  21. 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
  22. 23 May, 2014 3 commits
    • 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
  23. 22 May, 2014 7 commits
    • 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
  24. 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
  25. 08 May, 2014 1 commit
    • Vikram Kanigiri's avatar
      Ensure a console is initialized before it is used · 770de65f
      Vikram Kanigiri authored
      This patch moves console_init() to bl32_early_platform_setup(). It
      also ensures that console_init() is called in each
      blX_early_platform_setup() function before the console is used
      e.g. through a printf call in an assert() statement.
      
      Fixes ARM-software/TF-issues#127
      
      Change-Id: I5b1f17e0152bab674d807d2a95ff3689c5d4794e
      770de65f
  26. 06 May, 2014 2 commits
    • 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
    • Dan Handley's avatar
      Always use named structs in header files · fb037bfb
      Dan Handley authored
      Add tag names to all unnamed structs in header files. This
      allows forward declaration of structs, which is necessary to
      reduce header file nesting (to be implemented in a subsequent
      commit).
      
      Also change the typedef names across the codebase to use the _t
      suffix to be more conformant with the Linux coding style. The
      coding style actually prefers us not to use typedefs at all but
      this is considered a step too far for Trusted Firmware.
      
      Also change the IO framework structs defintions to use typedef'd
      structs to be consistent with the rest of the codebase.
      
      Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f
      fb037bfb
  27. 24 Apr, 2014 1 commit
    • Harry Liebel's avatar
      Enable secure memory support for FVPs · f2199d95
      Harry Liebel authored
      - Use the TrustZone controller on Base FVP to program DRAM access
        permissions. By default no access to DRAM is allowed if
        'secure memory' is enabled on the Base FVP.
      - The Foundation FVP does not have a TrustZone controller but instead
        has fixed access permissions.
      - Update FDTs for Linux to use timers at the correct security level.
      - Starting the FVPs with 'secure memory' disabled is also supported.
      
      Limitations:
      Virtio currently uses a reserved NSAID. This will be corrected in
      future FVP releases.
      
      Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
      f2199d95