GitLab

This patch moves the chip specific memory controller driver defines to
the appropriate tegra_def.h files, for future compatibility.

Change-Id: I3179fb771d8b32e913ca29bd94af95f4b2fc1961
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch uses the Memory controller driver's handler to restore
its settings and moves the other chip specific code to their own
'pwr_domain_on_finish' handlers.

Change-Id: I3c9d23bdab9e2e3c05034ff6812cf941ccd7a75e
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch introduces a function to secure the on-chip TZRAM memory. The
Tegra132 and Tegra210 chips do not have a compelling use case to lock the
TZRAM. The trusted OS owns the TZRAM aperture on these chips and so it
can take care of locking the aperture. This might not be true for future
chips and this patch makes the TZRAM programming flexible.

Change-Id: I3ac9f1de1b792ccd23d4ded274784bbab2ea224a
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch renames the current Memory Controller driver files to
"_v1". This is done to add a driver for the new Memory Controller
hardware (v2).

Change-Id: I668dbba42f6ee0db2f59a7103f0ae7e1d4684ecf
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Replace all use of memset by zeromem when zeroing moderately-sized
structure by applying the following transformation:
memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))

As the Trusted Firmware is compiled with -ffreestanding, it forbids the
compiler from using __builtin_memset and forces it to generate calls to
the slow memset implementation. Zeromem is a near drop in replacement
for this use case, with a more efficient implementation on both AArch32
and AArch64.

Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Introduce zeromem_dczva function on AArch64 that can handle unaligned
addresses and make use of DC ZVA instruction to zero a whole block at a
time. This zeroing takes place directly in the cache to speed it up
without doing external memory access.

Remove the zeromem16 function on AArch64 and replace it with an alias to
zeromem. This zeromem16 function is now deprecated.

Remove the 16-bytes alignment constraint on __BSS_START__ in
firmware-design.md as it is now not mandatory anymore (it used to comply
with zeromem16 requirements).

Change the 16-bytes alignment constraints in SP min's linker script to a
8-bytes alignment constraint as the AArch32 zeromem implementation is now
more efficient on 8-bytes aligned addresses.

Introduce zero_normalmem and zeromem helpers in platform agnostic header
that are implemented this way:
* AArch32:
	* zero_normalmem: zero using usual data access
	* zeromem: alias for zero_normalmem
* AArch64:
	* zero_normalmem: zero normal memory  using DC ZVA instruction
	                  (needs MMU enabled)
	* zeromem: zero using usual data access

Usage guidelines: in most cases, zero_normalmem should be preferred.

There are 2 scenarios where zeromem (or memset) must be used instead:
* Code that must run with MMU disabled (which means all memory is
  considered device memory for data accesses).
* Code that fills device memory with null bytes.

Optionally, the following rule can be applied if performance is
important:
* Code zeroing small areas (few bytes) that are not secrets should use
  memset to take advantage of compiler optimizations.

  Note: Code zeroing security-related critical information should use
  zero_normalmem/zeromem instead of memset to avoid removal by
  compilers' optimizations in some cases or misbehaving versions of GCC.

Fixes ARM-software/tf-issues#408

Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Currently, the non-overlapping video memory carveout region is cleared after
disabling the MMU at EL3. If at any exception level the carveout region is being
marked as cacheable, this zeroing of memory will not have an affect on the
cached lines. Hence, we first invalidate the dirty lines and update the memory
and invalidate again so that both caches and memory is zeroed out.

Change-Id: If3b2d139ab7227f6799c0911d59e079849dc86aa

The previous logic in the memctrl driver was not catering to cases
where the new memory region lied inside the older region. This patch
fixes the if/elseif/elseif logic in the driver to take care of this
case.

Reported by: Vikram Kanigiri <vikram.kanigiri@arm.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch adds support to reserve a memory carveout region in the
DRAM on Tegra SoCs. The memory controller provides specific registers
to specify the aperture's base and size. This aperture can also be
changed dynamically in order to re-size the memory available for
DRM video playback. In case of the new aperture not overlapping
the previous one, the previous aperture has to be cleared before
setting up the new one. This means we do not "leak" any video data
to the NS world.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

T210 is the latest chip in the Tegra family of SoCs from NVIDIA. It is an
ARM v8 dual-cluster (A57/A53) SoC, with any one of the clusters being active
at a given point in time.

This patch adds support to boot the Trusted Firmware on T210 SoCs. The patch
also adds support to boot secondary CPUs, enter/exit core power states for
all CPUs in the slow/fast clusters. The support to switch between clusters
is still not available in this patch and would be available later.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>