Skip to content

GitLab

Switch branch/tag
  1. 18 Jan, 2018 2 commits
    • Roberto Vargas's avatar
      bl2-el3: Add BL2 at EL3 support in FVP · 81528dbc
      Roberto Vargas authored 
      

This patch add supports for the new API added for BL2 at EL3 for
FVP. We don't have a non-TF Boot ROM for FVP, but this option can be
tested setting specific parameters in the model.

The bl2 image is loaded directly in memory instead of being loaded
by a non-TF Boot ROM and the reset address is changed:

	--data cluster0.cpu0=bl2.bin@0x4001000
	-C cluster0.cpu0.RVBAR=0x4001000

These parameters mean that in the cold boot path the processor will
jump to BL2 again. For this reason, BL2 is loaded in dram in this
case, to avoid other images reclaiming BL2 memory.

Change-Id: Ieb2ff8535a9e67ccebcd8c2212cad366e7776422
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      81528dbc
    • Roberto Vargas's avatar
      bl2-el3: Add BL2_EL3 image · b1d27b48
      Roberto Vargas authored 
      

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
stages without need for BL1.  This is not currently possible because
BL2 executes at S-EL1 and cannot jump straight to EL3.

Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b1d27b48
  3. 11 Jan, 2018 1 commit
  5. 03 Jan, 2018 1 commit
  7. 19 Dec, 2017 1 commit
  9. 06 Dec, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Move S-EL1/S-EL0 xlat tables to TZC DRAM · 45d640f0
      Antonio Nino Diaz authored 
      

A new platform define, `PLAT_SP_IMAGE_XLAT_SECTION_NAME`, has been
introduced to select the section where the translation tables used by
the S-EL1/S-EL0 are placed.

This define has been used to move the translation tables to DRAM secured
by TrustZone.

Most of the extra needed space in BL31 when SPM is enabled is due to the
large size of the translation tables. By moving them to this memory
region we can save 44 KiB.

A new argument has been added to REGISTER_XLAT_CONTEXT2() to specify the
region where the translation tables have to be placed by the linker.

Change-Id: Ia81709b4227cb8c92601f0caf258f624c0467719
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      45d640f0
  11. 29 Nov, 2017 2 commits
    • Soby Mathew's avatar
      ARM platforms: Fixup AArch32 builds · 5744e874
      Soby Mathew authored 
      

This patch fixes a couple of issues for AArch32 builds on ARM reference
platforms :

1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
   AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
   the BL31 memory is empty when built for AArch32. Hence this patch allocates
   BL32 to the memory region occupied by BL31 for AArch32 builds.

   As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
   be used to control the load address of BL32 in AArch32 mode which was
   never the intention of the macro anyway.

2. A static assert is added to sp_min linker script to check that the progbits
   are within the bounds expected when overlaid with other images.

3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
   involved when building Juno for AArch32 mode, the build option SPD needed to
   specifed. This patch corrects this and also updates the documentation in the
   user-guide.

4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
   a result the previous assumption that BL31 must be always present is removed
   and the certificates for BL31 is only generated if `NEED_BL31` is defined.

Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5744e874
    • Antonio Nino Diaz's avatar
      Replace magic numbers in linkerscripts by PAGE_SIZE · a2aedac2
      Antonio Nino Diaz authored 
      

When defining different sections in linker scripts it is needed to align
them to multiples of the page size. In most linker scripts this is done
by aligning to the hardcoded value 4096 instead of PAGE_SIZE.

This may be confusing when taking a look at all the codebase, as 4096
is used in some parts that aren't meant to be a multiple of the page
size.

Change-Id: I36c6f461c7782437a58d13d37ec8b822a1663ec1
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      a2aedac2
  13. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored 
      

Factor out SPE operations in a separate file.  Use the publish
subscribe framework to drain the SPE buffers before entering secure
world.  Additionally, enable SPE before entering normal world.

A side effect of this change is that the profiling buffers are now
only drained when a transition from normal world to secure world
happens.  Previously they were drained also on return from secure
world, which is unnecessary as SPE is not supported in S-EL1.

Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  15. 13 Nov, 2017 5 commits
  17. 09 Nov, 2017 1 commit
  19. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored 
      

A Secure Partition is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security
services. Since S-EL0 is an unprivileged exception level, a Secure
Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
granted access to system and processor resources. Essentially, it is a
software sandbox that runs under the control of privileged software in
the Secure World and accesses the following system resources:

- Memory and device regions in the system address map.
- PE system registers.
- A range of asynchronous exceptions e.g. interrupts.
- A range of synchronous exceptions e.g. SMC function identifiers.

A Secure Partition enables privileged firmware to implement only the
absolutely essential secure services in EL3 and instantiate the rest in
a partition. Since the partition executes in S-EL0, its implementation
cannot be overly complex.

The component in ARM Trusted Firmware responsible for managing a Secure
Partition is called the Secure Partition Manager (SPM). The SPM is
responsible for the following:

- Validating and allocating resources requested by a Secure Partition.
- Implementing a well defined interface that is used for initialising a
  Secure Partition.
- Implementing a well defined interface that is used by the normal world
  and other secure services for accessing the services exported by a
  Secure Partition.
- Implementing a well defined interface that is used by a Secure
  Partition to fulfil service requests.
- Instantiating the software execution environment required by a Secure
  Partition to fulfil a service request.

Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  21. 25 Oct, 2017 1 commit
  23. 24 Oct, 2017 1 commit
  25. 16 Oct, 2017 11 commits
  27. 11 Oct, 2017 2 commits
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored 
      

Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
arm_system_pwr_domain_save functions.

Introduce FVP PSCI power level 3 (System level) support. This is solely
done to provide example code on how to use the GICv3 save and restore
helpers.

Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
SUSPEND as its state is saved and restored.

Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
    • Soby Mathew's avatar
      ARM platforms: Add support for EL3 TZC memory region · a22dffc6
      Soby Mathew authored 
      

Some recent enhancements to EL3 runtime firmware like support for
save and restoring GICv3 register context during system_suspend
necessitates additional data memory for the firmware. This patch
introduces support for creating a TZC secured DDR carveout for use
by ARM reference platforms. A new linker section `el3_tzc_dram` is
created using platform supplied linker script and data marked with
the attribute `arm_el3_tzc_dram` will be placed in this section.
The FVP makefile now defines the `PLAT_EXTRA_LD_SCRIPT` variable to
allow inclusion of the platform linker script by the top level BL31
linker script.

Change-Id: I0e7f4a75a6ac51419c667875ff2677043df1585d
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a22dffc6
  29. 06 Oct, 2017 1 commit
    • David Cunado's avatar
      Increase PLAT_ARM_MMAP_ENTRIES and MAX_XLAT_TABLES · 2e421ad2
      David Cunado authored 
      

The MEM_PROTECT support adds a MMAP region for DRAM2, which when
building with TBBR support and OP-TEE tsp requires an additional
entry in the MMAP region array in BL2 - PLAT_ARM_MMAP_ENTRIES is
increased.

The MEM_PROTECT support also adds a new region in BL31, and when
BL31 is placed in DRAM, the memory mappings require an additional
translation table - MAX_XLAT_TABLES is increased.

Change-Id: I0b76260da817dcfd0b8f73a7193c36efda977625
Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      2e421ad2
  31. 25 Sep, 2017 2 commits
    • Roberto Vargas's avatar
      mem_protect: Add DRAM2 to the list of mem protected ranges · b09ba056
      Roberto Vargas authored 
      

On ARM platforms, the maximum size of the address space is limited
to 32-bits as defined in arm_def.h. In order to access DRAM2, which
is defined beyond the 32-bit address space, the maximum address space
is increased to 36-bits in AArch64. It is possible to increase the
virtual space for AArch32, but it is more difficult and not supported
for now.

NOTE - the actual maximum memory address space is platform dependent
and is checked at run-time by querying the PARange field in the
ID_AA64MMFR0_EL1 register.

Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b09ba056
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored 
      

mem_protect needs some kind of non-volatile memory because it has
to remember its state across reset and power down events.
The most suitable electronic part for this feature is a NVRAM
which should be only accesible from the secure world. Juno and
FVP lack such hardware and for this reason the MEM_PROTECT
functionality is implemented with Flash EEPROM memory on both
boards, even though this memory is accesible from the non-secure
world. This is done only to show a full implementation of
these PSCI features, but an actual system shouldn't use a
non-secure NVRAM to implement it.

The EL3 runtime software will write the mem_protect flag and BL2
will read and clear the memory ranges if enabled. It is done in
BL2 because it reduces the time that TF needs access to the full
non-secure memory.

The memory layout of both boards is defined using macros which
take different values in Juno and FVP platforms. Generic platform
helpers are added that use the platform specific macros to generate
a mem_region_t that is valid for the platform.

Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  33. 22 Sep, 2017 1 commit
  35. 12 Sep, 2017 1 commit
    • Qixiang Xu's avatar
      plat/arm: Fix BL31_BASE when RESET_TO_BL31=1 · fd5763ea
      Qixiang Xu authored 
      

The value of BL31_BASE currently depends on the size of BL31. This
causes problems in the RESET_TO_BL31 case because the value of
BL31_BASE is used in the model launch parameters, which often changes.

Therefore, this patch fixes BL31_BASE to the middle of Trusted SRAM,
to avoid further model parameter changes in future.

Change-Id: I6d7fa4fe293717d84768974679539c0e0cb6d935
Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      fd5763ea
  37. 11 Sep, 2017 1 commit
    • Soby Mathew's avatar
      Implement log framework · 7f56e9a3
      Soby Mathew authored 
      

This patch gives users control over logging messages printed from the C
code using the LOG macros defined in debug.h Users now have the ability
to reduce the log_level at run time using the tf_log_set_max_level()
function. The default prefix string can be defined by platform by
overriding the `plat_log_get_prefix()` platform API which is also
introduced in this patch.

The new log framework results in saving of some RO data. For example,
when BL1 is built for FVP with LOG_LEVEL=LOG_LEVEL_VERBOSE, resulted
in saving 384 bytes of RO data and increase of 8 bytes of RW data. The
framework also adds about 108 bytes of code to the release build of FVP.

Fixes ARM-software/tf-issues#462

Change-Id: I476013d9c3deedfdd4c8b0b0f125665ba6250554
Co-authored-by: default avatarEleanor Bonnici <Eleanor.bonnici@arm.com>
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      7f56e9a3
  39. 06 Sep, 2017 2 commits
    • Soby Mathew's avatar
      CSS: Changes for SDS framework · 18e279eb
      Soby Mathew authored 
      

This patch does the required changes to enable CSS platforms
to build and use the SDS framework. Since SDS is always coupled with
SCMI protocol, the preexisting SCMI build flag is now renamed to
`CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on
CSS platforms. Also some of the workarounds applied for SCMI are
now removed with SDS in place.

Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      18e279eb
    • Soby Mathew's avatar
      Fix JUNO AArch32 build · ba6c31da
      Soby Mathew authored 
      

This patch fixes the inconsistency with regards as to how
BL2_BASE/BL2U_BASE and BL2_LIMIT/BL2U_LIMIT macros are defined
when building Juno to run in AArch32 mode at EL3. In this case,
BL32 is compiled for AArch32 whereas BL1 and BL2 are compiled
for AArch64. This resulted in BL32 conditionally compiling a
different definition of the above mentioned macros from BL1/BL2.
This is fixed by taking into consideration the
JUNO_AARCH32_EL3_RUNTIME build flag as well in the conditional
compilation check.

Change-Id: I27ac68aa4df0502089c1739c05366a9c509eb5be
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      ba6c31da
  41. 05 Sep, 2017 1 commit