Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch

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

On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:

> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>
>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>> Hi Gilles
>>>>>>>>
>>>>>>>> Following your advice i tracked down the include files which 
>>>>>>>> need
>>>>>>>> to be
>>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>>> errors. I
>>>>>>>> followed the instructions in
>>>>>>>>
>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>
>>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>
>>>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON
>>>>>>>> the
>>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>>
>>>>>>> Are you sure the timer is running correctly?
>>>>>>>
>>>>>>>
>>>>>>>> Any advice on how to proceed to debug this problem? I attach 
>>>>>>>> the
>>>>>>>> config files of two cases for your reference.
>>>>>>>
>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>
>>>>>> How should i come about debugging the timer irq handler?
>>>>>
>>>>> Refering to this,
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>
>>>>> I believe that i should be put a printk in the function
>>>>> ipipe_mach_acktimer, as it is called when the linux timer 
>>>>> interrupt,
>>>>> but
>>>>> I after checking in these files, i still couldn't find it.
>>>>
>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>> patches.
>>>> The documentation for the I-pipe core patches on the ARM 
>>>> architecture
>>>> is
>>>> here:
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>
>>>> The linux timer interrupt handler given as example in this
>>>> documentation
>>>> is "omap2_gp_timer_interrupt" function, and is probably the same 
>>>> for
>>>> your omap3 derivative.
>>>
>>> Thanks for the information. So to proceed i looked at the function
>>>
>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>>> {
>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>
>>> 	if (!clockevent_ipipe_stolen(evt))
>>> 		omap2_gp_timer_ack();
>>>
>>> 	if (num_online_cpus() == 1)
>>> 		__ipipe_tsc_update();
>>>
>>> 	evt->event_handler(evt);
>>> 	return IRQ_HANDLED;
>>> }
>>>
>>> when clockevent_ipipe_stolen == 0
>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>> interrupt (with CONFIG_XENOMAI = no)
>>>
>>> I put a printk in omap2_gp_timer_ack and i notice that in both cases 
>>> of
>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>
>>> the omap2_gp_timer_ack function get called.
>>>
>>> But i am not sure how to interrupt this. I guess this means that the
>>> timer interrupt is being handled. But it still does not tell me why 
>>> the
>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>
>>
>> Put a static counter in the timer_ack function to only emit a printk
>> every HZ ticks, and check whether the timer is ticking when you get 
>> the
>> freeze in the at24c driver initialization.
> 
> Yes the timer is still ticking after the freeze in the at24c driver 
> initialization. Does this means that  the ipipe_handle_multi_irq in 
> omap_intc_handle_irq is not handling the multiple irq properly?


No. It simply means the problem is not the timer. Next usual suspect is
the clocksource. Did you get the message about clocksource switching to
ipipe_tsc and does ipipe_tsc_get return increasing values?

-- 
                                                                Gilles.