Optimization team update (11/02 ~ 11/08)

John Lee john_lee at openmoko.com
Sat Nov 8 05:19:55 CET 2008


Hi community,

A brief summary of what the optimization team did last week:

Erin worked on qtopia to improve the network registering time.

  Qtopia 4.3.2: camp network about 26~36 sec and it would display 'No
  Network' on screen before that.

  Qt extended 4.4.2: 40 sec from qpe main() to Ready [black screen
  first, home screen 20 sec]

  Qtopia 4.3.2 + X11 [17 + 52 sec before, 52 sec -12 -20 = 30 sec,
  by applying two patches]
  http://git.openmoko.org/?p=qtopia.git;a=commit;h=9f0eb58ab7cca96e90bd49845d23b10ecf7ba664
  http://git.openmoko.org/?p=qtopia.git;a=commit;h=9c8c832f77f4f24adc5ad17f5031016ce8562a34

  FSO: 10-20 sec
  Google Android: 20 sec

Olv tried to replace u-boot by qi along with various improvements to
bring down the boot time to illume (without qtopia) to about 30 secs.
qi does not support dfu-util so only do this if you know what you're
doing.  He dived into a lot of code reading to see if there are
further possibilities.

Jeremy looked into the two issues about suspend/resume that we may fix
in userspace.  One is #1991, here is his update:

As I inspected, qpe and apmd opens /dev/apm_bios right now, and I
found two possible scenarios for this issue as below:

  1) in qpe, we need to wait for the reply of prepare_suspend for the
  modem. in this case, we may need to wait for a period +of time that
  exceed 30 seconds, and we don't know how long it could be, waitfing
  for the response from modem.

  2) It goes to blank, but then ompower doesn't get any request for
  doing suspend. I doubt in some case, illume doesn't set +the
  suspend_delay timer.

  for 1), I will go to check what does that mean by the AT commands we
  emit before executing "apm --suspend".

  for 2), I will debug illume for a while.

Another one #1347 is about after the resume, it goes to suspend
immediately.  For this one, it's because screensaver timeouts right
after the resume.  We can fix this by invoking "xset s off" before
going +to sleep, and reset it after the resume.  Though I am looking
into the possbilities of enabling apm in xglamo and checking the
apm_bios driver code to see if we can fix this in xglamo.

BTW, Matt has patches to solve ticket #1884. It works. Matt is
arranging them and he is going to update some information about it.

Julian wrote an initial version of python loader.  It imports various
modules first, listens on dbus and forks on demand to execfile.  This
brought down the load time of pyefl-sudoko from 2.59s to 1.38, a 46%
improvement, and om-settings from 3.99 to 1.60, 59% improvement.
There was already a daemon in Om2008 just for the sake of loading
om-settings (and it cleverly sleeps for 4 seconds before starting up,
make the booting even slower), we take it out to get the 3.99 number.

It is just a start, there are many issues left regarding the python
loader and we will keep working on it.  Once the code is in a better
shape Julian will put it into our svn/git.

Tick mainly worked on the upgrade path this week (#2109).


Regards,
John




More information about the community mailing list