Re: [Xenomai] Testing on Freescale i.MX6

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/05/2014 01:28 PM, Ralf Roesch wrote:
> On Mon May 05 2014 12:51:00 GMT+0200, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org>  wrote:
>> On 05/05/2014 09:45 AM, Ralf Roesch wrote:
>>> On Sun May 04 2014 17:57:55 GMT+0200 (CEST), Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org>  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.