On Tue, 27 Mar 2018, Kever Yang wrote:
We use ARM generic timer.
A more enlightening commit message, please.
Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
See below for comments.
---
configs/lion-rk3368_defconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/configs/lion-rk3368_defconfig b/configs/lion-rk3368_defconfig
index 8a95ce3..89c4d76 100644
--- a/configs/lion-rk3368_defconfig
+++ b/configs/lion-rk3368_defconfig
@@ -88,10 +88,6 @@ CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_DEBUG_UART_SKIP_INIT=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
-CONFIG_TIMER=y
-CONFIG_SPL_TIMER=y
-CONFIG_TPL_TIMER=y
-CONFIG_ROCKCHIP_TIMER=y
NAK: The reason to not do this (and to have a DM time for the RK3368) has
been discussed, when we originally added this: SPL should not be specific
on the software stack.
Consider the following cases:
1. Boot to Linux (or U-Boot in EL2): this always includes an ATF as the
next-stage... so no need to setup the secure time here, as ATF will
take care of this anyway.
2. Boot to U-Boot in EL3 (e.g. from the Miniloader): we shouldn't rely on
the secure time having been set up (but U-Boot can't do it either, as
the same binary could either run at EL3 or at EL2).
So the consensus was to not have U-Boot rely on the secure timer to be
initialised... especially, as it doesn't have to rely on this.
Note that this is also true for the RK3399, but I need to finish up
further changes to the DRAM init code, as that currently relies on having
a timebase before the DM timer is available.
CONFIG_USE_TINY_PRINTF=y
CONFIG_SPL_TINY_MEMSET=y
CONFIG_LZO=y
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
