[Xenomai] iMX6q 1Hz tick

[Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

Hi,

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.

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 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.

I am still investigating but any clues would be very useful

Regards
Thierry

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

On 12/07/2012 02:28 PM, Thierry Bultel wrote:

> Hi,
> 
> 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.

> 
> 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.

> 
> 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.

-- 
                                                                Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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 kernel boots, it is stuck for some seconds when initializing 
network, but I have noticed some substancial differences on the fec 
driver, I should take a look at that later.

I do not have the slowness issue anymore,
/proc/xenomai/irq shows the timer IRQ counter increasing, on the 4 CPUs


[root@buildroot ~]# cat /proc/xenomai/irq | grep timer
  29:      257278       86177       23138       11670         [timer]

However,

in /proc/interrupts,
I have
  87:          8          0          0          0       GIC  i.MX Timer Tick

The counter increases -very- slowly, I have not measured accurately, but 
I takes several minutes to increase by one.

Where can I look to fix that issue please ?


Another issue I have noticed is that the "reboot" command takes about 
10-12 seconds, whereas it is almost immediate with the original kernel.

regards
Thierry

>

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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.


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.

-- 
                                                                Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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?


-- 
					    Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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?

-- 
                                                                Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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. What does cat
/proc/timer_list say?

Also, you can try adding the call to __ipipe_tsc_update in
mxc_timer_interrupt even in the SMP case. If you have a problem with the
tsc, the "tsc" test from Xenomai testsuite should fail after some time
when run with the "-w" argument, but normally the tsc should take a long
time to wrap, so, there should not be immediately visible effects. But
it is worth checking.

-- 
                                                                Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

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 ?

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

What does cat
> /proc/timer_list say?
>

[root@buildroot ~]# cat /proc/timer_list
Timer List Version: v0.6
HRTIMER_MAX_CLOCK_BASES: 3
now at 1470794386645 nsecs

cpu: 0
  clock 0:
   .base:       8c0084f0
   .index:      0
   .resolution: 10000000 nsecs
   .get_time:   ktime_get
active timers:
  clock 1:
   .base:       8c008528
   .index:      1
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_real
active timers:
  clock 2:
   .base:       8c008560
   .index:      2
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_boottime
active timers:
   .nohz_mode      : 1
   .idle_tick      : 1470780000000 nsecs
   .tick_stopped   : 0
   .idle_jiffies   : 117112
   .idle_calls     : 431119
   .idle_sleeps    : 103348
   .idle_entrytime : 1470792979203 nsecs
   .idle_waketime  : 1470789968751 nsecs
   .idle_exittime  : 1470790014466 nsecs
   .idle_sleeptime : 1458835547455 nsecs
   .iowait_sleeptime: 1296620167 nsecs
   .last_jiffies   : 117079
   .next_jiffies   : 117080
   .idle_expires   : 1470790000000 nsecs
jiffies: 117079

cpu: 1
  clock 0:
   .base:       8c0114f0
   .index:      0
   .resolution: 10000000 nsecs
   .get_time:   ktime_get
active timers:
  clock 1:
   .base:       8c011528
   .index:      1
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_real
active timers:
  clock 2:
   .base:       8c011560
   .index:      2
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_boottime
active timers:
   .nohz_mode      : 1
   .idle_tick      : 1470800000000 nsecs
   .tick_stopped   : 0
   .idle_jiffies   : 117079
   .idle_calls     : 26472
   .idle_sleeps    : 3777
   .idle_entrytime : 1470794091951 nsecs
   .idle_waketime  : 1470790774647 nsecs
   .idle_exittime  : 1470790779117 nsecs
   .idle_sleeptime : 1469166160233 nsecs
   .iowait_sleeptime: 208141047 nsecs
   .last_jiffies   : 117079
   .next_jiffies   : 117080
   .idle_expires   : 1504740000000 nsecs
jiffies: 117079

cpu: 2
  clock 0:
   .base:       8c01a4f0
   .index:      0
   .resolution: 10000000 nsecs
   .get_time:   ktime_get
active timers:
  clock 1:
   .base:       8c01a528
   .index:      1
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_real
active timers:
  clock 2:
   .base:       8c01a560
   .index:      2
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_boottime
active timers:
   .nohz_mode      : 1
   .idle_tick      : 1470440000000 nsecs
   .tick_stopped   : 1
   .idle_jiffies   : 117080
   .idle_calls     : 125874
   .idle_sleeps    : 32018
   .idle_entrytime : 1470460008425 nsecs
   .idle_waketime  : 1470459967346 nsecs
   .idle_exittime  : 1470430011331 nsecs
   .idle_sleeptime : 1467715834344 nsecs
   .iowait_sleeptime: 201327381 nsecs
   .last_jiffies   : 117046
   .next_jiffies   : 117243
   .idle_expires   : 1472430000000 nsecs
jiffies: 117079

cpu: 3
  clock 0:
   .base:       8c0234f0
   .index:      0
   .resolution: 10000000 nsecs
   .get_time:   ktime_get
active timers:
  clock 1:
   .base:       8c023528
   .index:      1
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_real
active timers:
  clock 2:
   .base:       8c023560
   .index:      2
   .resolution: 10000000 nsecs
   .get_time:   ktime_get_boottime
active timers:
   .nohz_mode      : 1
   .idle_tick      : 1467050000000 nsecs
   .tick_stopped   : 1
   .idle_jiffies   : 116718
   .idle_calls     : 16882
   .idle_sleeps    : 4052
   .idle_entrytime : 1468040078182 nsecs
   .idle_waketime  : 1468040068578 nsecs
   .idle_exittime  : 1467040019716 nsecs
   .idle_sleeptime : 1466208672344 nsecs
   .iowait_sleeptime: 149617863 nsecs
   .last_jiffies   : 116804
   .next_jiffies   : 1073858533
   .idle_expires   : 10738885330000000 nsecs
jiffies: 117079


Tick Device: mode:     1
Broadcast device
Clock Event Device: mxc_timer1
  max_delta_ns:   715827903888
  min_delta_ns:   42500
  mult:           25769803
  shift:          32
  mode:           3
  next_event:     9223372036854775807 nsecs
  set_next_event: v2_set_next_event
  set_mode:       mxc_set_mode
  event_handler:  tick_handle_oneshot_broadcast
  retries:        0
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: local_timer
  max_delta_ns:   21691754030
  min_delta_ns:   1000
  mult:           425201762
  shift:          31
  mode:           3
  next_event:     1470800000000 nsecs
  set_next_event: xnarch_next_htick_shot
  set_mode:       xnarch_switch_htick_mode
  event_handler:  tick_nohz_handler
  retries:        0

Tick Device: mode:     1
Per CPU device: 1
Clock Event Device: local_timer
  max_delta_ns:   21691754030
  min_delta_ns:   1000
  mult:           425201762
  shift:          31
  mode:           3
  next_event:     1470800000000 nsecs
  set_next_event: xnarch_next_htick_shot
  set_mode:       xnarch_switch_htick_mode
  event_handler:  tick_nohz_handler
  retries:        0

Tick Device: mode:     1
Per CPU device: 2
Clock Event Device: local_timer
  max_delta_ns:   21691754030
  min_delta_ns:   1000
  mult:           425201762
  shift:          31
  mode:           3
  next_event:     1472430000000 nsecs
  set_next_event: xnarch_next_htick_shot
  set_mode:       xnarch_switch_htick_mode
  event_handler:  tick_nohz_handler
  retries:        0

Tick Device: mode:     1
Per CPU device: 3
Clock Event Device: local_timer
  max_delta_ns:   21691754030
  min_delta_ns:   1000
  mult:           425201762
  shift:          31
  mode:           3
  next_event:     10738885330000000 nsecs
  set_next_event: xnarch_next_htick_shot
  set_mode:       xnarch_switch_htick_mode
  event_handler:  tick_nohz_handler
  retries:        0


> Also, you can try adding the call to __ipipe_tsc_update in
> mxc_timer_interrupt even in the SMP case. If you have a problem with the
> tsc, the "tsc" test from Xenomai testsuite should fail after some time
> when run with the "-w" argument, but normally the tsc should take a long
> time to wrap, so, there should not be immediately visible effects. But
> it is worth checking.

I keep you informed of the tests by tomorrow

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

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.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

Gilles,

another issue (likely related, and that may help to diagnose) that I can 
see is that time is completely wrong;

For instance:


[root@buildroot ~]# time sleep 10

real	0m10.009s
user	0m0.002s
sys	0m0.013s

The system says that it spent 10 secs but I actually measured 25 secs.

Notice that I have CONFIG_HZ=1000

Time is correct when CONFIG_IPIPE is set to NO

Regards
Thierry

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

On 12/11/2012 04:26 PM, Thierry Bultel wrote:
> Gilles,
> 
> another issue (likely related, and that may help to diagnose) that I can 
> see is that time is completely wrong;
> 
> For instance:
> 
> 
> [root@buildroot ~]# time sleep 10
> 
> real	0m10.009s
> user	0m0.002s
> sys	0m0.013s
> 
> The system says that it spent 10 secs but I actually measured 25 secs.

No, that is likely because you have CONFIG_CPU_FREQ or CONFIG_CPU_IDLE
enabled.

-- 
					    Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

Le 11/12/2012 16:36, Gilles Chanteperdrix a écrit :
> On 12/11/2012 04:26 PM, Thierry Bultel wrote:
>> Gilles,
>>
>> another issue (likely related, and that may help to diagnose) that I can
>> see is that time is completely wrong;
>>
>> For instance:
>>
>>
>> [root@buildroot ~]# time sleep 10
>>
>> real	0m10.009s
>> user	0m0.002s
>> sys	0m0.013s
>>
>> The system says that it spent 10 secs but I actually measured 25 secs.
>
> No, that is likely because you have CONFIG_CPU_FREQ or CONFIG_CPU_IDLE
> enabled.
>

Thanks, yes this was CONFIG_CPU_FREQ
Sorry

Thierry

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

On 12/11/2012 05:01 PM, Thierry Bultel wrote:
> Le 11/12/2012 16:36, Gilles Chanteperdrix a écrit :
>> On 12/11/2012 04:26 PM, Thierry Bultel wrote:
>>> Gilles,
>>>
>>> another issue (likely related, and that may help to diagnose) that I can
>>> see is that time is completely wrong;
>>>
>>> For instance:
>>>
>>>
>>> [root@buildroot ~]# time sleep 10
>>>
>>> real	0m10.009s
>>> user	0m0.002s
>>> sys	0m0.013s
>>>
>>> The system says that it spent 10 secs but I actually measured 25 secs.
>>
>> No, that is likely because you have CONFIG_CPU_FREQ or CONFIG_CPU_IDLE
>> enabled.
>>
> 
> Thanks, yes this was CONFIG_CPU_FREQ

Ok, and when running at full speed, do the timer thread always take 20%
cpu ?
-- 
					    Gilles.

Re: [Xenomai] iMX6q 1Hz tick

[Thierry Bultel]

Le 11/12/2012 17:50, Gilles Chanteperdrix a écrit :
> On 12/11/2012 05:01 PM, Thierry Bultel wrote:
>> Le 11/12/2012 16:36, Gilles Chanteperdrix a écrit :
>>> On 12/11/2012 04:26 PM, Thierry Bultel wrote:
>>>> Gilles,
>>>>
>>>> another issue (likely related, and that may help to diagnose) that I can
>>>> see is that time is completely wrong;
>>>>
>>>> For instance:
>>>>
>>>>
>>>> [root@buildroot ~]# time sleep 10
>>>>
>>>> real	0m10.009s
>>>> user	0m0.002s
>>>> sys	0m0.013s
>>>>
>>>> The system says that it spent 10 secs but I actually measured 25 secs.
>>>
>>> No, that is likely because you have CONFIG_CPU_FREQ or CONFIG_CPU_IDLE
>>> enabled.
>>>
>>
>> Thanks, yes this was CONFIG_CPU_FREQ
>
> Ok, and when running at full speed, do the timer thread always take 20%
> cpu ?
>

It is much better. I only have 1.3% of CPU load.
Also the target seems really stable now. Thanks a lot, again.

The only remaining 'weird' issue is that the iMX Timer Tick counter in 
/proc/interrupts does not increase whereas it does when CONFIG_IPIPE is 
set to NO. It is not really a blocking issue, but I would like to 
understand why.

Re: [Xenomai] iMX6q 1Hz tick

[Gilles Chanteperdrix]

On 12/11/2012 06:30 PM, Thierry Bultel wrote:
> Le 11/12/2012 17:50, Gilles Chanteperdrix a écrit :
>> On 12/11/2012 05:01 PM, Thierry Bultel wrote:
>>> Le 11/12/2012 16:36, Gilles Chanteperdrix a écrit :
>>>> On 12/11/2012 04:26 PM, Thierry Bultel wrote:
>>>>> Gilles,
>>>>>
>>>>> another issue (likely related, and that may help to diagnose) that I can
>>>>> see is that time is completely wrong;
>>>>>
>>>>> For instance:
>>>>>
>>>>>
>>>>> [root@buildroot ~]# time sleep 10
>>>>>
>>>>> real	0m10.009s
>>>>> user	0m0.002s
>>>>> sys	0m0.013s
>>>>>
>>>>> The system says that it spent 10 secs but I actually measured 25 secs.
>>>>
>>>> No, that is likely because you have CONFIG_CPU_FREQ or CONFIG_CPU_IDLE
>>>> enabled.
>>>>
>>>
>>> Thanks, yes this was CONFIG_CPU_FREQ
>>
>> Ok, and when running at full speed, do the timer thread always take 20%
>> cpu ?
>>
> 
> It is much better. I only have 1.3% of CPU load.
> Also the target seems really stable now. Thanks a lot, again.
> 
> The only remaining 'weird' issue is that the iMX Timer Tick counter in 
> /proc/interrupts does not increase whereas it does when CONFIG_IPIPE is 
> set to NO. It is not really a blocking issue, but I would like to 
> understand why.

Could you check if you have the issue with the I-pipe kernel for Linux
3.4.6, available in xenomai git?

git://git.denx.de/ipipe.git branch core-3.4

-- 
					    Gilles.