GitLab

This patch restores the TZRAM fence and the access permissions
on exiting the "System Suspend" state.

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

This patch enables L2 ECC and Parity Protection for ARM Cortex-A57 CPUs
for Tegra SoCs.

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

This patch modifies the secure IRQ registration process to allow platforms
to specify the target CPUs as well as the owner of the IRQ. IRQs "owned"
by the EL3 would return INTR_TYPE_EL3 whereas those owned by the Trusted
OS would return INTR_TYPE_S_EL1 as a result.

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

This patch adds a handler for FIQ interrupts triggered when
the CPU is in the NS world. The handler stores the NS world's
context along with ELR_EL3/SPSR_EL3.

The NS world driver issues an SMC initially to register it's
handler. The monitor firmware stores this handler address and
jumps to it when the FIQ interrupt fires. Upon entry into the
NS world the driver then issues another SMC to get the CPU
context when the FIQ fired. This allows the NS world driver to
determine the CPU state and call stack when the interrupt
fired. Generally, systems register watchdog interrupts as FIQs
which are then used to get the CPU state during hangs/crashes.

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

Tegra chips support multiple FIQ interrupt sources. These interrupts
are enabled in the GICD/GICC interfaces by the tegra_gic driver. A
new FIQ handler would be added in a subsequent change which can be
registered by the platform code.

This patch adds the GIC programming as part of the tegra_gic_setup()
which now takes an array of all the FIQ interrupts to be enabled for
the platform. The Tegra132 and Tegra210 platforms right now do not
register for any FIQ interrupts themselves, but will definitely use
this support in the future.

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

This patch adds a platform handler to calculate the proper target power
level at the specified affinity level.

Tegra platforms assign a local state value in order of decreasing depth
of the power state i.e. for two power states X & Y, if X < Y then X
represents a shallower power state than Y. As a result, the coordinated
target local power state for a power domain will be the maximum of the
requested local power state values.

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

This patch includes platform_def.h required to access UART macros -
"TEGRA_BOOT_UART_CLK_IN_HZ" and "TEGRA_CONSOLE_BAUDRATE" from
tegra_helpers.S.

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

This patch removes the restriction of allowing SiP calls only from the
non-secure world. The secure world can issue SiP calls as a result of
this patch now.

Change-Id: Idd64e893ae8e114bba0196872d3ec544cac150bf
Signed-off-by: Wayne Lin <wlin@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch adds a weak handler for early platform setup which
can be overriden by the soc-specific handlers to perform any
early setup tasks.

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

This patch adds support to relocate BL3-1 code to BL31_BASE in case
we cold boot to a different address. This is particularly useful to
maintain compatibility with legacy BL2 code.

This patch also checks to see if the image base address matches either
the TZDRAM or TZSRAM base.

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

This change disables the cache non-temporal hints for A57 and
A53 CPUs on Tegra.

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

Sorry to miss the security configuration for SRAM, if we don't support
it, somebody may modify the comment of SRAM in the non-secure space.
Let's fix this issue.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

This fixes code that set a tFC value in a register using the tRFC
value instead.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

The F1 CAS latency setting was not bit shifted, which resulted in
setting the DRAM additive latency value instead.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

On resume, we use the DFS hardware to switch frequency index,
followed by a full training sequence on that index. Leaving
the DFS training modules enabled causes issues with the full
training done at resume. We also only needs these enabled
during a call to ddr_set_rate during runtime, so there's no
issue disabling them at the end of ddr_set_rate.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

This moves the setting of the DQS drive strength to the M0 to minimize
the impact on DDR transactions. We need to have the DQS drive strength
changed for data training, which is triggered by the M0, but it also
needs to be changed back when data training is finished.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

This removes an optimization to not recalculate parameters if the
frequency index being switched to hold the next frequency. This is
because some registers do not have a copy per frequency index, so this
optimization might be causing problems.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

We were getting far off values on resume for the RX_CAL_DQS values.
This saves and restores the values for suspend/resume until the root
of the problem is figured out
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

These macros were accidentally deleted in a previous cleanup. This
slipped through because the code using them is currently unused, but
that may change in the future.
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch shuffles the M0 Makefile flags around a bit trying to make
their purpose clearer and remove duplication. Since all three build
steps (compiling, assembling, linking) actually call GCC, remove the
misleading aliases $(AS) and $(LD) to avoid confusion that those tools
might be called directly. Split flags into a common group that has
meaning for all three steps and separate variables specific to each
step. Remove -nostartfiles which is a strict subset of -nostdlib.

Also add explicit parameters for -mfloat-abi=soft, -fomit-frame-pointer
and -fno-common. If omitted these settings depend on the toolchain's
built-in default and cause various problems if they resolve to
unexpected values.
Signed-off-by: Julius Werner <jwerner@chromium.org>

The goal is that make clear the secure and SoC codes. Now cleaning them
will help secure code extensions for RK3399 in the future.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

Maybe the coreboot will reference the BL31 parameters (e.g the TZRAM_BASE
and TZRAM_SIZE for DDR secure regions), we can split them and don't have
to hardcode the range in two places.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

Move the BL31 loaded base address 0x10000 to 0x1000, and configure
the the memory range 0~1MB is secure, the goal is that make sure
the BL31 image will be not modified.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

So far, there are more and more features are supported on the RK3399,
meanwhile, these features are increasingly being defined and intertwined.
It's time to clean up and make them clearer.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

This removes waiting for vblank on the M0 during ddrfreq transitions.
That will now be done in the kernel to allow scheduling to be done on
the CPU core that changes the ddr frequency. Waiting for vblank in
the M0 would have the CPU core that waits on the M0 spin looping for
up to 16ms (1 frame for the display).
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

we will set PMU_CRU_GATEDIS_CON0 when idle port, it will enable
all clock, for save power consumption, we need to restore old value
when finish it.
Signed-off-by: Lin Huang <hl@rock-chips.com>

As rk3399 TRM1.1 document show, when set PMU_CRU_GATEDIS_CON0/1
register, it need set the write_mask bit (bit16 ~ bit31), but as
we test, it not need it. So need to correct the setting way, otherwise
it will set wrong value to this register.
Signed-off-by: Lin Huang <hl@rock-chips.com>

We found that the DUT will be hanged if we don't set the bit_1 of the
PMUCRU_GATEDIS_CON0. But, from the TRM, there is weird that the bit_1
is set the clk_center1_gating_dis, not clk_pmum0_gating_dis. Is the
TRM incorrect? We need to check it with the IC team and re-clean the
commit message and explain it tomorrow.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

This patch do following things:
1. Request hresetn_cm0s_pmu_req first then request
   poresetn_cm0s_pmu_req during M0 enable.
2. Do not diable M0 clock for ddr dvfs.
3. Correct the clk_pmum0_gating_dis bit, it is BIT0 not BIT1
4. do not set/clear hclk_noc_pmu_en in M0 code, it does not relate
   to the M0 clock.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

When vop is disabled and we read the vop register the system will
hang, so check vop status when we wait for the DMA finish flag to
avoid this sitiuation. This is done by checking for standby, DMA stop
mode, and disabled window states. Any one of these will prevent the
DMA finish flag from triggering.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

There is system timer in m0, we can use it to implement a set of
stopwatch functions for measuring timeouts.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

The phy pll needs to get 2X frequency to the DDR, so set the
pll_postdiv to 0.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

For ddr dfs stable, We need to enable ddr CA training
when do ddr dfs.
Signed-off-by: Lin Huang <hl@rock-chips.com>

This fixes a hang with setting the DRAM rate based on a race condition
with the M0 which sets the DRAM rate. The AP can also starve the M0,
so this also delays the AP reads to the DONE parameter for the M0.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

This enables per CS training at 666MHz and above for ddrfreq per
vendor recommendation. Since the threshold was used for latency was
the same value, this also adds a new value for that.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

This patch sets the frequency configuration of the next DRAM DFS index
to the configuration of the current index. This does not perform a
frequency transition. It just configures registers so the training on
resume for both indices will be correct.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

We used dcf do ddr frequency scaling, but we just include a dcf
binary, it hard to maintain later, we have M0 compile flow in ATF,
and M0 can also work for ddr frequency scaling, so let's use it.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

This makes the file consistently use tabs instead of mixing in spaces.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

Since the ATF project, we usually use the mmio_read_32 and
mmio_write_32. And the mmio_write_32, the firse parameter
is ADDR, the second is VALUE. In order to style consistency:

1/ rename readl/writel to mmio_read_32/mmio_write_32
2/ for keeping the same with mmio_write_32 in the ATF project,
   swap the order of the parameters for M0 mmio_write_32
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>

when dram frequency below 260MHz, phy master dll may unlock, so
let phy master dll working at dll bypass mode when frequency is
below 260MHz.
Signed-off-by: Lin Huang <hl@rock-chips.com>