Re: [Xenomai] Testing on Freescale i.MX6

["Ralf Rösch" <xenomai@cantastic.org>]

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>