lkml.org 
[lkml]   [2017]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v2] Added "Preserve Boot Time Support"
Date
Hello,

Any input on this topic?

Kind Regards,
Bogdan

On Thursday, May 04, 2017 1:55 PM Bogdan Mirea wrote:
>
> Hi Oleksij,
>
> On Thursday, May 04, 2017 12:27 PM, Oleksij Rempel wrote:
> > Hi Bogdan,
> >
> > are there any example what and how bootloader should do to provide
> > correct values?
>
> I will give you an example with a real behavior on Renesas RCAR Gen3
> Salvator-x:
>
> We have an ARM64 SOC with the following boot stages:
> ARM Trusted Firmware BL2 -> ARM Trusted Firmware BL31 -> U-Boot -> Linux
>
> [First]
> On ARM Trusted Firmware BL31 "programs the CNTFRQ_EL0 register with the
> clock frequency of the system counter, which is provided by the
> platform"(Aarch64 Bl31 documentation [1]). And after this step the timer
> is up and running so every timer cycle is counted in the CCNT register.
>
> [Step A]
> After this step BL31 will load and start execution of U-Boot(BL33). In
> U-Boot we will spend for example 4 seconds and then load and start
> execution of Linux Kernel.
>
> [Step B]
> Linux Kernel starts and after kernel timer is initiallized the
> sched_clock_register will be called.
>
> [Step C]
> Testing with "$: uptime > /dev/kmsg"
>
>
>
> Test 1: Testing with default kernel (no patch added)
> Log will be:
> [Step A]
> [ 0.165573]
> [ 0.167127] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
> ...
> [ 4.364556]
> [ 4.366065] Starting kernel ...
>
> [Step B]
> ...
> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
> [ 0.000003] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
> every 2199023255496ns
> [ 0.000214] Console: colour dummy device 80x25
> [ 0.000594] console [tty0] enabled
> ...
> [Step C]
> $ uptime > /dev/kmsg
> [ 9.148458] 00:00:09 up 0 min, load average: 0.00, 0.00, 0.00
>
> There is no inconsistency between kmsg and uptime, but from [Step B] we
> observe that the time spent before kernel start is not added.
>
>
>
> Test 2: Testing only with preserve boot time "kernel/time/sched_clock"
> modifications:
> Log will be:
> [Step A]
> [ 0.164567]
> [ 0.166122] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
> ...
> [ 4.357793]
> [ 4.359301] Starting kernel ...
>
> [Step B]
> ...
> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
> [ 4.641512] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
> every 2199023255496ns
> [ 4.641724] Console: colour dummy device 80x25
> [ 4.642105] console [tty0] enabled
> ...
>
> [Step C]
> uptime > /dev/kmsg
> [ 13.933217] 00:00:09 up 0 min, load average: 0.00, 0.00, 0.00
>
> We can see that the preserve boottime changes in
> "kernel/time/sched_clock" updates the kmsg time [Step B], but there is
> an inconsistency between kmsg time and uptime since uptime is not
> updated accordingly to the timer's CCNT value [Step C]. The uptime
> starts from 0, and dt~=4sec inconsistency between kmsg and uptime is
> observable.
>
>
>
> Test 3: Testing with the full preserve boot time support with
> "kernel/time/sched_clock" and "drivers/clocksource/arm_arch_timer":
> Log will be:
> [Step A]
> [ 0.164564]
> [ 0.166119] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
> ...
> [ 4.357751]
> [ 4.359259] Starting kernel ...
> [Step B]
> ...
> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
> [ 4.638667] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
> every 2199023255496ns
> [ 4.638884] Console: colour dummy device 80x25
> [ 4.639265] console [tty0] enabled
> ...
>
> [Step C]
> $ uptime > /dev/kmsg
> [ 17.728591] 00:00:17 up 0 min, load average: 0.00, 0.00, 0.00
>
> We can observe that the patch updates kmsg time with the time spent
> before kernel starts [Step B]("kernel/time/sched_clock") and also
> updates kernel uptime("drivers/clocksource/arm_arch_timer") in [Step C]
> no inconsistency being present between kmsg and uptime.
>
>
> Best Regards,
> Bogdan
> [1]
> https://github.com/ARM-software/arm-trusted-
> firmware/blob/master/docs/firmware-design.md

\
 
 \ /
  Last update: 2017-05-16 10:23    [W:0.137 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site