Archive for the 'openmoko' Category
cross compiling for arm, libtool issues, openmoko

No idea if this is a bug, but when installing *-dev packages with opgk-dev, the *.la library wrappers for libtool are not updated with the correct path. This causes dificulties when trying to cross compile packages that use libtool. In order to make this working, one should change the $MYCROSSCHAIN/usr/lib*.la the /usr/*/* paths to $MYCROSSCHAIN/usr/*/* directory. $MYCROSSCHAIN points to the directory where the crsschain is installed, in my case:

MYCROSSCHAIN=/usr/local/openmoko/arm/arm-XXX

fbui on gnufiish and openmoko

I managed to compile a kernel with the fbui patches. I had to make some changes in some files to adapt the patches. Unfortunately did not have too much time to test. I am quite courious how the kernel based user interface would behave on openmko… To be updated

vim on qtmoko

I just discovered that there is an ongoing porting activity of vim to qt. That should run on qtmoko… diid not try yet… It is on my agenda…

openmoko office is empty now

After following a conversation on the openmoko community mailing list and visiting http://wiki.openmoko.org/wiki/Who_is_Who it is clear now: the openmoko project is dead…

so… openmoo freerunner will be only a tool for hackers…

 

openmoko and the blond girl

Joke about blond girls: openmoko and the blond girl (invented by me)…
It guy (disappointed about his openmoko): I do not know what to do with my openmoko: should I burn it, throw it from the 45th floor, put it in clorhidric acid, or let all the wheels of a train roll over it
Blond girl: Give it to me, maybe I could use! Hallo??? Hallo!!!! Hallo??

gnufiish, linux on eten m800

I was almost sure, there will be some other people who will do much more than me for linux porting to eten glofiish m800. and le voila:

at least, I hope they will reuse the arm machine number… or they reuse the openmoko number?

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)

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.