Froyo build boots, but has blank screen with cursor in the upper left corner when zygote starts.

117 views
Skip to first unread message

Sir Ace

unread,
Nov 18, 2010, 11:48:19 AM11/18/10
to Android-x86
I setup my build box according to everything on the "get sources"
pages, and I do get a build.
The output files are 80386 ELFs, but from the host system, ldd is
telling me they don't look right... The do work on the tablet, so I
am guessing something else is going on.

root@comet:/usr/src/android-x86/out/target/product/generic_x86/system#
file bin/system_server bin/system_server: ELF 32-bit LSB executable,
Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs),
not stripped

root@comet:/usr/src/android-x86/out/target/product/generic_x86/system#
ldd bin/system_server
bin/system_server: error while loading shared libraries: /usr/lib32/
libc.so: invalid ELF header


I do know the USB/ISO daily builds for Donut work on this system. Is
there a way I can launch another shell so I can run logcat and see
where it's actually dying? If I boot into debug mode, I can launch
it right before it does the final boot stuff, but it flips to the
blank screen before I can read the last lines.

--Thanks!

Who what?

unread,
Nov 23, 2010, 1:53:21 PM11/23/10
to Android-x86
I'm reposting this in hopes I will get a response this time.
Basically, I'm just needing someone to point me in the right direction
so that I can troubleshoot my own issues...
Is there a doc that will walk me through the setup of a proper debuging env?
Once I type exit the 2nd time in the debug boot up, I loose my video,
so either I need a way to log in remotely, or have a file touched on
the disk with all the logs so I can see it on the next boot.

Can anyone point me in the right direction please?

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-x86...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
>
>

fishman

unread,
Nov 23, 2010, 7:25:04 PM11/23/10
to Android-x86
If the host os is 64bit and the target is 32bit ldd on the target
exec's wont give correct results. What's the host os?

Try Ctrl-Alt-F2 to switch terms and dmesg.

Make sure you compiled in the correct display driver, at least generic
vesa and some fonts otherwise it will give you a blank screen.

Also check out kernel/Documentation/android.txt for the options that
need to be set in the kernel in case some aren't.

J

On Nov 23, 10:53 am, "Who what?" <chand...@gmail.com> wrote:
> I'm reposting this in hopes I will get a response this time.
> Basically, I'm just needing someone to point me in the right direction
> so that I can troubleshoot my own issues...
> Is there a doc that will walk me through the setup of a proper debuging env?
> Once I type exit the 2nd time in the debug boot up, I loose my video,
> so either I need a way to log in remotely, or have a file touched on
> the disk with all the logs so I can see it on the next boot.
>
> Can anyone point me in the right direction please?
>

Who what?

unread,
Nov 24, 2010, 2:57:26 AM11/24/10
to andro...@googlegroups.com
Thanks for the reply! I never noticed that on the ldd before, my
normal build box will show correctly for ldd, but this ubuntu I
installed for compiling Android doesn't. Thanks for the heads up on
that, I doubt I would have caught it.

As for the tablet, the video driver is right, and I can see it
switching to the VESA graphics from text at the mid-level of the debug
boot . {after the first exit, and before the 2nd}

ctrl-alt-f2 switched the console just long enough for me to type
dmesg, then it was gone for good. I tried f1,f2,f3 all fail to
switch, once it does the blinking cursor thing.

I'll check the kernel options tomorrow morning, but unless it's the
ACPI flag, it won't be that. I think something else is going on. The
way the cursor is blinking, it looks like it's trying to start a
process, failing, and starting over again. {a lot like an inittab
entry that doesn't stop spawning}

fishman

unread,
Nov 24, 2010, 1:36:41 PM11/24/10
to Android-x86
I have ubuntu 64 and compiled it for my via i386 board. It works fine
I even got it to install. I had to change the grub config though as I
need it to use the vesa driver instead of the other settings so that
the screen is at least a decent size.

Do check that you have the correct options in the kernel. If it gets
past detecting android then it has found a device to run from. I got
the blinking cursor because init was dieing with a segfault. I'd also
get blinking keyboard lights.

Joe

On Nov 23, 11:57 pm, "Who what?" <chand...@gmail.com> wrote:
> Thanks for the reply!  I never noticed that on the ldd before, my
> normal build box will show correctly for ldd, but this ubuntu I
> installed for compiling Android doesn't.   Thanks for the heads up on
> that, I doubt I would have caught it.
>
> As for the tablet, the video driver is right, and I can see it
> switching to the VESA graphics from text at the mid-level of the debug
> boot . {after the first exit, and before the 2nd}
>
> ctrl-alt-f2 switched the console just long enough for me to type
> dmesg, then it was gone for good.  I tried f1,f2,f3 all fail to
> switch, once it does the blinking cursor thing.
>
> I'll check the kernel options tomorrow morning, but unless it's the
> ACPI flag, it won't be that.  I think something else is going on.  The
> way the cursor is blinking, it looks like it's trying to start a
> process, failing, and starting over again. {a lot like an inittab
> entry that doesn't stop spawning}
>

Who what?

unread,
Nov 24, 2010, 3:07:00 PM11/24/10
to andro...@googlegroups.com
It boots grub fine {after installation to the HD}, gets through the
kernel load, switches to the VESA mode graphics, finishes the text
boot in VESA mode, and then spits the "A N D R O I D root@blah #"
prompt, and when it goes to launch the GUI, that's where it goes to
the blank screen with the slow blinking cursor {maybe once every 5
seconds}.

I do know that at that point ctrl-alt-delete reboots, and it is
instantaneous, it doesn't look like it is doing a typical runlevel
shutdown.

I'll toy with it some here and see what I can find.

slajeune

unread,
Nov 24, 2010, 3:24:25 PM11/24/10
to Android-x86
What sort of hardware you you trying to run it on? I had this same
exact issue trying to boot it on a GMA 3150 (Atom N450) graphics card
while using i915 driver. If you use i915 driver, you need KMS enabled
in the kernel or else you get the blinking cursor of death :)

Cheers,
Stephane.

On Nov 24, 3:07 pm, "Who what?" <chand...@gmail.com> wrote:
> It boots grub fine {after installation to the HD}, gets through the
> kernel load, switches to the VESA mode graphics, finishes the text
> boot in VESA mode, and then spits the "A N D R O I D root@blah #"
> prompt, and when it goes to launch the GUI, that's where it goes to
> the blank screen with the slow blinking cursor {maybe once every 5
> seconds}.
>
> I do know that at that point ctrl-alt-delete reboots, and it is
> instantaneous, it doesn't look like it is doing a typical runlevel
> shutdown.
>
> I'll toy with it some here and see what I can find.
>

Who what?

unread,
Nov 24, 2010, 3:44:30 PM11/24/10
to andro...@googlegroups.com
It's an In-Motion LE1700, which has an Intel 945GM, which I think is
the same driver....
Let me give that a try and see what happens...
Thanks for the heads up on this.

Who what?

unread,
Nov 24, 2010, 4:01:59 PM11/24/10
to andro...@googlegroups.com
I just checked... CONFIG_DRM_I915_KMS is on...
At least according to:
out/target/product/generic_x86/obj/kernel/.config

slajeune

unread,
Nov 24, 2010, 5:29:18 PM11/24/10
to Android-x86
Odd...

Did you define:

BOARD_USES_I915C := true

in your BoardConfig.mk

Can you check, explicitely, which defconfig you are using?

Cheers,
Stephane.

On Nov 24, 4:01 pm, "Who what?" <chand...@gmail.com> wrote:
> I just checked...   CONFIG_DRM_I915_KMS is on...
> At least according to:
> out/target/product/generic_x86/obj/kernel/.config
>
> On Wed, Nov 24, 2010 at 2:44 PM, Who what? <chand...@gmail.com> wrote:
> > It's an In-Motion LE1700, which has an Intel 945GM, which I think is
> > the same driver....
> > Let me give that a try and see what happens...
> > Thanks for the heads up on this.
>

Who what?

unread,
Nov 24, 2010, 5:54:35 PM11/24/10
to andro...@googlegroups.com
I did not set that, in fact I am still trying to figure out how the
build works in general.
I believe that my linux kernel for this card is actually
CONFIG_FB_INTEL, but it should still work with the i915 driver too.

Who what?

unread,
Nov 25, 2010, 4:39:44 AM11/25/10
to andro...@googlegroups.com
Ok, so one problem down... That problem was, "I am an idiot"... I
was doing a make, and forgetting to have it remake my image..
Uncommenting the v915 video driver worked to fix the blinking cursor
issue. I do get video now on the tablet, but it's got the wrong mode
for the display.

Does anyone know how to change the display mode? {horizontal and/or
vertical refresh rates}

fishman

unread,
Nov 27, 2010, 2:53:26 PM11/27/10
to Android-x86
I think if you boot the vesa driver it will say vga=ask and that will
allow you to pick one, but it will use the generic vesa driver I
think.

By default it looks like there are 2 resolutions: medium and high and
neither of them are really desktop resolutions. They are low
resolution for smaller screens.

J

On Nov 25, 1:39 am, "Who what?" <chand...@gmail.com> wrote:
> Ok, so one problem down...  That problem was, "I am an idiot"...  I
> was doing a make, and forgetting to have it remake my image..
> Uncommenting the v915 video driver worked to fix the blinking cursor
> issue.  I do get video now on the tablet, but it's got the wrong mode
> for the display.
>
> Does anyone know how to change the display mode? {horizontal and/or
> vertical refresh rates}
>
> On Wed, Nov 24, 2010 at 2:54 PM, Who what? <chand...@gmail.com> wrote:
> > I did not set that, in fact I am still trying to figure out how the
> > build works in general.
> > I believe that my linux kernel for this card is actually
> > CONFIG_FB_INTEL, but it should still work with the i915 driver too.
>

Who what?

unread,
Nov 27, 2010, 3:25:33 PM11/27/10
to andro...@googlegroups.com
This was a good idea, but to no avail... I removed the options from
grub that deal with the video and set the vga=ask.
No matter what I picked as an option, it set that, then as soon as the
"A N D R O I D" prompt appeared, it reset the resolution to something
else. The splash screen was always at the same resolution regardless
of the mode that the frame buffer was supposed to be in.

I'm not sure why it is changing the resolution after the kernel sets
it, but I'm starting to think there is a hard coded option somewhere
in the boot process.

Who what?

unread,
Nov 28, 2010, 2:55:59 PM11/28/10
to andro...@googlegroups.com
Unfortunatly I was right on this one....
/scripts/0-auto-detect forces 800x600-16 on the modprobe of uvesafb
which probes the i915 driver itself.
I've attempted to modify this several different times and ways, all of
which either result in a kernel panic {as expected} or no change at
all. I'm not familiar with uvesafb at all so I'm going to have to do
a little research on this one.

Anyone have an idea now?

Changes I've tried:
probing i915 directly, with and without resolution options.
setting both uvesafb and i915 to not use mtrr
taking the probe out completely {panic}

Chih-Wei Huang

unread,
Nov 28, 2010, 9:15:57 PM11/28/10
to andro...@googlegroups.com
First of all, you have to know what framebuffer driver
you're using now. See /proc/fb.

vga=ask or xxx only affects vesafb driver.

If you are using i915 (inteldrmfb), set
video=wwwxhhh.

uvesafb (and its options) is only used
if no other framebuffer driver detected.

2010/11/29 Who what? <chan...@gmail.com>:


> Unfortunatly I was right on this one....
> /scripts/0-auto-detect forces 800x600-16 on the modprobe of uvesafb
> which probes the i915 driver itself.
> I've attempted to modify this several different times and ways, all of
> which either result in a kernel panic {as expected} or no change at
> all.  I'm not familiar with uvesafb at all so I'm going to have to do
> a little research on this one.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Who what?

unread,
Nov 28, 2010, 10:18:16 PM11/28/10
to andro...@googlegroups.com
uvesafb is probing i915 automatically, and that is also the one I am
using when I probe the module directly. Since uvesafb probes the
right module by default, I've tried not to add more complexity in the
configs than I need to by specifying one.

I do know that vga= sets the old style vesafb {I did a lot of research
on that today}, thanks for that, I may not have gotten that far
looking things up by the time I had sent the email earlier this
morning.

However, when I do use the video= options at boot time, they are
forcibly overridden somewhere else. As far as I can tell that
override is after the module {i915/drm} load time. The script I
mentioned {/scripts/0-auto-dectect} is doing a set. It's the only
place I can find anything so far.

The problem is, if I remove the options there, when it probes the
module, it is still switching resolutions and/or sync rates when the
splash screen {andriod word with left to right highlights} comes up.

This one is weird for a couple of reasons.
1) Booting into debug mode for a prompt, no matter what I set the
kernel fb resolution to, it seems to work. Which gives me an
indication that everything should be fine.
2) Once the splash hits, whatever resolution I had, is reset to
800x600, and a sync rate that makes anything unreadable.

I'm still tracing through the entire startup process, but I haven't
found anything that should be causing this yet.

Who what?

unread,
Nov 28, 2010, 10:49:14 PM11/28/10
to andro...@googlegroups.com
I can officially put this one to bed now, thank you all... Basically,
like Chih-Wei said, if you use "video=XXXXxYYY" it will work on this
hardware. I was using all the options {short example:
video=1280x1024-32@72} and that wasn't working.

I'm now up to the full GUI and am happy. The USB is really laggy for
mouse imput and the acore keeps crashing but I will work through those
too.

Thanks for all the help everyone!

Chih-Wei Huang

unread,
Nov 29, 2010, 1:11:09 AM11/29/10
to andro...@googlegroups.com
2010/11/29 Who what? <chan...@gmail.com>:

> uvesafb is probing i915 automatically, and that is also the one I am
> using when I probe the module directly.  Since uvesafb probes the
> right module by default, I've tried not to add more complexity in the
> configs than I need to by specifying one.

uvesafb and i915 are totally different fb drivers.
Saying uvesafb probes i915 is totally wrong.

i915 is usually detected and loaded by the auto-detect script.
uvesafb is only loaded if no other fb driver detected.
It is the last resort.

I think you're using i915, which is controlled by video= option.

As said, try cat /proc/fb to see what the fb driver is used exactly.

jlum

unread,
Dec 3, 2010, 3:10:31 AM12/3/10
to Android-x86
I'm having a similar issue as described above. What I'm trying to do
is set the resolution to something less than the current resolution of
the monitor.
I have verified via /proc/fb that I'm using the inteldrmfb.
So when I set the resolution via the grub kernel command line using
"video=XXXXxYYY". XXXX and YYY set to the desired resolution.
It initially sets the right screen resolution to that value.
However, once the shining Android is displayed the resolution gets set
instead to the current resolution of the monitor and not the desired.
Is there somewhere else where the resolution can be set so the desired
resolution after Android is fully booted is used?

On Nov 28, 10:11 pm, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> 2010/11/29 Who what? <chand...@gmail.com>:

Who what?

unread,
Dec 3, 2010, 3:17:23 AM12/3/10
to andro...@googlegroups.com
Mine worked with just that, if the Android logo displayed, everything
after that worked..
I ran through about 12 options to test all of the resolutions my
tablet supported... It took a little while.
Here are a few of the ones that worked for me:
1440x1080
1440x1024
1400x1050
1280x1024
1280x800
1024x800
1024x768
800x600
640x480

Chih-Wei Huang

unread,
Dec 3, 2010, 3:31:30 AM12/3/10
to andro...@googlegroups.com
2010/12/3 jlum <jp8...@gmail.com>:

> I'm having a similar issue as described above. What I'm trying to do
> is set the resolution to something less than the current resolution of
> the monitor.
> I have verified via /proc/fb that I'm using the inteldrmfb.
> So when I set the resolution via the grub kernel command line using
> "video=XXXXxYYY". XXXX and YYY set to the desired resolution.
> It initially sets the right screen resolution to that value.
> However, once the shining Android is displayed the resolution gets set
> instead to the current resolution of the monitor and not the desired.
> Is there somewhere else where the resolution can be set so the desired
> resolution after Android is fully booted is used?

Never heard that and quite impossible.
The resolution is totally determined by the
framebuffer driver and related kernel options.
Android itself definitely won't change the resolution.

Remember Android is targeted for smartphone.
Have you ever heard a smartphone can
change its resolution? I never.

Check the output of logcat to see
the exact resolution you used.

BTW, have you enabled the hardware
OpenGL acceleration?

jlum

unread,
Dec 3, 2010, 6:28:20 PM12/3/10
to Android-x86
Can you verify that my procedure for changing the resolution is
correct?

The default resolution of the monitor is 1280x1024 and I would like to
change the output to display at 1024x768.
1. Reboot system
2. At the "GNU GRUB version 0.97" screen, select "Android-x86
2010-12-01 (HDPI)"
3. Press 'e' to start editing
4. Select line "kernel /android-2010-12-01/kernel quiet root=/dev/
ram0..."
5. Press 'e' again to edit this line
6. Move to the end of the line "<C:/android-2010-12-01" and add
"video=1024x768" to the end (to modify the resolution)
7. Press "Enter" to accept the editing
8. Then press 'b' to boot using that kernel and those parameters
9. System displays the "Detecting Android-x86..."
10. System displays "ANDROID root@android:/ #" and boots.

I also tried the 'a' option instead of 'e' in step 3 but the result
was the same.
The resolution remains at 1280x1024.
Here's the output from logcat:

I/SurfaceFlinger( 2316): SurfaceFlinger is starting
I/SurfaceFlinger( 2316): SurfaceFlinger's main thread ready to run.
Initializing graphics H/W...
I/GRALLOC-MOD( 2316): mode.hdisplay 1280
I/GRALLOC-MOD( 2316): mode.vdisplay 1024
I/GRALLOC-MOD( 2316): mode.vrefresh 60
I/GRALLOC-MOD( 2316): format 0x5
I/GRALLOC-MOD( 2316): xdpi 85
I/GRALLOC-MOD( 2316): ydpi 86

Any help here is appreciated.


On Dec 3, 12:31 am, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> 2010/12/3 jlum <jp8....@gmail.com>:

jlum

unread,
Dec 3, 2010, 7:01:56 PM12/3/10
to Android-x86
BOARD_USES_I915C := true was added to the BoardConfig.mk.
I believe this enables the OpenGL H/W acceleration.
> > Android-x86 projecthttp://www.android-x86.org- Hide quoted text -
>
> - Show quoted text -

Who what?

unread,
Dec 3, 2010, 7:05:52 PM12/3/10
to andro...@googlegroups.com
That was all I had to do... Are you watching it as it boots into the
OS, or do you walk away?
I've noticed if you don't change the default time-out, it will blank
the screen fairly fast, after the logo, and I have to full-power cycle
to get the system back. I think the default is 60 seconds, but it
may be a little longer.

jlum

unread,
Dec 3, 2010, 7:47:07 PM12/3/10
to Android-x86
I have been watching it as it boots.
I'm not sure I follow. Which logo are you referring to?
I can see the screen resolution changed when the "Detecting Android-
x86...found" and the "ANDROID root@android:/ #" are displayed but once
the "shimmering Android" appears it looks as if the screen resolution
has been overwritten. This is very similar to what you had described
before.
> >> > Android-x86 projecthttp://www.android-x86.org-Hide quoted text -
>
> >> - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups "Android-x86" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to android-x86...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/android-x86?hl=en.- Hide quoted text -
Reply all
Reply to author
Forward
0 new messages