One way to modify the clock setting is to change the register definitions In the u-boot board config header (pcl052.h). I tried changing CONFIG_SYS_CLKCTRL_CCSR from 0x0003FF24 to 0x0001FF24 (which changes PLL1 PFD clock select from PFD3 (396MHz) to PFD1 (500MHz)), and verified that the system clock changed to 500MHz (by adding a call to pll1_sw_clk.get_rate() in Linux kernel sources in arch/arm/mach-mvf/clock.c). However, changing the system clock to 500MHz broke UART functionality; I SSH'ed to the hardware target to confirm these values.
There is currently not an option to change the clock speed in Desktop Factory. The next kernel bump should allow you to change the clock speed in Linux userspace on the fly, which is why we will not be adding this as an option to Desktop Factory.
thanks for your quick answer. I have tried to change value of the CONFIG_SYS_CLKCTRL_CCSR register in the pcl052.h file, and the arm_core_clk and arm_sys_clk in the clock.c file.
Changing only the value of the PLL register CONFIG_SYS_CLKCTRL_CCSR will only change PLL speed but there is no any correlation of that change to the configuration of the other parts of Vybrid CPU, such as UART, USB, ADC, etc., and they stop working after that change. So, this is not solution for CPU speed change.
We can only wait that next kernel bump which should allow us to change the clock speed in Linux user space on the fly.
With best regards,
I'm also trying to bump the A5 core speed to max, my board - PhyTek PhyCore Vybrid, referred to as pcm052 in sys code. Also using TimeSys kit (desktop factory), with latest supplied kernel and u-boot by them.
The above changes are not enough to bump the speed. Both, u-boot and kernel file(s) need extra changes.
The CONFIG_SYS_CLKCTRL_CCSR 0x0003FF24 change bumps the core clock, but keeping dividers same - register CACRR, defined just below CCSR - that means bus and ipg clocks also get bumped to max. One thing ipg feeds UART, so your baud rate gets screwed as we observe.
The Vybrid adaption in u-boot provided seems very 'disabled' (as we see mostly commend out and hardcoded values in vybrid/clock.c), and when you do change these clocks speed in lowlevel system init, you also need to statically change them higher up. The idea is those should get obtained dynamically (I think ... as I'm new to u-boot).
To fix the baud rate, you need to enable serial_init, by adding to board/phytec/pcm052/pcm052.c contains board_init. You also need to change cardcoded clocks.
From default startup, A5,DDR,BUS,IPG = 396,396,132,66 (which it actually boots with without the u-boot default), if we change PLL1->PFD3 to PFD1 we have 500,396,166,83 frequencies now.
return 83000000; //66000000;
gd->bus_clk = 166000000; //66000000;
gd->ipg_clk = 83000000; //66000000;
That should give you bootable u-boot, with higher a5 rate and working serial baudrate at 115200.
But once you start booting kernel it will get screwed again, because ipg rate is hardcoded in more than one place there too. As well as the busrate. While you can login remotely and check that pll1_sw clock is 500 as suggested above, you should also check BogoMips : and that for me was identical to before doing any changes.
Thus at 396 A5 speed i get 262.96 Bogo, which i also get exactly same with above changes only. Bummer. But bogo may be bogus, so I run CoreMark before and after change, and the same statistic resulted on both cases ~ 830 (you can google coremark).
In same clock file, you need to go and fix all the same arm core and bus and ipg hardcoded values, to correct for the change. After doing that, I use both the kernel tracing and CoreMark to very that (firstly serial now works at same rate as u-boot), and the A5 core (and whole system) is running faster now.
vyclk = clk_get(NULL, "pll1_sw_clk");
printk(KERN_NOTICE "~vybrid~: pll1_sw_clk = %u\n", clk_get_rate(vyclk));
vyclk = clk_get(NULL, "cpu_clk");
printk(KERN_NOTICE "~vybrid~: arm_core_clk = %u\n", clk_get_rate(vyclk));
vyclk = clk_get(NULL, "ipg_clk");
printk(KERN_NOTICE "~vybrid~: ipg_clk = %u\n", clk_get_rate(vyclk));
vyclk = clk_get(NULL, "periph_clk");
printk(KERN_NOTICE "~vybrid~: platform_bus_clk = %u\n", clk_get_rate(vyclk));
~vybrid~: pll1_sw_clk = 500000000
~vybrid~: arm_core_clk = 500000000
~vybrid~: ipg_clk = 83000000
~vybrid~: platform_bus_clk = 166000000
BogoMips: Calibrating delay loop... 331.77 BogoMIPS (lpj=1658880).
And, CoreMark result is ~1048.
So this is real speed bump to me!
Hopefully TimeSys will fix or implement that dynamic frequencing soon. But fixed way may be useful too, and both u-boot and kernel board startup should be fixed I think to allow easy one place change and recompile.
You will need to modify U-Boot and Linux source to change clock values. In U-Boot source, clock register definitions are set in the board config header (for example, include/configs/pcl052.h) whereas Linux performs clock setup at arch/arm/mach-mvf/clock.c file.
If you are using the Desktop Factory to build U-Boot and Linux, after you make modifications to the above source files, you can run 'make u-boot-restage kernel-restage && make' to rebuild.
I have made two SD cards with Timesys Linux. One without any modifications of images from your site (396 MHz), and one with suggested modifications from you (498 MHz).
> You will need to modify U-Boot and Linux source to change clock values. In U-Boot source, clock register definitions are set in the board config header
> (for example, include/configs/pcl052.h) whereas Linux performs clock setup at arch/arm/mach-mvf/clock.c file.
> If you are using the Desktop Factory to build U-Boot and Linux, after you make modifications to the above source files,
> you can run 'make u-boot-restage kernel-restage && make' to rebuild.
In the first moment, I thought that A5 core work on 498 MHz, but I was wrong, because of bad time measuring (by the way, now I use gettimeofday();)
I have made a test program (8 Queens puzzle) and with both SD Card Timesys Linux distributions (unmodified and modified) I got for all 92 puzzle solutions a same timings (130 micro-seconds), so obviously CPU speed is not changed.
Can you PLEASE make necessary modifications for maximum speed of VF61, and explain what exactly to do, to get 500 MHz speed, or attach necessary modified files.
Thanks in advance.
With best regards,
I have attached files that have to be tuned which Timesys Support has suggested in the previous post.
My question for Timesys: Why you don't add CPU and BUS Frequency change option in the Timesys Desktop Factory to avoid such a problems with users (like myself) without specific knowledge about Linux architecture?
Nice example is Raspbian Linux for Raspberry Pi where you have a start-up configuration choice of several CPU "tweaks" from modest to extensive.
My question for Freescale: Do I have a wrong impression that you are not too much interested to "make alive" Vybrid CPU's for wide spectrum of users. This product is two years on the market, and we are still struggling with some basic CPU features like DSPI, NAND boot, etc. ? Why you don't make sample code for every feature of Vybrid CPU, like NXP does for their CPU's? If you are waiting a Community to resolve that, maybe they will give up at some point.
Thanks in advance.
With best regards,