[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[vinoth eswaran]

Hello Developers,

  Currently I am working on an embedded project using Tegra Jetson Tk1
board. The Linux Kernel version is 4.7 and the u-boot version is v2016.05.
I am building a customised Linux kernel and u-boot to have the fastest boot
time possible.

During Kernel startup I am seeing some error messages related to CPU clock
frequencies like,

[    0.000000] Tegra clk 127: register failed with -17

[    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
696000 KHz
[    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
changed to: 714000 KHz

On seeing the bootchart I have a feeling that the cpu clock frequency might
be low - as lot of drivers are taking more time than usual, so I now wish
to know what frequency does the cpu cores are running on during boot time.
I am not clear on who is responsible(u-boot/kernel) for setting up the cpu
clock frequency during the boot time.

In u-boot which modules do I need to look to get information about cpu
frequency being set.

Thanks & Regards,
Vinothkumar

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[Stephen Warren]

On 08/22/2016 08:37 AM, vinoth eswaran wrote:
> Hello Developers,
>
>   Currently I am working on an embedded project using Tegra Jetson Tk1
> board. The Linux Kernel version is 4.7 and the u-boot version is v2016.05.
> I am building a customised Linux kernel and u-boot to have the fastest boot
> time possible.
>
> During Kernel startup I am seeing some error messages related to CPU clock
> frequencies like,
>
> [    0.000000] Tegra clk 127: register failed with -17
>
> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
> 696000 KHz
> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
> changed to: 714000 KHz
>
> On seeing the bootchart I have a feeling that the cpu clock frequency might
> be low - as lot of drivers are taking more time than usual, so I now wish
> to know what frequency does the cpu cores are running on during boot time.
> I am not clear on who is responsible(u-boot/kernel) for setting up the cpu
> clock frequency during the boot time.
>
> In u-boot which modules do I need to look to get information about cpu
> frequency being set.

This all happens on SoC-specific code; take a look at arch/arm/mach-tegra/.

I don't immediately see anything that sets a particular clock rate for 
the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. 
I'm CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in 
arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL 
clock rates. However, I can't guarantee it'll print the correct rates; 
it's debug code that was added early on (i.e. prior to Tegra124 support 
being added) so it's possible it hasn't been updated to get the correct 
answer on more recent SoCs. Oh, and IIRC the CPU can run on either PLL_X 
or some other PLL. You'd need to check which clock source is in use by 
reading the CAR registers; see the TRM for details of the CAR.

Also note that the memory controller clock likely boots at a non-maximal 
rate. This is controlled by the BCT.

Typically both the CPU clock and memory controller clock run at 
non-maximal rates at boot time, and hence during U-Boot. That's because 
using higher rates may (a) require PMIC programming, and (b) not be safe 
without active thermal management. I don't remember which 
frequency/voltage combinations are legal/tested/thermally-safe. If you 
need more details here, the NVIDIA L4T web forums are the best place to 
get answers; visit http://developer.nvidia.com/embedded-computing the 
follow the community link, then follow the forum link.

Once the kernel boots, it is responsible for any clock management. If 
higher-than-default clocks are required, the kernel is responsible for 
selecting these.

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[vinoth eswaran]

On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>
>> Hello Developers,
>>
>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>> board. The Linux Kernel version is 4.7 and the u-boot version is v2016.05.
>> I am building a customised Linux kernel and u-boot to have the fastest boot
>> time possible.
>>
>> During Kernel startup I am seeing some error messages related to CPU clock
>> frequencies like,
>>
>> [    0.000000] Tegra clk 127: register failed with -17
>>
>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>> 696000 KHz
>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
>> changed to: 714000 KHz
>>
>> On seeing the bootchart I have a feeling that the cpu clock frequency might
>> be low - as lot of drivers are taking more time than usual, so I now wish
>> to know what frequency does the cpu cores are running on during boot time.
>> I am not clear on who is responsible(u-boot/kernel) for setting up the cpu
>> clock frequency during the boot time.
>>
>> In u-boot which modules do I need to look to get information about cpu
>> frequency being set.
>
>
> This all happens on SoC-specific code; take a look at arch/arm/mach-tegra/.
>
> I don't immediately see anything that sets a particular clock rate for the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. I'm CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL clock rates. However, I can't guarantee it'll print the correct rates; it's debug code that was added early on (i.e. prior to Tegra124 support being added) so it's possible it hasn't been updated to get the correct answer on more recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other PLL. You'd need to check which clock source is in use by reading the CAR registers; see the TRM for details of the CAR.
>
> Also note that the memory controller clock likely boots at a non-maximal rate. This is controlled by the BCT.
>
> Typically both the CPU clock and memory controller clock run at non-maximal rates at boot time, and hence during U-Boot. That's because using higher rates may (a) require PMIC programming, and (b) not be safe without active thermal management. I don't remember which frequency/voltage combinations are legal/tested/thermally-safe. If you need more details here, the NVIDIA L4T web forums are the best place to get answers; visit http://developer.nvidia.com/embedded-computing the follow the community link, then follow the forum link.
>
> Once the kernel boots, it is responsible for any clock management. If higher-than-default clocks are required, the kernel is responsible for selecting these.

After enabling the debug messages in clock.c and tegra124/clock.c I am
seeing the following messages during u-boot start up.

get_pll: Invalid PLL 6
Osc = 12000000
CLKM = 12000000
PLLC = 88000000
PLLM = 924000000
PLLP = 408000000
PLLU = 960000000
PLLD = 925000000
PLLX = 0
PLLP 5801980c is correct
periph 47, rate=6400000, reg=60006128 = 7e
Requested clock rate 6400000 not honored (got 6375000)
periph 47, rate=166400000, reg=60006128 = 3
Requested clock rate 166400000 not honored (got 163200000)
MC:   board_mmc_init called
board_mmc_init: init MMC
periph 15, rate=20000000, reg=60006164 = 27
Requested clock rate 20000000 not honored (got 19902439)
periph 69, rate=20000000, reg=600061bc = 27
Requested clock rate 20000000 not honored (got 19902439)
Tegra SD/MMC: 0, Tegra SD/MMC: 1
periph 15, rate=375000, reg=60006164 = 86
periph 15, rate=375000, reg=60006164 = 86
periph 15, rate=48000000, reg=60006164 = f

I am seeing lot of requested clock rates are not honored, which I
assume to be meaning unable to set to the requested clock frequency
and other frequencies being set.
which is the frequency it is currently running on?

Thanks & Regards,
Vinothkumar

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[Stephen Warren]

On 08/23/2016 06:23 AM, vinoth eswaran wrote:
> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>
>>> Hello Developers,
>>>
>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>> board. The Linux Kernel version is 4.7 and the u-boot version is v2016.05.
>>> I am building a customised Linux kernel and u-boot to have the fastest boot
>>> time possible.
>>>
>>> During Kernel startup I am seeing some error messages related to CPU clock
>>> frequencies like,
>>>
>>> [    0.000000] Tegra clk 127: register failed with -17
>>>
>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>>> 696000 KHz
>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
>>> changed to: 714000 KHz
>>>
>>> On seeing the bootchart I have a feeling that the cpu clock frequency might
>>> be low - as lot of drivers are taking more time than usual, so I now wish
>>> to know what frequency does the cpu cores are running on during boot time.
>>> I am not clear on who is responsible(u-boot/kernel) for setting up the cpu
>>> clock frequency during the boot time.
>>>
>>> In u-boot which modules do I need to look to get information about cpu
>>> frequency being set.
>>
>>
>> This all happens on SoC-specific code; take a look at arch/arm/mach-tegra/.
>>
>> I don't immediately see anything that sets a particular clock rate for the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. I'm CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL clock rates. However, I can't guarantee it'll print the correct rates; it's debug code that was added early on (i.e. prior to Tegra124 support being added) so it's possible it hasn't been updated to get the correct answer on more recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other PLL. You'd need to check which clock source is in use by reading the CAR registers; see the TRM for details of the CAR.
>>
>> Also note that the memory controller clock likely boots at a non-maximal rate. This is controlled by the BCT.
>>
>> Typically both the CPU clock and memory controller clock run at non-maximal rates at boot time, and hence during U-Boot. That's because using higher rates may (a) require PMIC programming, and (b) not be safe without active thermal management. I don't remember which frequency/voltage combinations are legal/tested/thermally-safe. If you need more details here, the NVIDIA L4T web forums are the best place to get answers; visit http://developer.nvidia.com/embedded-computing the follow the community link, then follow the forum link.
>>
>> Once the kernel boots, it is responsible for any clock management. If higher-than-default clocks are required, the kernel is responsible for selecting these.
>
> After enabling the debug messages in clock.c and tegra124/clock.c I am
> seeing the following messages during u-boot start up.
>
...
> PLLX = 0
...
> periph 47, rate=6400000, reg=60006128 = 7e
> Requested clock rate 6400000 not honored (got 6375000)
...
> I am seeing lot of requested clock rates are not honored, which I
> assume to be meaning unable to set to the requested clock frequency
> and other frequencies being set.

Yes, the clock dividers can't generate every possible frequency, so they 
generate the closest possible value and emit a debug message just as a 
note. You can ignore these.

> which is the frequency it is currently running on?

PLLX = 0 above is obviously wrong. The only way to find out is to 
manually trace through the CAR registers to find the source the CPU is 
hooked to, and then trace through all the dividers.

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[vinoth eswaran]

On Tue, Aug 23, 2016 at 6:09 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/23/2016 06:23 AM, vinoth eswaran wrote:
>>
>> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>>
>>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>>
>>>>
>>>> Hello Developers,
>>>>
>>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>>> board. The Linux Kernel version is 4.7 and the u-boot version is
>>>> v2016.05.
>>>> I am building a customised Linux kernel and u-boot to have the fastest
>>>> boot
>>>> time possible.
>>>>
>>>> During Kernel startup I am seeing some error messages related to CPU
>>>> clock
>>>> frequencies like,
>>>>
>>>> [    0.000000] Tegra clk 127: register failed with -17
>>>>
>>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>>>> 696000 KHz
>>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
>>>> changed to: 714000 KHz
>>>>
>>>> On seeing the bootchart I have a feeling that the cpu clock frequency
>>>> might
>>>> be low - as lot of drivers are taking more time than usual, so I now
>>>> wish
>>>> to know what frequency does the cpu cores are running on during boot
>>>> time.
>>>> I am not clear on who is responsible(u-boot/kernel) for setting up the
>>>> cpu
>>>> clock frequency during the boot time.
>>>>
>>>> In u-boot which modules do I need to look to get information about cpu
>>>> frequency being set.
>>>
>>>
>>>
>>> This all happens on SoC-specific code; take a look at
>>> arch/arm/mach-tegra/.
>>>
>>> I don't immediately see anything that sets a particular clock rate for
>>> the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. I'm
>>> CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in
>>> arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL clock
>>> rates. However, I can't guarantee it'll print the correct rates; it's debug
>>> code that was added early on (i.e. prior to Tegra124 support being added) so
>>> it's possible it hasn't been updated to get the correct answer on more
>>> recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other PLL.
>>> You'd need to check which clock source is in use by reading the CAR
>>> registers; see the TRM for details of the CAR.
>>>
>>> Also note that the memory controller clock likely boots at a non-maximal
>>> rate. This is controlled by the BCT.
>>>
>>> Typically both the CPU clock and memory controller clock run at
>>> non-maximal rates at boot time, and hence during U-Boot. That's because
>>> using higher rates may (a) require PMIC programming, and (b) not be safe
>>> without active thermal management. I don't remember which frequency/voltage
>>> combinations are legal/tested/thermally-safe. If you need more details here,
>>> the NVIDIA L4T web forums are the best place to get answers; visit
>>> http://developer.nvidia.com/embedded-computing the follow the community
>>> link, then follow the forum link.
>>>
>>> Once the kernel boots, it is responsible for any clock management. If
>>> higher-than-default clocks are required, the kernel is responsible for
>>> selecting these.
>>
>>
>> After enabling the debug messages in clock.c and tegra124/clock.c I am
>> seeing the following messages during u-boot start up.
>>
> ...
>>
>> PLLX = 0
>
> ...
>>
>> periph 47, rate=6400000, reg=60006128 = 7e
>> Requested clock rate 6400000 not honored (got 6375000)
>
> ...
>>
>> I am seeing lot of requested clock rates are not honored, which I
>> assume to be meaning unable to set to the requested clock frequency
>> and other frequencies being set.
>
>
> Yes, the clock dividers can't generate every possible frequency, so they
> generate the closest possible value and emit a debug message just as a note.
> You can ignore these.
>
>> which is the frequency it is currently running on?
>
>
> PLLX = 0 above is obviously wrong. The only way to find out is to manually
> trace through the CAR registers to find the source the CPU is hooked to, and
> then trace through all the dividers.

In the arch/arm/mach-tegra/tegra124/clock.c file , I am seeing some
TBD features related to clock frequencies.

/*
 * Get the oscillator frequency, from the corresponding hardware configuration
 * field. Note that Tegra30+ support 3 new higher freqs, but we map back
 * to the old T20 freqs. Support for the higher oscillators is TBD.
 */
enum clock_osc_freq clock_get_osc_freq(void)
{

From the logs and boot graph I feel that the Tegra cpu's are running
at low frequencies and it might be because u-boot has set the clock
frequency low. Is it so?

After cpu_freq driver is initialized the clock frequency is changed to 714 MHz.

[    8.646758] cpufreq: cpufreq_online: CPU0: Running at unlisted
freq: 696000 KHz
[    8.646980] cpufreq: cpufreq_online: CPU0: Unlisted initial
frequency changed to: 714000 KHz

Do you have any idea which part of kernel driver or initialization
phase is responsible to set the clock frequencies?

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[Stephen Warren]

On 08/24/2016 05:44 AM, vinoth eswaran wrote:
> On Tue, Aug 23, 2016 at 6:09 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 08/23/2016 06:23 AM, vinoth eswaran wrote:
>>>
>>> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org>
>>> wrote:
>>>>
>>>>
>>>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>>>
>>>>>
>>>>> Hello Developers,
>>>>>
>>>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>>>> board. The Linux Kernel version is 4.7 and the u-boot version is
>>>>> v2016.05.
>>>>> I am building a customised Linux kernel and u-boot to have the fastest
>>>>> boot
>>>>> time possible.
>>>>>
>>>>> During Kernel startup I am seeing some error messages related to CPU
>>>>> clock
>>>>> frequencies like,
>>>>>
>>>>> [    0.000000] Tegra clk 127: register failed with -17
>>>>>
>>>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>>>>> 696000 KHz
>>>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency
>>>>> changed to: 714000 KHz
>>>>>
>>>>> On seeing the bootchart I have a feeling that the cpu clock frequency
>>>>> might
>>>>> be low - as lot of drivers are taking more time than usual, so I now
>>>>> wish
>>>>> to know what frequency does the cpu cores are running on during boot
>>>>> time.
>>>>> I am not clear on who is responsible(u-boot/kernel) for setting up the
>>>>> cpu
>>>>> clock frequency during the boot time.
>>>>>
>>>>> In u-boot which modules do I need to look to get information about cpu
>>>>> frequency being set.
>>>>
>>>>
>>>>
>>>> This all happens on SoC-specific code; take a look at
>>>> arch/arm/mach-tegra/.
>>>>
>>>> I don't immediately see anything that sets a particular clock rate for
>>>> the CPU, so I'm not sure what clock rate the CPU runs at for Tega124. I'm
>>>> CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in
>>>> arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL clock
>>>> rates. However, I can't guarantee it'll print the correct rates; it's debug
>>>> code that was added early on (i.e. prior to Tegra124 support being added) so
>>>> it's possible it hasn't been updated to get the correct answer on more
>>>> recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other PLL.
>>>> You'd need to check which clock source is in use by reading the CAR
>>>> registers; see the TRM for details of the CAR.
>>>>
>>>> Also note that the memory controller clock likely boots at a non-maximal
>>>> rate. This is controlled by the BCT.
>>>>
>>>> Typically both the CPU clock and memory controller clock run at
>>>> non-maximal rates at boot time, and hence during U-Boot. That's because
>>>> using higher rates may (a) require PMIC programming, and (b) not be safe
>>>> without active thermal management. I don't remember which frequency/voltage
>>>> combinations are legal/tested/thermally-safe. If you need more details here,
>>>> the NVIDIA L4T web forums are the best place to get answers; visit
>>>> http://developer.nvidia.com/embedded-computing the follow the community
>>>> link, then follow the forum link.
>>>>
>>>> Once the kernel boots, it is responsible for any clock management. If
>>>> higher-than-default clocks are required, the kernel is responsible for
>>>> selecting these.
>>>
>>>
>>> After enabling the debug messages in clock.c and tegra124/clock.c I am
>>> seeing the following messages during u-boot start up.
>>>
>> ...
>>>
>>> PLLX = 0
>>
>> ...
>>>
>>> periph 47, rate=6400000, reg=60006128 = 7e
>>> Requested clock rate 6400000 not honored (got 6375000)
>>
>> ...
>>>
>>> I am seeing lot of requested clock rates are not honored, which I
>>> assume to be meaning unable to set to the requested clock frequency
>>> and other frequencies being set.
>>
>>
>> Yes, the clock dividers can't generate every possible frequency, so they
>> generate the closest possible value and emit a debug message just as a note.
>> You can ignore these.
>>
>>> which is the frequency it is currently running on?
>>
>>
>> PLLX = 0 above is obviously wrong. The only way to find out is to manually
>> trace through the CAR registers to find the source the CPU is hooked to, and
>> then trace through all the dividers.
>
> In the arch/arm/mach-tegra/tegra124/clock.c file , I am seeing some
> TBD features related to clock frequencies.
>
> /*
>  * Get the oscillator frequency, from the corresponding hardware configuration
>  * field. Note that Tegra30+ support 3 new higher freqs, but we map back
>  * to the old T20 freqs. Support for the higher oscillators is TBD.
>  */
> enum clock_osc_freq clock_get_osc_freq(void)
> {

I /believe/ support for the "higher oscillators is TBD" because there 
aren't any boards that actually use those frequencies, so whether 
they're supported isn't relevant at present.

> From the logs and boot graph I feel that the Tegra cpu's are running
> at low frequencies and it might be because u-boot has set the clock
> frequency low. Is it so?

Certainly the Linux kernel clock driver isn't the first piece of kernel 
code to run, so the initial kernel boot will be at whatever frequency 
U-Boot set the CPU to.

> After cpu_freq driver is initialized the clock frequency is changed to 714 MHz.
>
> [    8.646758] cpufreq: cpufreq_online: CPU0: Running at unlisted
> freq: 696000 KHz
> [    8.646980] cpufreq: cpufreq_online: CPU0: Unlisted initial
> frequency changed to: 714000 KHz
>
> Do you have any idea which part of kernel driver or initialization
> phase is responsible to set the clock frequencies?

It'll be some part of the clock (drivers/clk/tegra) or cpufreq 
(drivers/cpufreq/tegra*) code.

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[vinoth eswaran]

On Wed, Aug 24, 2016 at 6:01 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/24/2016 05:44 AM, vinoth eswaran wrote:
>>
>> On Tue, Aug 23, 2016 at 6:09 PM, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> On 08/23/2016 06:23 AM, vinoth eswaran wrote:
>>>>
>>>>
>>>> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello Developers,
>>>>>>
>>>>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>>>>> board. The Linux Kernel version is 4.7 and the u-boot version is
>>>>>> v2016.05.
>>>>>> I am building a customised Linux kernel and u-boot to have the fastest
>>>>>> boot
>>>>>> time possible.
>>>>>>
>>>>>> During Kernel startup I am seeing some error messages related to CPU
>>>>>> clock
>>>>>> frequencies like,
>>>>>>
>>>>>> [    0.000000] Tegra clk 127: register failed with -17
>>>>>>
>>>>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted
>>>>>> freq:
>>>>>> 696000 KHz
>>>>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial
>>>>>> frequency
>>>>>> changed to: 714000 KHz
>>>>>>
>>>>>> On seeing the bootchart I have a feeling that the cpu clock frequency
>>>>>> might
>>>>>> be low - as lot of drivers are taking more time than usual, so I now
>>>>>> wish
>>>>>> to know what frequency does the cpu cores are running on during boot
>>>>>> time.
>>>>>> I am not clear on who is responsible(u-boot/kernel) for setting up the
>>>>>> cpu
>>>>>> clock frequency during the boot time.
>>>>>>
>>>>>> In u-boot which modules do I need to look to get information about cpu
>>>>>> frequency being set.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This all happens on SoC-specific code; take a look at
>>>>> arch/arm/mach-tegra/.
>>>>>
>>>>> I don't immediately see anything that sets a particular clock rate for
>>>>> the CPU, so I'm not sure what clock rate the CPU runs at for Tega124.
>>>>> I'm
>>>>> CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in
>>>>> arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL
>>>>> clock
>>>>> rates. However, I can't guarantee it'll print the correct rates; it's
>>>>> debug
>>>>> code that was added early on (i.e. prior to Tegra124 support being
>>>>> added) so
>>>>> it's possible it hasn't been updated to get the correct answer on more
>>>>> recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other
>>>>> PLL.
>>>>> You'd need to check which clock source is in use by reading the CAR
>>>>> registers; see the TRM for details of the CAR.
>>>>>
>>>>> Also note that the memory controller clock likely boots at a
>>>>> non-maximal
>>>>> rate. This is controlled by the BCT.
>>>>>
>>>>> Typically both the CPU clock and memory controller clock run at
>>>>> non-maximal rates at boot time, and hence during U-Boot. That's because
>>>>> using higher rates may (a) require PMIC programming, and (b) not be
>>>>> safe
>>>>> without active thermal management. I don't remember which
>>>>> frequency/voltage
>>>>> combinations are legal/tested/thermally-safe. If you need more details
>>>>> here,
>>>>> the NVIDIA L4T web forums are the best place to get answers; visit
>>>>> http://developer.nvidia.com/embedded-computing the follow the community
>>>>> link, then follow the forum link.
>>>>>
>>>>> Once the kernel boots, it is responsible for any clock management. If
>>>>> higher-than-default clocks are required, the kernel is responsible for
>>>>> selecting these.
>>>>
>>>>
>>>>
>>>> After enabling the debug messages in clock.c and tegra124/clock.c I am
>>>> seeing the following messages during u-boot start up.
>>>>
>>> ...
>>>>
>>>>
>>>> PLLX = 0
>>>
>>>
>>> ...
>>>>
>>>>
>>>> periph 47, rate=6400000, reg=60006128 = 7e
>>>> Requested clock rate 6400000 not honored (got 6375000)
>>>
>>>
>>> ...
>>>>
>>>>
>>>> I am seeing lot of requested clock rates are not honored, which I
>>>> assume to be meaning unable to set to the requested clock frequency
>>>> and other frequencies being set.
>>>
>>>
>>>
>>> Yes, the clock dividers can't generate every possible frequency, so they
>>> generate the closest possible value and emit a debug message just as a
>>> note.
>>> You can ignore these.
>>>
>>>> which is the frequency it is currently running on?
>>>
>>>
>>>
>>> PLLX = 0 above is obviously wrong. The only way to find out is to
>>> manually
>>> trace through the CAR registers to find the source the CPU is hooked to,
>>> and
>>> then trace through all the dividers.
>>
>>
>> In the arch/arm/mach-tegra/tegra124/clock.c file , I am seeing some
>> TBD features related to clock frequencies.
>>
>> /*
>>  * Get the oscillator frequency, from the corresponding hardware
>> configuration
>>  * field. Note that Tegra30+ support 3 new higher freqs, but we map back
>>  * to the old T20 freqs. Support for the higher oscillators is TBD.
>>  */
>> enum clock_osc_freq clock_get_osc_freq(void)
>> {
>
>
> I /believe/ support for the "higher oscillators is TBD" because there aren't
> any boards that actually use those frequencies, so whether they're supported
> isn't relevant at present.
>
>> From the logs and boot graph I feel that the Tegra cpu's are running
>> at low frequencies and it might be because u-boot has set the clock
>> frequency low. Is it so?
>
>
> Certainly the Linux kernel clock driver isn't the first piece of kernel code
> to run, so the initial kernel boot will be at whatever frequency U-Boot set
> the CPU to.
>
>> After cpu_freq driver is initialized the clock frequency is changed to 714
>> MHz.
>>
>> [    8.646758] cpufreq: cpufreq_online: CPU0: Running at unlisted
>> freq: 696000 KHz
>> [    8.646980] cpufreq: cpufreq_online: CPU0: Unlisted initial
>> frequency changed to: 714000 KHz
>>
>> Do you have any idea which part of kernel driver or initialization
>> phase is responsible to set the clock frequencies?
>
>
> It'll be some part of the clock (drivers/clk/tegra) or cpufreq
> (drivers/cpufreq/tegra*) code.


Ya I have seen the code in the Linux Kernel. The problem is that the
cpufreq driver is initialized in the later phase of Linux Kernel,
after almost all drivers are getting initialized. The frequency during
the initial phase is around 696 MHZ -- which I think is setup by the
U-boot.

I want my system to boot up as fast as possible. Since during boot
time the frequency is lower than what the chip can support, I am
looking for possibilities where I can run the chip around 2 GHz which
the tegra TK1 board can support.

My doubt is , is it possible to set the frequency around 2 GHz in the
u-boot itself before passing the control to the Linux Kernel?

[U-Boot] CPU Clock frequency at boot time - Nvidia Jetson TK1

[Stephen Warren]

(CC += a few people who co-incidentally seem to be having an almost 
identical conversation on the Linux mailing list instead).

On 08/24/2016 10:38 AM, vinoth eswaran wrote:
> On Wed, Aug 24, 2016 at 6:01 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 08/24/2016 05:44 AM, vinoth eswaran wrote:
>>>
>>> On Tue, Aug 23, 2016 at 6:09 PM, Stephen Warren <swarren@wwwdotorg.org>
>>> wrote:
>>>>
>>>> On 08/23/2016 06:23 AM, vinoth eswaran wrote:
>>>>>
>>>>>
>>>>> On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <swarren@wwwdotorg.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/22/2016 08:37 AM, vinoth eswaran wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello Developers,
>>>>>>>
>>>>>>>   Currently I am working on an embedded project using Tegra Jetson Tk1
>>>>>>> board. The Linux Kernel version is 4.7 and the u-boot version is
>>>>>>> v2016.05.
>>>>>>> I am building a customised Linux kernel and u-boot to have the fastest
>>>>>>> boot
>>>>>>> time possible.
>>>>>>>
>>>>>>> During Kernel startup I am seeing some error messages related to CPU
>>>>>>> clock
>>>>>>> frequencies like,
>>>>>>>
>>>>>>> [    0.000000] Tegra clk 127: register failed with -17
>>>>>>>
>>>>>>> [    4.275805] cpufreq: cpufreq_online: CPU0: Running at unlisted
>>>>>>> freq:
>>>>>>> 696000 KHz
>>>>>>> [    4.275845] cpufreq: cpufreq_online: CPU0: Unlisted initial
>>>>>>> frequency
>>>>>>> changed to: 714000 KHz
>>>>>>>
>>>>>>> On seeing the bootchart I have a feeling that the cpu clock frequency
>>>>>>> might
>>>>>>> be low - as lot of drivers are taking more time than usual, so I now
>>>>>>> wish
>>>>>>> to know what frequency does the cpu cores are running on during boot
>>>>>>> time.
>>>>>>> I am not clear on who is responsible(u-boot/kernel) for setting up the
>>>>>>> cpu
>>>>>>> clock frequency during the boot time.
>>>>>>>
>>>>>>> In u-boot which modules do I need to look to get information about cpu
>>>>>>> frequency being set.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This all happens on SoC-specific code; take a look at
>>>>>> arch/arm/mach-tegra/.
>>>>>>
>>>>>> I don't immediately see anything that sets a particular clock rate for
>>>>>> the CPU, so I'm not sure what clock rate the CPU runs at for Tega124.
>>>>>> I'm
>>>>>> CC'ing Tom Warren in case he can recall. If you "#define DEBUG" in
>>>>>> arch/arm/mach-tegra/clock.c, then clock_init() will print out the PLL
>>>>>> clock
>>>>>> rates. However, I can't guarantee it'll print the correct rates; it's
>>>>>> debug
>>>>>> code that was added early on (i.e. prior to Tegra124 support being
>>>>>> added) so
>>>>>> it's possible it hasn't been updated to get the correct answer on more
>>>>>> recent SoCs. Oh, and IIRC the CPU can run on either PLL_X or some other
>>>>>> PLL.
>>>>>> You'd need to check which clock source is in use by reading the CAR
>>>>>> registers; see the TRM for details of the CAR.
>>>>>>
>>>>>> Also note that the memory controller clock likely boots at a
>>>>>> non-maximal
>>>>>> rate. This is controlled by the BCT.
>>>>>>
>>>>>> Typically both the CPU clock and memory controller clock run at
>>>>>> non-maximal rates at boot time, and hence during U-Boot. That's because
>>>>>> using higher rates may (a) require PMIC programming, and (b) not be
>>>>>> safe
>>>>>> without active thermal management. I don't remember which
>>>>>> frequency/voltage
>>>>>> combinations are legal/tested/thermally-safe. If you need more details
>>>>>> here,
>>>>>> the NVIDIA L4T web forums are the best place to get answers; visit
>>>>>> http://developer.nvidia.com/embedded-computing the follow the community
>>>>>> link, then follow the forum link.
>>>>>>
>>>>>> Once the kernel boots, it is responsible for any clock management. If
>>>>>> higher-than-default clocks are required, the kernel is responsible for
>>>>>> selecting these.
>>>>>
>>>>>
>>>>>
>>>>> After enabling the debug messages in clock.c and tegra124/clock.c I am
>>>>> seeing the following messages during u-boot start up.
>>>>>
>>>> ...
>>>>>
>>>>>
>>>>> PLLX = 0
>>>>
>>>>
>>>> ...
>>>>>
>>>>>
>>>>> periph 47, rate=6400000, reg=60006128 = 7e
>>>>> Requested clock rate 6400000 not honored (got 6375000)
>>>>
>>>>
>>>> ...
>>>>>
>>>>>
>>>>> I am seeing lot of requested clock rates are not honored, which I
>>>>> assume to be meaning unable to set to the requested clock frequency
>>>>> and other frequencies being set.
>>>>
>>>>
>>>>
>>>> Yes, the clock dividers can't generate every possible frequency, so they
>>>> generate the closest possible value and emit a debug message just as a
>>>> note.
>>>> You can ignore these.
>>>>
>>>>> which is the frequency it is currently running on?
>>>>
>>>>
>>>>
>>>> PLLX = 0 above is obviously wrong. The only way to find out is to
>>>> manually
>>>> trace through the CAR registers to find the source the CPU is hooked to,
>>>> and
>>>> then trace through all the dividers.
>>>
>>>
>>> In the arch/arm/mach-tegra/tegra124/clock.c file , I am seeing some
>>> TBD features related to clock frequencies.
>>>
>>> /*
>>>  * Get the oscillator frequency, from the corresponding hardware
>>> configuration
>>>  * field. Note that Tegra30+ support 3 new higher freqs, but we map back
>>>  * to the old T20 freqs. Support for the higher oscillators is TBD.
>>>  */
>>> enum clock_osc_freq clock_get_osc_freq(void)
>>> {
>>
>>
>> I /believe/ support for the "higher oscillators is TBD" because there aren't
>> any boards that actually use those frequencies, so whether they're supported
>> isn't relevant at present.
>>
>>> From the logs and boot graph I feel that the Tegra cpu's are running
>>> at low frequencies and it might be because u-boot has set the clock
>>> frequency low. Is it so?
>>
>>
>> Certainly the Linux kernel clock driver isn't the first piece of kernel code
>> to run, so the initial kernel boot will be at whatever frequency U-Boot set
>> the CPU to.
>>
>>> After cpu_freq driver is initialized the clock frequency is changed to 714
>>> MHz.
>>>
>>> [    8.646758] cpufreq: cpufreq_online: CPU0: Running at unlisted
>>> freq: 696000 KHz
>>> [    8.646980] cpufreq: cpufreq_online: CPU0: Unlisted initial
>>> frequency changed to: 714000 KHz
>>>
>>> Do you have any idea which part of kernel driver or initialization
>>> phase is responsible to set the clock frequencies?
>>
>>
>> It'll be some part of the clock (drivers/clk/tegra) or cpufreq
>> (drivers/cpufreq/tegra*) code.
>
>
> Ya I have seen the code in the Linux Kernel. The problem is that the
> cpufreq driver is initialized in the later phase of Linux Kernel,
> after almost all drivers are getting initialized. The frequency during
> the initial phase is around 696 MHZ -- which I think is setup by the
> U-boot.
>
> I want my system to boot up as fast as possible. Since during boot
> time the frequency is lower than what the chip can support, I am
> looking for possibilities where I can run the chip around 2 GHz which
> the tegra TK1 board can support.
>
> My doubt is , is it possible to set the frequency around 2 GHz in the
> u-boot itself before passing the control to the Linux Kernel?

I'm sure it's practically possible to modify U-Boot to make the same
register writes as the kernel, and hence increase the CPU clock 
frequency; there are no restrictions on the registers that U-Boot can 
access, as far as I know.

However, I'm not sure that it's safe to do so. Different SKUs support 
different clock rates and at different voltages. Also, higher clock 
rates might require more active thermal management, etc. I don't know 
the details of such restrictions, but if you ask on the forums that I 
mentioned above, someone might be able to help.