On Fri, Nov 20, 2009 at 7:00 AM, AchimNohl <achim.n...@coware.com> wrote:
> Hi all, > > I have see the same symptom while brining up 2.0 on an ARM926EJS based > (virtual) platform. 1.5 was working fine and my kernel remained > unchanged. In my analysis tools, I see that in my case the boot gets > stuck in a pthread_mutex_lock. After that the CPU is just idle. The > lock is called from hardware/libhardware/modules/gralloc.cpp in > init_pmem_area. I do not know if the problem is the same as yours but > I will update you once I found out more. > > Thanks for details , me too got stuck at same place, so it looks many guys have same problem. It shouldn't be fb driver issue or might need some changes in fb driver to make it work but we don't know what. Anyone has successfully migrate (bring-up) to eclair with same kernel from donut ? > Regards, > Achim > > On Nov 20, 4:52 am, Porting beginner <porting.begin...@gmail.com> > wrote: > > On Thu, Nov 19, 2009 at 7:10 PM, Alexey Roslyakov < > > > > alexey.roslya...@gmail.com> wrote: > > > Can you share your diff and/or logcat output? > > > > I/SurfaceFlinger( 784): SurfaceFlinger is starting > > I/SurfaceFlinger( 784): SurfaceFlinger's main thread ready to run. > > Initializing graphics H/W... > > E/FramebufferNativeWindow( 784): +++++++++++ CALLING framebuffer_open > > ++++++ > > W/gralloc ( 784): ----------- here in framebuffer, doing ioctl for > page > > flippping ------ > > W/gralloc ( 784): ----------- here in framebuffer, doing ioctl for page > > flippping ------- > > W/gralloc ( 784): ----------- here in framebuffer, doing ioctl for page > > flippping -------- > > I/gralloc ( 784): ++++++++++++using (fd=23) > > I/gralloc ( 784): id = LCDfb > > I/gralloc ( 784): xres = 240 px > > I/gralloc ( 784): yres = 320 px > > I/gralloc ( 784): xres_virtual = 240 px > > I/gralloc ( 784): yres_virtual = 640 px > > I/gralloc ( 784): bpp = 16 > > I/gralloc ( 784): r = 11:5 > > I/gralloc ( 784): g = 5:6 > > I/gralloc ( 784): b = 0:5 > > I/gralloc ( 784): width = 240 mm (25.400000 dpi) > > I/gralloc ( 784): height = 320 mm (25.400000 dpi) > > I/gralloc ( 784): refresh rate = 60.00 Hz > > E/FramebufferNativeWindow( 784): +++++++++++ CALLING gralloc_open > ++++++ > > E/FramebufferNativeWindow( 784): +++++++++++ INITIALIZE THE BUFFER FIFO > > +++++ > > E/FramebufferNativeWindow( 784): +++++++++++ AFTER GRDEV->ALLOC O +++++ > > E/FramebufferNativeWindow( 784): xDpi -2097152000 > > E/FramebufferNativeWindow( 784): yDpi -2097152000 > > > > On Nov 20, 12:22 am, Michael Trimarchi <trimar...@gandalf.sssup.it> > > > > > > > > > > > > > wrote: > > > > Hi, > > > > > > Alexey Roslyakov wrote: > > > > > I added LOGI just before return from fb_device_open. > > > > > > > I/gralloc ( 713): fb_device_open res: 0 > > > > > > > fb device initialized successfully. Problem is not here. > > > > > But where? > > > > > > maybe we have the same architecture. I'm compiling eclair for > openmoko > > > but > > > > the issue that I have is a crash in opencore. I'm trying to find the > > > > related problem, > > > > can you share with us your configuration for compile on the armv4t > > > > architecture? > > > > > > Michael > > > > > -- > > > unsubscribe: > > > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > <android-porting%2bunsubscr...@googlegroups.com> > > > website:http://groups.google.com/group/android-porting > > > > -- > > Thanks > > Rizavan- Hide quoted text - > > > > - Show quoted text - > > -- > unsubscribe: > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > website: http://groups.google.com/group/android-porting > -- Thanks -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
