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

iGo Stowaway Ultra-Slim Keyboard

I just realized that the original software or drivers are not needed for windows mobile in order to connect the iGo keyboard. Simply press ctrl  Fn(left) Fn(right), check if the led is on, then go to the Settings/Connections/Bluetooth/Add new device… The mobile device should see the keyboard after few seconds. Click on the listed device, enter a pin, then enter the same pin on the keyboard (take care on shift/Fn etc.), the connection should be made.
The iGo also works perfectly on openmoko…

glofiish m800 framebuffer faster than the one one openmoko

I wrote a test application that creates random squares directly with random colors directly on framebuffer. It turns out that the the squares are rendered faster on the framebuffer of glofiish (gnufiish) than on openmoko. The ratio is somewhere around 7/10.

running windows mobile applications on linux of openmoko

I am excited about the idea to create a WINE like compatibility layer, eventually port WINE in order to be able to run windows mobile applications on windows. To make things even faster, I would build the GUI abstraction on top of kernel fbui. I think running fbui does not exclude running xwindows on the top of the same framebuffer, as long as they share it well…

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

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…

 

I want my money back for my openmoko freerunner

Well, I knew few days after I bought openmoko that it was the worst investment in my life :) I am sad to read on Herald Welte’s, Slashdot, H-online that the project is half over. Well it is unclear what is the state as all the news information say different things. There is an email exchange between some of the guys involved in the project, but it is unclear what the project B means. I am confident that the project will survive!

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??

android on openmoko

new compiled android kernel/filesystem available for openmoko:

http://forum.koolu.org/files/uImage-android-patched_bc2caff9cdef8a16.bin

http://forum.koolu.org/files/androidfs-koolu-1_0.jffs2

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?