Re: [Xenomai] iMX6q 1Hz tick

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

On 12/10/2012 10:09 PM, Thierry Bultel wrote:

> Le 10/12/2012 21:19, Gilles Chanteperdrix a écrit :
>> On 12/10/2012 09:02 PM, Thierry Bultel wrote:
>>
>>> Le 10/12/2012 19:56, Gilles Chanteperdrix a écrit :
>>>> On 12/10/2012 07:34 PM, Thierry Bultel wrote:
>>>>
>>>>> Le 10/12/2012 18:37, Gilles Chanteperdrix a écrit :
>>>>>> On 12/10/2012 05:31 PM, Thierry Bultel wrote:
>>>>>>> Le 10/12/2012 17:01, Gilles Chanteperdrix a écrit :
>>>>>>>> On 12/10/2012 03:53 PM, Thierry Bultel wrote:
>>>>>>>>> Le 10/12/2012 00:54, Gilles Chanteperdrix a écrit :
>>>>>>>>>> On 12/09/2012 09:06 PM, Thierry Bultel wrote:
>>>>>>>>>>
>>>>>>>>>>> Le 07/12/2012 19:34, Gilles Chanteperdrix a écrit :
>>>>>>>>>>>> On 12/07/2012 02:28 PM, Thierry Bultel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Hello Gilles,
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have "successfully" patched a 3.0.35 kernel from Freescale with
>>>>>>>>>>>>> adeos-ipipe-3.0.36-1.18.11
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have -not- applied the adeos-ipipe-3.0.36-arm-1.18-11-pre.patch
>>>>>>>>>>>>> that showed too much "revert patch detected" errors.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The patch should apply cleanly, the question, if you get too many
>>>>>>>>>>>> rejections, it is because you do not apply it to the proper branch.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Of course it was not.
>>>>>>>>>>> I started with a kernel provided by the module manufacturer. I estimate
>>>>>>>>>>> that this kernel is "almost" a rel_imx_3.0.35_12.09.02, I mean, that
>>>>>>>>>>> I have not found a closer tag than this one.
>>>>>>>>>>>
>>>>>>>>>>> My first idea was to attempt to apply the patches to that kernel
>>>>>>>>>>> directly. I was not expecting it would have been simple, and it was
>>>>>>>>>>> actually not. But after a few hours I came to the initial result I said.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW, I have understand that its purpose was mainly to upgrade to 3.0.36,
>>>>>>>>>>>>> but what is actually the role of the
>>>>>>>>>>>>> adeos-ipipe-3.0.36-arm-1.18-11-post.patch ? (I applied it).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have explained this in a previous mail.
>>>>>>>>>>>
>>>>>>>>>>> Ok, I will seek in the history. I would be nice if the explanation
>>>>>>>>>>> was in the README.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had to deal with some rejections but at least the kernel is booting
>>>>>>>>>>>>> and my application running.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the target is very slow, and /proc/xenomai/irq shows that the
>>>>>>>>>>>>> [timer] irq only comes about every 1 second.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The /proc/interrupts shows an IRQ every 10ms, which was expected
>>>>>>>>>>>>> since I have CONFIG_HZ=100
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am pretty sure that I messed up something in the patch process,
>>>>>>>>>>>>> however I do not know where to start to look for.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Apply the patches to the proper imx release, and everything should be fine.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is what I did, at last.
>>>>>>>>>>> To do so, I have extracted the BSP from the given 'almost'
>>>>>>>>>>> rel_imx_3.0.35_12.09.02 kernel,
>>>>>>>>>>> taken the rel_imx_3.0.15_12.03.00, applied the patches,
>>>>>>>>>>> and brought back the BSP to the patched kernel.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The issues I mentionned are not also present with CONFIG_IPIPE=no,
>>>>>>>>> so it is just that the 3.0.15 kernel does not have everything for my board.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would do what you want to do with git. Checkout the ipipe-3.0-imx6q
>>>>>>>>>> branch from the ipipe-gch.git, then merge it with the vendor branch you
>>>>>>>>>> want to use.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure it would work and would be fine with git.
>>>>>>>>> But unfortunalely I do not have access to the repository of the vendor,
>>>>>>>>> but only to a bz2 snapshot of their kernel.
>>>>>>>>>
>>>>>>>>> I wonder if the right method would be to use git to merge Ipipe to the
>>>>>>>>> 3.0.35_12_09.02, and then bring back the BSP that I have isolated as a patch
>>>>>>>>
>>>>>>>> Yes, if the vendor BSP is based on 3.0.35_12_09.02, you should make a
>>>>>>>> diff with that, and try and merge it with the ipipe-3.0-imx6q branch.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Done. And success. Thanks. I am running your 3.0.43 kernel with my BSP.
>>>>>>> no more network or reboot slowness issues.
>>>>>>>
>>>>>>> However, htop it saying that CPU0 is at 20% and CPU3 at 12%,
>>>>>>> no application is running. The only thing that I see running is the
>>>>>>> timer interrupt.
>>>>>>>
>>>>>>> Also, I still have
>>>>>>> 87:         13          0          0          0       GIC  i.MX Timer Tick
>>>>>>>
>>>>>>> .. the counter increases very slowly, about 1 every 10 minutes maybe.
>>>>>>>
>>>>>>> That does not happen with CONFIG_IPIPE=no
>>>>>>
>>>>>> Do you have CONFIG_LOCALTIMER (and CONFIG_SMP) enabled?
>>>>>>
>>>>>>
>>>>>
>>>>> CONFIG_SMP yes,
>>>>> You mean CONFIG_LOCAL_TIMERS ? Yes
>>>>
>>>>
>>>> Could you post the disassembly of the mxc_timer_interrupt function?
>>>>
>>>
>>> Hope this helps:
>>>
>>> 8006e93c <mxc_timer_interrupt>:
>>> 8006e93c:       e3031998        movw    r1, #14744      ; 0x3998
>>> 8006e940:       e92d4010        push    {r4, lr}
>>> 8006e944:       e34810c7        movt    r1, #32967      ; 0x80c7
>>> 8006e948:       e3020a00        movw    r0, #10752      ; 0x2a00
>>> 8006e94c:       e34800c3        movt    r0, #32963      ; 0x80c3
>>> 8006e950:       e3a04001        mov     r4, #1
>>> 8006e954:       e5912000        ldr     r2, [r1]
>>> 8006e958:       e5903000        ldr     r3, [r0]
>>> 8006e95c:       e5921008        ldr     r1, [r2, #8]
>>> 8006e960:       e5824008        str     r4, [r2, #8]
>>> 8006e964:       e12fff33        blx     r3
>>> 8006e968:       e1a00004        mov     r0, r4
>>> 8006e96c:       e8bd8010        pop     {r4, pc}
>>>
>>> Tell me if you need more information
>>>
>>>
>>
>> Ok, this looks compiled as the sources tell us. The thing I do not
>> understand is that since there is another clockevent running (the local
>> timers), the mxc_timer should not be ticking at all.
> 
> but is does when CONFIG_IPIPE is NO, (I can see the counter increasing);
> why is it not the case otherwise ?


I am not sure I have a deep enough understanding of the clockevents
system, but from what I understandd, when the local timers are running,
there is no need to run a broadcast timer.

> 
> If you do not encounter this issue with your board(s) , does that mean
> that the problem is somewhere in my BSP ?


I may have completely overlooked this issue when testing the imx6q port,
so, I will access the board to have a look at it. Anyway, on the omap4
to which I have direct access, I have:

Tick Device: mode:     0
Broadcast device
Clock Event Device: gp_timer
 max_delta_ns:   131072454787401
 min_delta_ns:   91553
 mult:           140737
 shift:          32
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: <800146a9>
 set_mode:       <80014805>
 event_handler:  <8003ec95>
 retries:        0
tick_broadcast_mask: 00000000


Tick Device: mode:     0
Per CPU device: 0
Clock Event Device: local_timer
 max_delta_ns:   8521760502
 min_delta_ns:   1000
 mult:           1
 shift:          0
 mode:           2
 next_event:     9223372036854775807 nsecs
 set_next_event: <8004d561>
 set_mode:       <8004d651>
 event_handler:  <8003eead>
 retries:        0

Tick Device: mode:     0
Per CPU device: 1
Clock Event Device: local_timer
 max_delta_ns:   8521760502
 min_delta_ns:   1000
 mult:           1
 shift:          0
 mode:           2
 next_event:     9223372036854775807 nsecs
 set_next_event: <8004d561>
 set_mode:       <8004d651>
 event_handler:  <8003eead>
 retries:        0

mode 1 is "shutdown", so the broadcast timer is stopped,
mode 2 is "periodic", because CONFIG_HIGH_RES_TIMERS is off in this
particular configuration
and mode 3 is "one-shot".

Do you have the kernel messages at hand? Maybe they would give us a clue.

-- 
                                                                Gilles.