[Xenomai] Testing on Freescale i.MX6

[Xenomai] Testing on Freescale i.MX6

[Ralf Roesch]

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?

Many thanks for your great job and best regards
Ralf


[1] SABRE Lite, i.MX 6Quad development kit
http://www.element14.com/community/community/knode/single-board_computers/sabrelite
[2] Freescale i.MX Linux Tree
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/

Re: [Xenomai] Testing on Freescale i.MX6

[Gilles Chanteperdrix]

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?


-- 
                                                                Gilles.

Re: [Xenomai] Testing on Freescale i.MX6

[Ralf Roesch]

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.

--
Ralf

Re: [Xenomai] Testing on Freescale i.MX6

[Gilles Chanteperdrix]

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.

-- 
                                                                Gilles.

Re: [Xenomai] Testing on Freescale i.MX6

[Ralf Roesch]

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)

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

Re: [Xenomai] Testing on Freescale i.MX6

[Gilles Chanteperdrix]

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.

Re: [Xenomai] Testing on Freescale i.MX6

[Ralf Rösch]

Am 05.05.2014 13:44, schrieb Gilles Chanteperdrix:
> 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.
>
which is default in >= 3.10?
>>
>> 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.
>
[1]
You convinced me to switch to the latest ipipe-available stable branch: 
3.14.
(to be precise: I use the armv7-multiplatform branch from Robert Nelson 
with 3.14.3 tag)
and merged in your raw/ipipe-3.14.0 branch.
The system time drifts away in the same manner I described in my 
previous mails.

I found a hack which solves my problem:

diff --git a/arch/arm/kernel/ipipe_tsc.c b/arch/arm/kernel/ipipe_tsc.c
index 4eb5050..f759a20 100644
--- a/arch/arm/kernel/ipipe_tsc.c
+++ b/arch/arm/kernel/ipipe_tsc.c
@@ -132,6 +132,11 @@ void __init __ipipe_tsc_register(struct 
__ipipe_tscinfo *info)
                            (unsigned long)(tsc_area + 0x80));
         hard_local_irq_restore(flags);

+#ifdef CONFIG_CPU_FREQ_GOV_PERFORMANCE
+       if (registered)
+               tsc_info.freq = 498000000;
+#endif
+
         printk(KERN_INFO "I-pipe, %u.%03u MHz clocksource\n",
                tsc_info.freq / 1000000, (tsc_info.freq % 1000000) / 1000);
         if (!registered)

My system is fixed to performance (governer, cpufreq-set), so the CPU is 
100% working on max. 996MHz.
The date and hwclock are in sync now.

[2]
I'm currently benchmark the 3.14 system by 2 processes:
  - cyclictest  -l50000000  -p99 -n -i 400
  - dd if=/dev/mmcblk0p2

I have seen one hung task timeout at the console:
[ 2161.927458] INFO: task kworker/u8:2:62 blocked for more than 120 seconds.
[ 2161.934263]       Not tainted 3.14.3-xenomai-armv7-x5 #5
[ 2161.939624] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[ 2161.947510] kworker/u8:2    D c08282e4     0    62      2 0x00000000
[ 2161.953921] Workqueue: kmmcd mmc_rescan
[ 2161.957840] [<c08282e4>] (__schedule) from [<c067fb90>] 
(__mmc_claim_host+0x90/0x1b8)
[ 2161.965696] [<c067fb90>] (__mmc_claim_host) from [<c06867cc>] 
(mmc_sd_detect+0x1c/0x70)
[ 2161.973730] [<c06867cc>] (mmc_sd_detect) from [<c06820f0>] 
(mmc_rescan+0x174/0x2e8)
[ 2161.981430] [<c06820f0>] (mmc_rescan) from [<c0041550>] 
(process_one_work+0x148/0x3ec)
[ 2161.989383] [<c0041550>] (process_one_work) from [<c00424e0>] 
(worker_thread+0x13c/0x404)
[ 2161.997602] [<c00424e0>] (worker_thread) from [<c0047c1c>] 
(kthread+0xd4/0xec)
[ 2162.004852] [<c0047c1c>] (kthread) from [<c000e520>] 
(ret_from_fork+0x18/0x38)

In Kernel 3.10 (Freescale) I did not observe this type of error (i have 
tested for about 2 days).
Do you know how much the max. latency could be involved when this sort 
of error is triggered?

[3]
BTW i have attached an other patch which might be helpful.

--
Ralf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-i-pipe-compiler-fixes-for-imx.patch
Type: text/x-patch
Size: 1496 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140507/763c512e/attachment.bin>

Re: [Xenomai] Testing on Freescale i.MX6

[Gilles Chanteperdrix]

On 05/07/2014 07:20 PM, Ralf Rösch wrote:
>
> Am 05.05.2014 13:44, schrieb Gilles Chanteperdrix:
>> 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.
>>
> which is default in >= 3.10?

It is modified in the git for 3.10, but the patch has not been generated 
I believe.

> I found a hack which solves my problem:
>
> diff --git a/arch/arm/kernel/ipipe_tsc.c b/arch/arm/kernel/ipipe_tsc.c
> index 4eb5050..f759a20 100644
> --- a/arch/arm/kernel/ipipe_tsc.c
> +++ b/arch/arm/kernel/ipipe_tsc.c
> @@ -132,6 +132,11 @@ void __init __ipipe_tsc_register(struct
> __ipipe_tscinfo *info)
>                              (unsigned long)(tsc_area + 0x80));
>           hard_local_irq_restore(flags);
>
> +#ifdef CONFIG_CPU_FREQ_GOV_PERFORMANCE
> +       if (registered)
> +               tsc_info.freq = 498000000;
> +#endif
> +
>           printk(KERN_INFO "I-pipe, %u.%03u MHz clocksource\n",
>                  tsc_info.freq / 1000000, (tsc_info.freq % 1000000) / 1000);
>           if (!registered)

To do the same thing cleanly, you should call ipipe_tsc_register again 
when the frequency changes, unfortunately, it does not fix the timer 
frequency, so, you will experience a lot of useless timer interrupts.
IOW, the problem is not really solved. The best workaround I found for 
the freescale kernel 3.0 is to start the processor directly with the 
target frequency (people want fast boots usually, so booting with the 
highest frequency makes more sense anyway), this also avoids having to 
enable cpufreq. Which is why I told you to look at this patch for the 
solution to your problem.

> In Kernel 3.10 (Freescale) I did not observe this type of error (i have
> tested for about 2 days).
> Do you know how much the max. latency could be involved when this sort
> of error is triggered?

This error probably has nothing to do with latency (interrupt latency or 
scheduling latency, as returned by cyclictest or the latency test as 
what we mean on this list when we say latency without precising latency 
of what). You may want to look at the freescale kernel to see if it does 
not have any patch regarding mmc.

>
> [3]
> BTW i have attached an other patch which might be helpful.

Thanks, will merge.



-- 
					    Gilles.

[Xenomai] Testing on Freescale i.MX6

[Paul S.]

Hello there. I'm running Xenomai 2.6.3 on a developer board with imx6q, and
it seems to work perfectly fine for me. I've used ipipe-gch.git from
git.xenomai.org, then checked out to ipipe-3.0-imx6q branch, then I've had
some rough time porting some board-specific code from my 3.0.36 kernel to
3.0.43 from that branch, but besides that everything seems to be working.
I've run LinuxCNC on that, and now I'm stuck writing GPIO driver for
LinuxCNC, but, again, besides that everything seems to be in order.


-- 
sincerely, Paul

Re: [Xenomai] Testing on Freescale i.MX6

[Ralf Roesch]

schrieb Paul S.:
> Hello there. I'm running Xenomai 2.6.3 on a developer board with imx6q, and
> it seems to work perfectly fine for me. I've used ipipe-gch.git from
> git.xenomai.org, then checked out to ipipe-3.0-imx6q branch, then I've had
> some rough time porting some board-specific code from my 3.0.36 kernel to
> 3.0.43 from that branch, but besides that everything seems to be working.
> I've run LinuxCNC on that, and now I'm stuck writing GPIO driver for
> LinuxCNC, but, again, besides that everything seems to be in order.
>
>
Paul, thanks a lot. What type of developer board do you use?
Which type of electrical interfaces do you provide for controlling CNC
(servo, stepper, field-bus, real-time Ethernet)?
Do you have some results of latency tests available?

Our company is also working in the motion control section for over 20
years now.
We mostly build "intelligent" controller cards (for example
http://www.rw-gmbh.de/gallery/3-mcu3100/detail/4-mcu3100).
Up to now we have built our CNC firmware based on an own built minimal
RTOS with very low latency (some few microseconds).
We currently check the possibility to switch over to an generic
available OS with real-time support.
The i.mx6 series processor has been selected because of scalability,
long term availability and PCIE root complex end endpoint support.
Our plan is to develop an intelligent PCIe card based on the i.mx6S/D/Q
for Linux and Windows hosts and also working as a standalone controller.
--
regards Ralf