05-01-2013 09:52 AM
Could someone tell me where I should modify Linux Kernel so that the system time runs correctly with a new clock crystal?
I am working on a customer board with Zynq ZC702 running Linux kernel 3.3.0, where HW engineers put on with a different clock crystal from the one of Zynq ZC702 evaluation board.
05-01-2013 10:11 AM
Which crystal? Do you have a schematic designator number I can reference?
There are a number of variables which need to be set correctly in the processor system setup, and I recall a drop down menu to set them in the tools. It is part of the setup of all the dedicated processor system IO pins, peripheral options, etc. in SDK....
Linux per se doesn't care about the clock frequencies. The only thing that is affected (other than it not running at all as the options are just set wrong) is that any timer functions won't represent the correct time.
05-01-2013 10:51 AM
I assume you use a crystal which does not provide a 33MHz frequency. I don't know to what extend this has been tested. IIRC, the 3.3 kernel uses a lot of hard coded frequency values across BSP code and device drivers.
This should become a lot easier with more recent kernels since we migrated to use the common clock framework. I think the CCF has been merged in 3.5 and the Xilinx kernel started using it soon after. In theory on those recent kernels, all you have to do is to provide the oscillator frequency through your device tree. All other clocks should be automatically derived from there (your FSBL has to provide a sane initial setup, so the system comes up at all, of course).
05-03-2013 02:07 PM
Thanks guys for all your questions and hints, and here is the new info I got from our HW guy...
> Zynq EVA board RTC clock is using 111.111115 Mhz
> ST4300 Zynq RTC clock is using 88.888885 Mhz
and I was told that this same 88M cystal is down clocked to 33M for the SoC.
So the customer board is running OK with all funtionalities, excpet that the Linux Kernel's ticks are off, losing 12 seconds for each of real 60 seconds.
As you can see from the tow frequency number, the new crystal is 20% slower, just losing 12 seconds.
Hope this update is helpful to you guys to point me to a right location in the kernel for modifications that will bring back the correct tick counting, thus a shell command "sleep 60" will come out in real 60 seconds.
05-03-2013 02:17 PM
I'm not sure I fully understand. Are you producing a 33MHz input clock for Zynq? Then there shouldn't be a difference.
Otherwise you have to change the ps_clk's frequency in your dts file (e.g. zc702: http://git.xilinx.com/cgit/linux-xlnx.git/tree/arch/arm/boot/dts/zynq-zc702.dts#n99 ).
05-03-2013 07:55 PM
Thaks for the link but my linux-3.3 source does not contail "ps_clk" entry in file "zynq-zc702.dts". Any other entry?
05-03-2013 09:33 PM
As I said before, on kernels earlier than 3.5 frequencies were hard coded all over the place. Sorry to tell you, but there you are on your own.
Though, the timers used to be setup in arch/arm/mach-zynq/timer.c (but I don't know for sure whether that is the case for 3.3, that is just an ancient kernel).