> > So... I have tried the installer on a small desktop PC - a Asus Nova Lite: > > http://www.asus.com/news_show.aspx?id=11565 >
Heh, cute. I should mention that we really should not be reusing the same installer images as a "general purpose" installer for anything x86. It really is meant to be configured individually for every target device for reproducible builds/installs, per-device tweaks, etc. and the installer seems as it has run its course well (although it took > a lot of time - namely resizing the 250 GB partition), and the nova lite > pc now boots from the hard drive. > resize2fs is really really slow. I didn't get a chance to dig into it to figure out why. It could probably be improved significantly with a little TLC. > However, Android is not able to boot completely. After a few seconds, > the screen goes completely black and never proceeds. By pressing alt+f1 > I am able to access the system console (however the system keeps trying > to initialize the graphic interface, and I have to press alt+f1 every > few seconds to access the console). > Are the framebuffer drives loading correctly? The prebuilt drivers were only verified to work on the i945g chipset that's in the eeepc 701 (though it "probably" works on many other i915 derivatives?). As mentioned I have only verified this on my eeepc, so ymmv. It's a bit of a pain right now since the drm/i915 modules need to be built outside the kernel tree, and I really didn't want to mirror the f.o drm trees since its under development, and I dont have the time to keep up with it at the moment. I just threw together the precompiled bins for convenience. The f.o guys are doing great work, and once their stuff is pushed into mainline (.29ish timeframe i think?), the fb drivers will be part of the kernel build and there will be much rejoicing. It will be great. dmesg: > > the surfaceflinger activity has exited due to a segfault - and I can see > from the log that it keeps retrying forever. > > Logcat : > > /dev/pmem could not be found, as well as lighgl.so. > validate_display_surface has failed with error 300 (BAD_DISPLAY_SURFACE) > call to OpenGL API has been done with no current context. > The pmem and hgl messages are non fatal in this case. Surfaceflinger should fall-back onto ashmem heaps (iirc) and sw gl. It probably goes haywire since your fb driver is not operational? > > Do you have any clue of what might be causing the surfaceflinger to fail > (is it the lack of drivers?)? Also what do you recommend to troubleshoot > these situations (how to get the complete logs out of the test box, and > what other troubleshooting tools are available in the android console). > If this is not one of those silly umpc/netbook thingies and it has a normal serial port, i would recommend hooking up to it. It will give you a working shell, and let you debug a lot easier than on a flickering console :) You should also build your own kernel and make sure you have the right ethernet drivers to get access to it from the network. You can then run adb over the network and essentially get a remote console. Hope this helps. --Dima > > Cheers, > Filipe > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
