upstart openmoko

Due to the complex dependencies in the linux boot process the safest way to boot is to run the different initialization scripts sequentially. The result is a long boot process, subsystems are initialized earlier than needed etc.

There are different approaches like upstart, initng, runit, einit that try to improve the boot process on linux, each approach concentrating on several aspects, like running initialization scripts in parallel, handling device generated events in a more flexible way etc. Ubuntu for example comes now with upstart as default init, but it failes to use even at minimum the strength of the ideas behind upstart.

With the intent to speed up the linux process both for desktop and for embedded devices like ubuntu, I started to write some scripts that generates native upstart scripts based on the information from the /etc/init.d/* scripts. As first stage it would be enough to create the native upstart script as wrapper scripts around the /etc/init.d/* scripts.

One could speed up the boot process if initialization scripts could be run in parallel. As we know certain scripts need to have other scripts already started before. To simplify my description I will use the terms target as synonim for the script and dependencies for scripts that need to be started. Having the dependency relation ship we identify two categories of scripts: dependants and dependees. Of course the dependee can be dependant and so on… It is a general requirement that there should be no cyclic dependencies in sysVinit scripts.

The most trivial approach is to create upstart scripts for the dependees containing following

start on starting …. #list those targets that require the current one

pre-start exec /etc/init.d/$MYSCRIPT start

pre-stop exec /etc/init.d/$MYSCRIPT stop

the dependants (targets) would contain sthg. like:

stop on stopping … #list those dependencies that if stopped, the current one should be stopped

pre-start exec /etc/init.d/$MYSCRIPT start

pre-stop exec /etc/init.d/$MYSCRIPT stop

the two above would be merged like:

start on starting …. #list those targets that require the current one

stop on stopping … #list those dependencies that if stopped, the current one should be stopped

pre-start exec /etc/init.d/$MYSCRIPT start

pre-stop exec /etc/init.d/$MYSCRIPT stop

the first version of a python script that would generate such wrappers would be sthg. like… (GPL!!!!)

def createfile(file, startingon):
f = open(”/etc/event.d/upgen/” + file, ‘w’)
f.write(’#file automatically generated by upgen \n\n’)
for dep in startingon:
f.write(’start on starting ‘ + dep + ‘\n\n’)
f.write(’\n\n’)
f.write(’pre-start exec /etc/init.d/’ + file + ‘ start \n\n’)
f.write(’pre-stop exec /etc/init.d/’ + file + ‘ stop\n\n’)
f.close()

def createfiles(startingonmap):
for file in startingonmap:
createfile(file, startingonmap[file])

depfile=’/etc/init.d/.depend.boot’

startingonmap={}

for line in open(depfile, ‘r’).readlines():
#skip lines with
if (line.find(’TARGETS =’) != -1) or (line.find(’INTERACTIVE =’) != -1):
pass
else:
t = line.split(’:')
dependant = t[0]
dependies = t[1].split()
for dependy in dependies:
inversemap = {}
try:
inversemap = startingonmap[dependy]
except:
pass
inversemap[dependant] = 1
startingonmap[dependy]=inversemap

createfiles(startingonmap)

virtual openmoko

There will be probably soon an arm version of XEN available. However for low carbon computing would be definitely stupid to deploy a full kernel virtualization, however even in the limited 128 MB of memory would be interesting to have a sort of openVZ, that would allow to switch back and forth between android and gnomoid or even lightoid. I am interested in this topic, so probably will write soon more about it.

review: android on openmoko freerunner (under work:) )

My first impression about the android software stack is a very good one. Maybe I am obsessed by speed, and other small details of computing, but my very first conclusion is that the android stack beats both qt embedded and the default openmoko stack.

First of all what is amazing is the boot time. The device boots with the very first version in less than 1 minute on openmoko. The screen home screen does not show too much at the beginning, just some shortcuts, but the general design just rocks.

openmoko neo freerunner booting faster

I am happy to hear that there is some progress in reducing boot time for openmoko from 2.35 (Om2008.9) minutes to around 1minute 40 seconds. Chia-l Wu claims a reduced boot time of ~50 seconds. If it will boot faster than the eten m800 with the windows mobile 6.1., then it still has to fight with the boot times of the iphone ….

 

openmoko memory allocator and hoard

Wrote a little program that allocates randomly sizes from 0 to 100 MB and compared the results for the default allocator and hoard. Hoard behaves better both as speed and overhead, however not much better. Will publish the results as soon I will have time to put them in a decent format.

openmoko project blown up like the global financial markets

As I was saying in my previous posts, I am more than disappointed about the openmoko project. The apple iphone is successful because the main man behind it wants one thing. And he wants that the users are happy with the device. And when are the users happy? If they have a usable phone… And openmoko has failed to provide that, however it had enough lego elements at disposal, and also enough time. Nobody will want to use a phone that takes 5 minutes to boot, and then another 1 minute to go to the phone interface and make a call. The problem is that the system (of the project) has to many freedoms and too many forces with random intensities in time and the result is a brownian movement, and it does not look to tend towards an equilibrium state, or it tends to an equilibrium state which is general failure :)

I have the following questions to the community:
1. Why was in not possible to create a simpler kernel that loads just the basic things to make the phone available and start anything else when needed. Or loading the kernel is slow due to printing the messages to the slow framebuffer?
2. why is this story with glamo so stupid? I was reading the specs. I spent (psychologically) 50 dolars more to have an accelerated graphic card for opengl… and it is not there… I have no acceleration on eten m800 but gl es is working on it!!!!
3. why is everything so slow? Why not moving to sthg. fast like qt embedded on top of framebuffer. I believe that tweaking of framebuffer (directfb) driver would be easier than X to activate someway the graphics acceleration.

The answer is following: the main guy behind it is just incapable, all the story is a blown up story like the global financial system… (in this case the guy behind is like the big guys who manipulate the financial markets :))

p.s. Nobody should believe that have sthg. to do with QT or Nokia other than liking the QT embedded:)

mikrokernel on openmoko freerunner

I am happy to see that there are other experiments than linux on openmoko…

http://www.linuxdevices.com/news/NS8294545513.html

and

http://wiki.ok-labs.com/

neo freerunner with qt extended 4.4

The applications look nice, the device is quite responsive, however I do not have network at all. Usb network semms to work, but the sshd is not up. Tried to start it /etc/init./….. start but the application is crashing. Unfortunatelly untill I do not have a connection to network I cannot install more software to make a more clear impression….

linux left, windows right pocket…

Yes at the moment linux is in the right pocket until linux catches up. Then will swap. I am talking about the neo freerunner vs. the eten m800. After months of problems with it the m800 is stable, I have quite a lot of software on the device that the freerunner would not provide at the moment.

neo freerunner arrived…

After a few month of hamletian tick-tack to buy or not to buy, I pushed the button and the openmoko neo freerunner took its way to me. Compared to the Eten glofiish m800 that I own I had the following impressions both about the phones external design:

  • the device seems to be more compact and less fragile than the m800
  • it seems to have less weight than m800
  • the round form gives the impression that it would slide easier into your pocket

about the preinstalled software:

  • booting is not in record time… maybe slower than the windows 6.1 image I have now on m800
  • switching between application is slow..
  • … did not want to go into details as the newer version of the image Om 2008.9, was already available… so went to download…