Hi, Dima Zavin wrote: > > > 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. >
Although the nova lite has a i945 intel board chipset, it uses an 620gle ati graphics card... that's probably a, or the, problem. Does the kernel of the installer include any ati drivers? > 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. It does! Thanks! I tried this since I don't have a eee/netbook PC and was too anxious to see Android splashing on the big screen :-)... sorry for the trouble... Cheers, Filipe > > --Dima > > > > Cheers, > Filipe > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
