From: Stefan K. <ste...@ge...> - 2014-07-24 12:32:50
|
On 07/24/2014 01:50 PM, chirag garg wrote: > Hi Stefan, > > On Thu, Jul 24, 2014 at 2:36 PM, Stefan Kalkowski < > ste...@ge...> 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 >>> gen...@li... >>> 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 >> gen...@li... >> 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 > gen...@li... > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ |