Kernel Initialization Problem

[chirag garg]

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.



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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140724/e8f39c9f/attachment.html>