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

Wed Aug 24 22:47:48 CEST 2016

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