On 08/23/2016 06:23 AM, vinoth eswaran wrote:
On Mon, Aug 22, 2016 at 6:15 PM, Stephen Warren <[email protected]> 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 mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
