short white screen after kernel boots

Andy Green andy at openmoko.com
Sat Nov 1 10:55:20 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Sat, Nov 01, 2008 at 12:12:08AM +0000, Andy Green wrote:
|> What I had in mind is not that userspace should bring up the backlight
|> (it will look like a brick then if you booted into a rootfs that didn't
|> know it was expected) but that the framebuffer driver will blank the
|> video memory and then bring up the backlight just after Glamo driver
inits.
|>
|> What we could do is chvt to 4 say and put a small logo in there during
|> glamo framebuffer init, just before backlight comes up?
| This is with Qi, right?  I am using stable kernel and it takes about
| 1.25 seconds before we can show anything fancy on the screen.  300ms of
| which are mdelay()'s in gta02_machine_init (powering on WLAN module?).
| If we could remove them, it is possible to show a graphical screen
| within 1 second.  This does not take into account the time we spend in
| bootloader, which could be another some seconds.

Yes the patch to remove this is in stable-tracking already, it's because
the Atheros SDIO stack / AR6001 driver does not recognize the "card"
when we power it that it is still defaulting to having to power it.
Atheros stack + WLAN driver does not work as modules either.  Werner has
a mainline SDIO stack implementation of the AR6001 driver under
development that might act better eventually.

| This is also sort of what I am thinking about.  If we define our normal
| power-on action to be, for example, long press the power button for 5
| seconds, we can give the users an impression that it enters graphical
| boot within 1 second.  Because Qi could do its work, including loading
| the kernel to ram, during the press without users noticing.  If the
| power button is released before 5 seconds, Qi powers down the machine
| instead of booting the kernel.

I think you have identified the few hundred ms that can be shaved off in
kernel already, we have identified before the WLAN delay and the many
seconds blown in U-Boot and solved that with Qi, there are still "real"
savings to be had in userland I am sure of many tens of seconds that
will pay off much better.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkMJ3gACgkQOjLpvpq7dMpjEgCdE27jhTR1EV9A1eTKLhaP9r4u
lQ0An01nG2Rb6N4zzS4BXttTTLsq31uS
=IZmH
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list