- 24 Feb, 2017 24 commits
-
-
Derek Basehore authored
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>
-
Julius Werner authored
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>
-
Julius Werner authored
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>
-
Xing Zheng authored
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>
-
Xing Zheng authored
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>
-
Xing Zheng authored
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>
-
Xing Zheng authored
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>
-
Derek Basehore authored
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>
-
Lin Huang authored
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>
-
Lin Huang authored
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>
-
Xing Zheng authored
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>
-
Lin Huang authored
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>
-
Lin Huang authored
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>
-
Lin Huang authored
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>
-
Lin Huang authored
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>
-
Lin Huang authored
For ddr dfs stable, We need to enable ddr CA training when do ddr dfs. Signed-off-by: Lin Huang <hl@rock-chips.com>
-
Derek Basehore authored
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>
-
Derek Basehore authored
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>
-
Derek Basehore authored
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>
-
Xing Zheng authored
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>
-
Derek Basehore authored
This makes the file consistently use tabs instead of mixing in spaces. Signed-off-by: Derek Basehore <dbasehore@chromium.org>
-
Xing Zheng authored
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>
-
Derek Basehore authored
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>
-
Derek Basehore authored
we can reuse the dram config from loader, so we can remove dram_init() and dts_timing_receive() funciton in dram.c, add the dram_set_odt_pd() function to get the odt and auto power down parameter from kernel. This also removes the dcf_code_init function to allow the system to actually boot. Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Derek Basehore <dbasehore@chromium.org> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
-
- 31 Jan, 2017 1 commit
-
-
dp-arm authored
These are equivalent so use the reduced form. Change-Id: I40ca097411b9abab69985b8e4dbccf7582eae49e Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 26 Jan, 2017 1 commit
-
-
David Cunado authored
With GCC 6.2 compiler, more C undefined behaviour is being flagged as warnings, which result in build errors in ARM TF build. The specific issue that this patch resolves is the use of (1 << 31), which is predominantly used in case statements, where 1 is represented as a signed int. When shifted to msb the behaviour is undefined. The resolution is to specify 1 as an unsigned int using a convenience macro ULL(). A duplicate macro MAKE_ULL() is replaced. Fixes ARM-software/tf-issues#438 Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1 Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 24 Jan, 2017 4 commits
-
-
Koan-Sin Tan authored
Now it's possbile to build BL31 for MT8173 with ERROR_DEPRECATED=1. Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>
-
Koan-Sin Tan authored
Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>
-
Koan-Sin Tan authored
Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>
-
Koan-Sin Tan authored
make 'make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- PLAT=mt8173 ENABLE_PLAT_COMPAT=0' work. Change-Id: I13f35d8aef23dfa0e65883fa0be43f1513c9fef5 Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>
-
- 23 Jan, 2017 2 commits
-
-
Masahiro Yamada authored
One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. For AARCH32/AARCH64, these macros are defined in the top-level Makefile as follows: ifeq (${ARCH},aarch32) $(eval $(call add_define,AARCH32)) else $(eval $(call add_define,AARCH64)) endif This means only one of the two is defined. So, AARCH32/AARCH64 belongs to the latter group where we should use #ifdef or #ifndef. The conditionals are mostly coded correctly, but I see some mistakes. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 18 Jan, 2017 3 commits
-
-
Masahiro Yamada authored
I do not see any line that references BL32_SIZE. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
We have lots of duplicated defines (and comment blocks too). Move them to include/plat/common/common_def.h. While we are here, suffix the end address with _END instead of _LIMIT. The _END is a better fit to indicate the linker-derived real end address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The usage of _LIMIT seems odd here, so rename as follows: BL_CODE_LIMIT --> BL_CODE_END BL_RO_DATA_LIMIT --> BL_RO_DATA_END BL1_CODE_LIMIT --> BL1_CODE_END BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END Basically, we want to use _LIMIT and _END properly as follows: *_SIZE + *_MAX_SIZE = *_LIMIT *_SIZE + *_SIZE = *_END The _LIMIT is generally defined by platform_def.h to indicate the platform-dependent memory constraint. So, its typical usage is ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.") in a linker script. On the other hand, _END is used to indicate the end address of the compiled image, i.e. we do not know it until the image is linked. Here, all of these macros belong to the latter, so should be suffixed with _END. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 14 Jan, 2017 1 commit
-
-
Paul Kocialkowski authored
The actual length of the firmware is 1001 32 bit words. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
-
- 12 Jan, 2017 1 commit
-
-
Masahiro Yamada authored
We are duplicating this macro define, and it is useful enough to be placed in the common place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 06 Jan, 2017 1 commit
-
-
Soren Brinkmann authored
Commit 0029624f ("Add PLAT_xxx_ADDR_SPACE_SIZE definition") deprecates 'ADDR_SPACE_SIZE' in favor of PLAT_(PHY|VIRT)_ADDRESS_SPACE_SIZE. Migrate the zynqmp platform to use the new interface. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
-
- 04 Jan, 2017 1 commit
-
-
Patrick Georgi authored
Depending on the compiler used, it might try to link in libc even though it's not required. Stop it from doing that. Signed-off-by: Patrick Georgi <pgeorgi@google.com>
-
- 20 Dec, 2016 1 commit
-
-
Masahiro Yamada authored
The platform.mk sets build options required for ZynqMP, but users can still change them from the command line, like: make PLAT=zynqmp RESET_TO_BL31=0 CROSS_COMPILE=... Then, the makefile shows an error message in that case: Using BL31 as the reset vector is only one option supported on ZynqMP. Please set RESET_TO_BL31 to 1. If the option is not user-configurable, the makefile can specify "override" to prevent users from changing it. We do not need the error message for the case that never happens. Likewise, ENABLE_PLAT_COMPAT := 0 and PROGRAMMABLE_RESET_ADDRESS := 1 are mandatory to avoid build error. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
-