short white screen after kernel boots

Andy Green andy at openmoko.com
Sat Nov 1 11:39:07 CET 2008


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

Somebody in the thread at some point said:
| On Sat, Nov 01, 2008 at 09:55:20AM +0000, Andy Green wrote:
|> 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.
| Ah.. that is true.  I have spent hours to shave off the time spend between
| init and X, and I could enter X several seconds earlier now.  Other than
| that, I still need to wait for 30 seconds before I can launch the dialer
| and another 30 seconds to register to the operator.

Right, it's frightening.

Since Harald tightened the NAND timing to good effect I have wondered a
bit if we really max out our SDRAM timing.  Then I really thought about
this when I introduced the full SDRAM test in Qi, it runs real slow to
cover 128MB and I don't think the code is inefficient.

I know you meddled with Glamo bus timing before (don't go there!  been
there!) but if you're looking for something that might pay off up in
that X delay world it wouldn't hurt to go in Qi and just start backing
off each SDRAM timing parameter by 1 and seeing how easy it was to
break... maybe some things don't break SDRAM if they shrink a little...
you can also use wallclock time against the Qi SDRAM test as a
performance metric, each dot printed is one full set and verify action
for the whole memory.

Just trash your NAND kernel temporarily (write Qi on it for example) and
remove your SD Card and Qi will do memory tests.

- -Andy

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

iEYEARECAAYFAkkMMbwACgkQOjLpvpq7dMrWtQCfa8hBPbZoTGrCNLK25jWOcxFC
rzYAoISOtM8I5k9aI2CpV3RMJlFi6SU3
=eK2F
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list