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

[Kever Yang]

On 04/02/2018 05:34 AM, Philipp Tomsich wrote:
>
>
> 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).
>

I'm sure(and we have to make sure) the secure timer have been set up before
U-Boot proper, no matter who do it(SPL/miniloader/trust), because kernel is
always using ARM generic timer as clock source. If the kernel can rely
on it,
then U-Boot can rely on it.

In rockchip binaries, ddr.bin will do setup the secure timer and in
U-Boot project,
SPL or TPL need to do this.

You can still use rockchip timer as DM timer for lion-rk3368, although I
prefer
all SoCs/boards to use the timer in a same way.

Thanks,
- Kever
> 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
>>
>