* [Xenomai] iMX6q 1Hz tick @ 2012-12-07 13:28 Thierry Bultel 2012-12-07 18:34 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-07 13:28 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-07 13:28 [Xenomai] iMX6q 1Hz tick Thierry Bultel @ 2012-12-07 18:34 ` Gilles Chanteperdrix 2012-12-09 20:06 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-07 18:34 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-07 18:34 ` Gilles Chanteperdrix @ 2012-12-09 20:06 ` Thierry Bultel 2012-12-09 23:54 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-09 20:06 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-09 20:06 ` Thierry Bultel @ 2012-12-09 23:54 ` Gilles Chanteperdrix 2012-12-10 14:53 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-09 23:54 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-09 23:54 ` Gilles Chanteperdrix @ 2012-12-10 14:53 ` Thierry Bultel 2012-12-10 16:01 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-10 14:53 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 14:53 ` Thierry Bultel @ 2012-12-10 16:01 ` Gilles Chanteperdrix 2012-12-10 16:31 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-10 16:01 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 16:01 ` Gilles Chanteperdrix @ 2012-12-10 16:31 ` Thierry Bultel 2012-12-10 17:37 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-10 16:31 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 16:31 ` Thierry Bultel @ 2012-12-10 17:37 ` Gilles Chanteperdrix 2012-12-10 18:34 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-10 17:37 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 17:37 ` Gilles Chanteperdrix @ 2012-12-10 18:34 ` Thierry Bultel 2012-12-10 18:56 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-10 18:34 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 18:34 ` Thierry Bultel @ 2012-12-10 18:56 ` Gilles Chanteperdrix 2012-12-10 20:02 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-10 18:56 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 18:56 ` Gilles Chanteperdrix @ 2012-12-10 20:02 ` Thierry Bultel 2012-12-10 20:19 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-10 20:02 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 20:02 ` Thierry Bultel @ 2012-12-10 20:19 ` Gilles Chanteperdrix 2012-12-10 21:09 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-10 20:19 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 20:19 ` Gilles Chanteperdrix @ 2012-12-10 21:09 ` Thierry Bultel 2012-12-10 21:22 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-10 21:09 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 21:09 ` Thierry Bultel @ 2012-12-10 21:22 ` Gilles Chanteperdrix 2012-12-11 15:26 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-10 21:22 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-10 21:22 ` Gilles Chanteperdrix @ 2012-12-11 15:26 ` Thierry Bultel 2012-12-11 15:36 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-11 15:26 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-11 15:26 ` Thierry Bultel @ 2012-12-11 15:36 ` Gilles Chanteperdrix 2012-12-11 16:01 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-11 15:36 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-11 15:36 ` Gilles Chanteperdrix @ 2012-12-11 16:01 ` Thierry Bultel 2012-12-11 16:50 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-11 16:01 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-11 16:01 ` Thierry Bultel @ 2012-12-11 16:50 ` Gilles Chanteperdrix 2012-12-11 17:30 ` Thierry Bultel 0 siblings, 1 reply; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-11 16:50 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-11 16:50 ` Gilles Chanteperdrix @ 2012-12-11 17:30 ` Thierry Bultel 2012-12-11 17:40 ` Gilles Chanteperdrix 0 siblings, 1 reply; 20+ messages in thread From: Thierry Bultel @ 2012-12-11 17:30 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai] iMX6q 1Hz tick 2012-12-11 17:30 ` Thierry Bultel @ 2012-12-11 17:40 ` Gilles Chanteperdrix 0 siblings, 0 replies; 20+ messages in thread From: Gilles Chanteperdrix @ 2012-12-11 17:40 UTC (permalink / raw) To: Thierry Bultel; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-12-11 17:40 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-07 13:28 [Xenomai] iMX6q 1Hz tick Thierry Bultel 2012-12-07 18:34 ` Gilles Chanteperdrix 2012-12-09 20:06 ` Thierry Bultel 2012-12-09 23:54 ` Gilles Chanteperdrix 2012-12-10 14:53 ` Thierry Bultel 2012-12-10 16:01 ` Gilles Chanteperdrix 2012-12-10 16:31 ` Thierry Bultel 2012-12-10 17:37 ` Gilles Chanteperdrix 2012-12-10 18:34 ` Thierry Bultel 2012-12-10 18:56 ` Gilles Chanteperdrix 2012-12-10 20:02 ` Thierry Bultel 2012-12-10 20:19 ` Gilles Chanteperdrix 2012-12-10 21:09 ` Thierry Bultel 2012-12-10 21:22 ` Gilles Chanteperdrix 2012-12-11 15:26 ` Thierry Bultel 2012-12-11 15:36 ` Gilles Chanteperdrix 2012-12-11 16:01 ` Thierry Bultel 2012-12-11 16:50 ` Gilles Chanteperdrix 2012-12-11 17:30 ` Thierry Bultel 2012-12-11 17:40 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.