From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <536775E4.3080309@cantastic.org> Date: Mon, 05 May 2014 13:28:36 +0200 From: Ralf Roesch MIME-Version: 1.0 References: <53661901.8090400@cantastic.org> <53666383.9010302@xenomai.org> <536741B1.8010800@cantastic.org> <53676D14.4050502@xenomai.org> In-Reply-To: <53676D14.4050502@xenomai.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Testing on Freescale i.MX6 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org On Mon May 05 2014 12:51:00 GMT+0200, Gilles Chanteperdrix wrote: > On 05/05/2014 09:45 AM, Ralf Roesch wrote: >> On Sun May 04 2014 17:57:55 GMT+0200 (CEST), Gilles Chanteperdrix >> wrote: >>> On 05/04/2014 12:40 PM, Ralf Roesch wrote: >>>> Hi, >>>> >>>> based on your suggestions from thread "[Xenomai] ipipe-core-3.10 patch >>>> for arm" >>>> I started testing Xenomai on an i.MX6 board [1]. >>>> >>>> * checked out branch imx_3.10.17_1.0.0_ga from linux-2.6-imx.git [2] >>>> * merged vanilla v3.10.32 tag >>>> resolved 3 conflicts: >>>> drivers/net/can/flexcan.c >>>> drivers/usb/host/ehci.h >>>> sound/soc/codecs/wm8962.c >>>> * applied ipipe-v3.10.32.patch >>>> resolved 4 conflicts: >>>> arch/arm/mach-imx/clk-imx6q.c >>>> arch/arm/mach-imx/mach-imx6q.c >>>> arch/arm/mach-imx/mm-imx27.c >>>> arch/arm/mach-imx/mm-imx3.c >>>> * applied xenomai-2.6 support (prepare-kernel.sh) >>>> >>>> My box boots without errors and seems to be quiet stable at the first >>>> glance. >>>> Linux arm 3.10.32-xenomai-armv7-x1 #24 SMP Sun May 4 12:17:10 CEST 2014 >>>> armv7l GNU/Linux >>>> >>>> The first thing I observed is a system time problem: >>>> the RTC and system time clocks get out of phase very quickly. >>>> I do compare the timers (end - start) on console by calling: >>>> - hwclock&& date (start) >>>> - wait an hour or more >>>> - hwclock&& date (end) >>>> The hwclock time is always o.k. but the system time reported by date is >>>> roughly 25% faster. >>>> Do you have an idea what could go wrong here? >>> The timer frequency. Did you not forget to disable CONFIG_CPU_FREQ? Do >>> you have the same issue without the I-pipe patch? >>> >>> >> Thanks Gilles, I had not disabled the CONFIG_CPU_FREQ. >> After disabling I had also to disable CONFIG_PM, because I got a lot of >> unresolved linker errors. >> More fixes had to be made in various modules where CONFIG_PM was not >> taken into account. >> In the end I had a bootable kernel, where the "out of phase of timer >> problem" has been resolved. >> Both timers keep in sync now. >> >> The kernel without I-pipe patch did work correctly, sorry for not >> mentioning that before. >> >> I have some more questions regarding timer frequency: >> >> * I prefer to leave CONFIG_CPU_FREQ enabled, >> because in this case I can use the CPUFreq governor (cpufrequtils >> package) >> to use the highest frequency, i.e. "performance" >> * if the governer is set to "performance" a frequency switch shoud not >> be possible >> (because the processor is fixed to the high rate) >> * without governer I can not use the highest rate of the processor: >> - the frequency (now) without CONFIG_CPU_FREQ is 792MHz >> - when CONFIG_CPU_FREQ is enabled (before) and governer set to >> performance it is 996MHz >> >> If I compare this both frequencies (792MHz vs. 996MHz) I estimate there >> is a wrong scaling factor responsible for the "out of phase" problem. > Look at the mx6 patch for 3.0.43, it solves a similar issue. We support > mainline, and freescale 3.0.35, not freescale 3.10, so, you may have a > lot of issues with this version which were solved for 3.0.43 but are not > in the patch for mainline 3.10. If I remember correctly, there were > multiple such issues such as idle thread and broadcast timer. > Before going deeper into this, I would like to do some performance checks. Could you please give me an advise for latency measurements and some information which result you would expect for this Quadcore CPU? (I have read about high latencies caused by cache issues for this type of cpu) BTW, I do not understand "not freescale 3.10". There is already a lot of i-pipe work done in arch/arm/mach-imx/ (mach-imx6q.c, clk-imx6q.c, ... for example) which is freescale, isn't it? -- Ralf