Kernel Initialization Problem

[Stefan Kalkowski]

On 07/24/2014 01:50 PM, chirag garg wrote:
> Hi Stefan,
> 
> On Thu, Jul 24, 2014 at 2:36 PM, Stefan Kalkowski <
> stefan.kalkowski at ...1...> wrote:
> 
>> Hi,
>>
>> On 07/24/2014 09:27 AM, chirag garg wrote:
>>> Hi
>>>
>>> As I am working on iMx6 Board. I am trying to use Arm_gic Interrupt
>>> Controller instead of TZIC used in iMx53 board. Previously I was using
>>> Pic_based:: Pic( ).
>>>
>>
>> You should use the PIC for Cortex A9, like Aditya Kousik used it in the
>> original patch to enable i.MX6:
>>
>>   "class Pic : public Cortex_a9::Pic { };"
>>
>>> As the version change in Genode 14.05,
>>> Inside : Genode/repos/base-hw/src/core/kernel/kernel.cc
>>>
>>>  we are calling " init_kernel_uniprocessor( ) " to set up the env for
>> other
>>> core and then we are calling  " init_kernel_multiprocessor( ) " which is
>>> using *pic( )* call at various places which is returning a singleton
>>> object.
>>
>> You shouldn't need to change anything in kernel.cc. If you just describe
>> the execution flow, then you're right: the firstly executing CPU
>> initializes certain data-structures (e.g. kernels initial page tables),
>> and then it wakes up all other CPUs (if configured, and available). Then
>> all CPUs, including the first one, are executing the code in
>> "init_kernel_multiprocessor".
>>
>> One remark: did you set the PROCESSORS variable in
>> "repos/base-hw/mk/spec-hw_imx6.mk" to some value above "1"? That
>> variable got introduced in Genode release 14.04 as part of the
>> preliminary SMP support. Please assure that you set that variable to
>> one, because until now the SMP for Cortex A9 isn't tested at all, and
>> probably is not working correctly.
>>
>>
>  yes, we are not changing anything in kernel.cc, we are trying to debug the
> Kernel Initialization problem by printing debug messages in the kernel.cc .
> And we set the PROCESSORS variable to 1.
> 
>>>
>>>
>>> extern "C" void init_kernel_multiprocessor()
>>> {
>>> .....
>>> .....
>>> init_trustzone(*pic( )*);
>>> ......
>>> }
>>>  and the pic( ):
>>>
>>> Pic * pic() {   * return unmanaged_singleton<Pic>( ) *;  }
>>>
>>> and at this point it is not able to return the object
>>> *unmanaged_singleton<Pic>(
>>> ) , *what could be the problem ??
>>
>> I don't know what you mean by: "not able to return the object". Does it
>> mean you get a null-pointer, or isn't the function returning at all,
>> blocking infinitely? Or does it (page-)fault within the Pic() constructor?
>>
>> yes, wherever the first call to *pic( )* is there , the execution stuck ,
> I mean to say it is not returning at all from the function call,blocking
> infinitely.
> All the debug messages before the first *pic( ) * call are getting printed.
> and next messages are not printed and kernel initialization stops.

Do you call pic() recursively? Is the execution reaching the PIC
constructor esp. constructor of the grandparent-class "Arm_gic"?

It is hard to debug the problem this way remotely. You've to follow the
execution from call to call: first instrument the unmanaged_singleton
function, constructor and constructors of the base classes until you
find the point where it stucks.

I wonder why the kernel now stucks at this point. In a previous mail,
your kernel was doing progress, but then you got a page-fault. Now,
you're experiencing problems much earlier.

Regards

> 
> 
> 
> Regards
> 
> Chirag Garg
> IIT Madras , Rise Lab
> 
> 
>> Regards
>>
>>>
>>>
>>> Regards
>>>
>>> Chirag Garg
>>> IIT Madras , Rise Lab
>>>
>>>
>>>
>>>
>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>>
>>>
>>>
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>
>> --
>> Stefan Kalkowski
>> Genode Labs
>>
>> http://www.genode-labs.com/ · http://genode.org/
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> 
> 
> 
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/