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.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
