From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <536779B2.9090506@xenomai.org> Date: Mon, 05 May 2014 13:44:50 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <53661901.8090400@cantastic.org> <53666383.9010302@xenomai.org> <536741B1.8010800@cantastic.org> <53676D14.4050502@xenomai.org> <536775E4.3080309@cantastic.org> In-Reply-To: <536775E4.3080309@cantastic.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: Ralf Roesch Cc: xenomai@xenomai.org On 05/05/2014 01:28 PM, Ralf Roesch wrote: > 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) Unfortunately, I have not experienced the high latencies myself, probably because I tested the system without display. Anyway, from what I understood, if you want good latencies, you have to disable the L2 cache write-allocate policy. > > 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? mainline linux = the linux from kernel.org (which has support for imx6) freescale linux = the linux forked by freescale (which, if I understand correctly, you want to use) freescale line is forked, it has some changes which are not in mainline, and so are not patched by the patch for mainline. -- Gilles.