Skip to content

GitLab

Switch branch/tag
  1. 26 Oct, 2017 1 commit
  3. 25 Oct, 2017 3 commits
  5. 24 Oct, 2017 1 commit
    • Etienne Carriere's avatar
      qemu: fix holding pen mailbox sequence · 33dd33f8
      Etienne Carriere authored 
      

Before this change, plat_secondary_cold_boot_setup reads wake up mailbox
as a byte array but through 64bit accesses on unaligned 64bit addresses.
In the other hand qemu_pwr_domain_on wakes secondary cores by writing
into a 64bit array.

This change forces the 64bit mailbox format as PLAT_QEMU_HOLD_ENTRY_SIZE
explicitly specifies it.
Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      33dd33f8
  7. 18 Oct, 2017 3 commits
  9. 17 Oct, 2017 3 commits
  11. 16 Oct, 2017 13 commits
  13. 13 Oct, 2017 2 commits
  15. 05 Oct, 2017 1 commit
    • Soby Mathew's avatar
      GICv3: add functions for save and restore · ebf1ca10
      Soby Mathew authored 
      

During system suspend, the GICv3 Distributor and Redistributor context
can be lost due to power gating of the system power domain. This means
that the GICv3 context needs to be saved prior to system suspend and
restored on wakeup. Currently the consensus is that the Firmware should
be in charge of this. See tf-issues#464 for more details.

This patch introduces helper APIs in the GICv3 driver to save and
restore the Distributor and Redistributor contexts. The GICv3 ITS
context is not considered in this patch because the specification says
that the details of ITS power management is implementation-defined.
These APIs are expected to be appropriately invoked by the platform
layer during system suspend.

Fixes ARM-software/tf-issues#464

Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      ebf1ca10
  17. 04 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      TSP: Support multi-threading CPUs on FVP · 5e4ca661
      Jeenu Viswambharan authored 
      Commit 11ad8f20

 added supporting
multi-threaded CPUs on FVP platform, including modifications for
calculating CPU IDs. This patch imports the strong definition of the
same CPU ID calculation on FVP platform for TSP.

Without this patch, TSP on FVP was using the default CPU ID calculation,
which would end up being wrong on CPUs with multi-threading.

Change-Id: If67fd492dfce1f57224c9e693988c4b0f89a9a9a
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      5e4ca661
  19. 27 Sep, 2017 1 commit
  21. 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
  23. 22 Sep, 2017 2 commits
  25. 21 Sep, 2017 2 commits
    • Sandrine Bailleux's avatar
      FVP: Include utils_def.h instead of utils.h · d08f8c6a
      Sandrine Bailleux authored 
      platform_def.h doesn't need all the definitions in utils.h,
the ones in utils_def.h are enough. This patch is related
to the changes introduced by commit 53d9c9c8

.

Change-Id: I4b2ff237a2d7fe07a7230e0e49b44b3fc2ca8abe
Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      d08f8c6a
    • Antonio Nino Diaz's avatar
      Fix type of `unsigned long` constants · e47ac1fd
      Antonio Nino Diaz authored 
      

The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
AArch64. This is inconsistent and that's why we avoid using it as per
the Coding Guidelines. This patch changes all `UL` occurrences to `U`
or `ULL` depending on the context so that the size of the constant is
clear.

This problem affected the macro `BIT(nr)`. As long as this macro is used
to fill fields of registers, that's not a problem, since all registers
are 32 bit wide in AArch32 and 64 bit wide in AArch64. However, if the
macro is used to fill the fields of a 64-bit integer, it won't be able
to set the upper 32 bits in AArch32.

By changing the type of this macro to `unsigned long long` the behaviour
is always the same regardless of the architecture, as this type is
64-bit wide in both cases.

Some Tegra platform files have been modified by this patch.

Change-Id: I918264c03e7d691a931f0d1018df25a2796cc221
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e47ac1fd
  27. 18 Sep, 2017 1 commit
  29. 13 Sep, 2017 2 commits
  31. 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
  33. 07 Sep, 2017 1 commit