Kever & Simon,
On 12 Sep 2017, at 14:30, Simon Glass sjg@chromium.org wrote:
Hi Kever,
On 11 September 2017 at 02:17, Kever Yang <kever.yang@rock-chips.com mailto:kever.yang@rock-chips.com> wrote:
Hi Simon,
On 09/08/2017 08:17 PM, Simon Glass wrote:
Hi Kever,
On 8 September 2017 at 01:34, Dr. Philipp Tomsich philipp.tomsich@theobroma-systems.com wrote:
On 8 Sep 2017, at 04:46, Kever Yang kever.yang@rock-chips.com wrote:
Philipp,
We already enable CONFIG_SPL_OF_CONTROL for all rk3399 board, right?
I meant “full OF_CONTROL” as opposed to “OF_PLATDATA” (which is dependent of OF_CONTROL, but is intended as a stopgap measure).
For OF_PLATDATA, I would prefer there always have a option to use for speed up the boot time, not only for ram size.
I had discussed that with Simon recently and he views OF_PLATDATA as a last resort to be used, when there is not enough memory for full OF_CONTROL.
Can you use bootstage to measure the boot time impact?
I think I have do the statistics before with the timer instead of bootstage. And here is the result I got with bootstage(with little change in spl to move secure_timer_init() before spl_early_init()):
The mark of end_spl: With of-pladata: 205952 205864 205857 without of-platdata: 279520 279495 279508
The difference is about 75ms.
That is enough to justify using of-platdata here. I am not sure why the difference is so large though.
I have noticed that the RK3399 U-Boot code does not clock up the boot CPU (i.e. rk3399_configure_cpu() is never called).
Could this be the reason for the large difference?
BTW: bug1: there is no timer_get_boot_us() in armv8, bug2: there is something wrong with "dm_spl", it use bootstage_start() + bootstage_accum() instead of bootstage_mark_name(), the "board_init_f" will replace it, maybe some tag is not correct.
OK. Do you think you could send patches to fix these?
I woul prefer if we could move the timer-code away from the generic timer and start using Rockchip-specific DM-timer drivers. This will make the U-Boot code independent of the initialisation of the secure-timer block…
Regards, Simon