Kernel Initialization Problem

chirag garg chiragdthinker at ...9...
Thu Jul 24 15:30:43 CEST 2014


On Thu, Jul 24, 2014 at 6:02 PM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:

> 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"?
>
> No , we are not calling pic() recursively. No it's not reaching there I
tried to put the debug message.


> 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.
>
> ok, I will try to do that.


> 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.
>
> Initially, I was using pic_bsaed :: pic() in that case it was printing
"Kernel Initialized ". but when i got to know we have to use Arm_gic then i
changed to the   "class Pic : public Cortex_a9::Pic { }; " like Aditya was
doing.


> 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/
>
>
> ------------------------------------------------------------------------------
> 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/83b9915f/attachment.html>


More information about the users mailing list