[U-Boot] [U-Boot, 30/36] rockchip: lion-rk3368: remove rockchip timer

[Philipp Tomsich]

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.yang at 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
>