- 20 Mar, 2017 2 commits
-
-
Varun Wadekar authored
This patch programs the Memory controller's control registers to disable non-secure accesses to the TZRAM. In case these registers are already programmed by the BL2/BL30, then the driver just bails out. Change-Id: Ia1416988050e3d067296373060c717a260499122 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch adds driver for the Memory Controller (v2) in the newer Tegra SoCs. The newer hardware uses ARM's SMMU hardware instead of the proprietary block in the past. Change-Id: I78359da780dc840213b6e99954e45e34428d4fff Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 23 Feb, 2017 2 commits
-
-
Varun Wadekar authored
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>
-
Varun Wadekar authored
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>
-
- 22 Feb, 2017 1 commit
-
-
Varun Wadekar authored
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>
-
- 06 Feb, 2017 2 commits
-
-
Douglas Raillard authored
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>
-
Douglas Raillard authored
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>
-
- 25 Nov, 2015 1 commit
-
-
Varun Wadekar authored
This patch renames the tegra_fc_cpu_idle() function to a more appropriate tegra_fc_cpu_powerdn() to better reflect its usage. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 14 Sep, 2015 1 commit
-
-
Vikram Kanigiri authored
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
-
- 26 Aug, 2015 1 commit
-
-
Varun Wadekar authored
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>
-
- 17 Jul, 2015 3 commits
-
-
Varun Wadekar authored
The PMC Scratch22 register contains the CPU reset vector to be used by the warmboot code to power up the CPU while resuming from system suspend. This patch locks this PMC register to avoid any further writes. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch checks if the target CPU is already online before proceeding with it's power ON sequence. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch fixes the delay loop used to wake up the BPMP during SC7 exit. The earlier loop would fail just when the timer was about to wrap-around (e.g. when TEGRA_TMRUS_BASE is 0xfffffffe, the target value becomes 0, which would cause the loop to exit before it's expiry). Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 12 Jun, 2015 1 commit
-
-
Varun Wadekar authored
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>
-
- 29 May, 2015 1 commit
-
-
Varun Wadekar authored
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>
-