News aggregator

Marcus Bauer a publié les premières captures d'écran de Hackable1.
C'est sympathique en apparence, et sûrement sous le capot aussi.

xchat, connecté à un salon de discussion IRC sous Hackable1

Rui Seabra a sorti une version baptisée NewRotate 0.5.0 'Lazy Edition' de son logiciel tournant automatiquement l'écran en fonction de son orientation grâce aux accéléromètres.

Lors du SAPO Codebit 2008, Valério Valério a terminé premier la compétition de programmation avec un projet pour dénommé AccelMoko qui transforme le Neo en périphérique de jeu BlueTooth (comme la WiiMote). Il raconte sur son blog comment ça s'est passé.

Trois preuves supplémentaires - si besoin était - de l'activité de la communauté

首先，依照 Android 文件上的說明 [先安裝 SDK]，再 [撰寫 Hello, Android!] 應用程式後，打包成 apk 格式；本文使用的 Android SDK 搭配的 Eclipse 版本是 3.4（Ganymede）。接著，再照 [Android Documentation] 的說明撰寫一個 Android 應用程式，再將程式編譯後打包成 HelloMoko.apk 檔案。

當然，必須將 FreeRunner 更新為 Android 系統，更新方式可至 Openmoko 中文 wiki 下載投影片：http://wiki.openmoko.org/wiki/Main_Page/zh_tw。請依以下步驟將 HelloMoko.apk 安裝至 FreeRunner 手機上。以下的實驗環境為 Ubuntu 8.04.1。

1. 連接 FreeRunner 與 PC

將 FreeRunner 以 USB 連接 PC，再將 FreeRunner 手機開機至 Android 環境。請注意，依照 Openmoko wiki 上的說明，若在開機後再連接 PC，可能會有問題。可利用 lsusb 指令檢查 FreeRunner 是否順利連到 PC 上：

$ lsusb Bus 007 Device 002: ID 04b4:1724 Cypress Semiconductor Corp. Bus 007 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 006 Device 001: ID 0000:0000 Bus 005 Device 034: ID 1457:5117 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 004 Device 004: ID 04d9:0499 Holtek Semiconductor, Inc. Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000

2. 殺掉 adb server

執行 adb 時，adb-server 會自動啟動。因此，若是先前曾利用 Eclipse 啟動過 Android 模擬器來測試 HelloMoko 的話，adb-server 己經在背景執行了。啟動 adb server 後再連接 FreeRunner，可能會讓 adb server 找不到 FreeRunner，因此，最可靠的做法是：先檢查系統是否有 adb server，將執行中的 adb server kill 掉後，再重新啟動 adb server。

$ ps ax|grep adb 20092 ? S+ 0:00 grep adb 21032 ? Sl 0:00 adb fork-server server $ sudo kill -9 21032

adb 是 Android SDK 所提供的工具，可於 Android SDK 的 tools/ 目錄下取得。

3. 設定 PC 端 IP

接下來設定 PC 端的 IP 位址為 192.168.0.x，例如：

$ sudo ifconfig usb0 192.168.0.200

FreeRunner 的預設 IP 為 192.168.0.202，可以 ping 此位址測試是否能正常連線。

4. 啟動 adb server

設定 ADBHOST 環境變數：

$ export ADBHOST=192.168.0.202

ADBHOST 的值為 FreeRunner 的 IP 位址。再執行 adb 啟動 adb server，adb server 會自動偵測 Android 手機：

$ adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554 device

在 'List of devices attached' 項目可以看到系統自動偵測到的 Android 手機。

5. 安裝 HelloMoko.apk

使用 adb 將 HelloMoko.apk 安裝到 FreeRunner / Android 手機：

$ adb install HelloMoko.apk

安裝完成後，重新啟動 FreeRunner 即可在應用程式選單裡看到 HelloMoko。

Being a scuba diver I never seen one until recently.

After this bad joke we can come to some real infos. Harald is working on the kernel full steam ahead. Good progress so far. Sometimes faster sometimes slower.

From my side I concentraded on the OE side so far. Booting into a fso-image is working now. With every new hardware feature the kernel gets support for we can start to integrate it into FSO. GPS and BT are good candidates as they are just attached to UARTs and the enabling/disabling via GPIOs is already in the kernel.

A 'cat /dev/ttySAC2' already gives out some NMEA stancas. SiRF III binary protocol has to wait a bit longer. Next week I'll have some fun with making use of the GPS in frameword. Stay tuned.

As I post here previously, I went to Sapo Codebits  event in the last week, with my friends. The first day of the event and the morning of the second day was only conferences, the rest of the event was several contests, including a 24-hours programming contest.

In the first day of the event I met Marcus Bauer, the TangoGPS creator, he  shown some OpenMoko phones there and also gave a presentation about OpenMoko, he shown me how to install debian in a freerunner in a few minutes, using the Hackable1 distro, a very cool and easy way to try out debian on the neo SD card.

I participated in the 24-hours programming competition, my idea was turn my freerunner in a mouse and gamepad (like the wiimote) using the accelerometers. My knowledge about the accelerometers are very low, so I started getting the accelerometers data with a Python script to see the data behavior. I noticed a wrong behavior when I turn my freerunner quickly, the accelerometer seems to stall,  after a quick search in the ML archive I found that some kernel’s have this behavior, so I flash my freerunner with some old kernel’s until found a stable kernel. The accelerometer mouse required a lot of work until I get a smooth mouse movement. I also don’t knew that the acelerometers are very sensitive, and the data for the accelerometer suffer changes even if the freerunner are steady in a table. The gamepad accelerometer required less work, I used some of the ReMoko code with a few changes in the event sending methods, in order to send continues key presses, to the freerunner acts like a really gamepad. In the morning when I had my project almost completed, after some hours without sleep, I broken the BlueZ libs in my laptop, after doing a stupid mistake in the cross compiling process, this cost me about a hour to put everything in place again:). But I found some time to wrote a beta UI for my project and gave the project the silly name: AccelMoko.

After the competition ends, starts the presentation session of the projects developed during the event, the participants have only 90 seconds to present the projects to the judge and audience, when one participant finish the time another participant starts talking, in a non stop way, 82 projects enter in the contest this year (small games, web stuff, ideas …). My project was in the 20th position, my presentation had a very good feedback from the audience (they have a live voting system, with two choices “I like” and “I don´t like”). When all the participants finished there presentation, the judge gathered for about a hour to decide the winning projects.

To be sincere, I only participate in contest in a “sportive” way, I don’t had any hope to win, but… my project was the most voted by the audience and also I got the first place in the judge votes :D. So a OpenMoko project wins the Sapo Codebits 2008 competition.

In the next weeks I will merge the AccelMoko code into the ReMoko project.

You can find the git tree here and clone it from git://git.gnufiish.org/gnufiish.git. Thanks to Stefan for setting up the tree and doing the initial push (ssh+git from Taipei is so slow that it cannot finish the initial commit of a kernel Tree before the DSL modem reconnects 12 hours later).

I've called the project "gnufiish" just for the fun of it. It's quite close to the original name, and therefore a 'language hack'. Though it's obvious that there is no real official connection to the GNU project, since Linux is not part of that.

Hi,

I’ve just release a new version of omnewrotate (OpenPGP signature), the ‘Lazy Edition’ because it uses so much less CPU than any version I did before. Oh, I forgot to mention it in the release commit, but at least with FSO M4 I’m getting a very stable rotation BUT if the screen looks garbled, please wait a few seconds until the graphic user interface adjusts to the screen changes. I don’t think I can do much about that…

From the ChangeLog:

2008-11-19 - 0.5.0 - Lazy edition * uses a second thread for reading the accellerometer packets * drops Fabian's changes (not that they weren't good, just not needed any more) * adds flags (look at display_help() or ./rotate -h) * drops packets with 0 value coordinates (I got bogus packets like that so I decided to drop them, if you feel you get good packets with 0 value, you can use '-0' as an argument to take them in account). * top -d 1 -p PID shows 0.0% CPU usage (of omnewrotate) even during rotation * seems to waste a little too much memory (some stuff could be done with one number and bitwise operations instead of several numbers, I wonder how much that will improve and if it's worth the effort...) * only output outside of debug mode are real errors

Voici juste un petit billet pour vous donner quelques informations diverses glanées sur la Toile.

http://downloads.openmoko.org/releases est à nouveau disponible avec une image d'Om2008.9 sans MP3

Bearstech fera une conférence sur Openmoko le lundi 1er décembre à l'occasion du Forum Mondial du Libre.

La dernière lettre "Community Update" (du 3 au 16 Novembre) est parue : FSO a publié la "Milestone IV", SHR a publié une image de test, une mise à jour du Firmware GSM ouvrirait la porte aux cartes SIM 3G, une amélioration du driver graphique glamo se profile, etc ...

Zophon parle sur son blog d'un petit jeu qui rappellera quelques souvenir aux anciens (dirigé avec les accéléromètres, ce serait encore mieux).

Openmoko-fr.org est le 4ème résultat en recherchant "openmoko" sur Google.fr

Ce n'est plus un scoop : après Qtopia, Debian, Gentoo et d'autres, Android vient rejoindre la liste des systèmes compatibles Openmoko.
C'est l'occasion de faire le point sur ce qui est déjà disponible, ou en préparation.

En effet, une multitude de distributions existent déjà alors que l'appareil n'est en vente que depuis le 4 juillet 2008 !
Le wiki officiel en recense quelques unes mais vous allez être surpris : j'en ai trouvé 17 !
Petit tour d'horizon

Introduction

Pour ne rien vous cacher, ce billet est en préparation depuis longtemps.
L'objectif était de produire quelque chose d'assez précis sans trop entrer dans les détails techniques afin de rester accessible à tous.

Mais cet exercice est devenu très périlleux pour plusieurs raisons :

• les nouveautés et développements se succèdent à un rythme effréné
• je n'ai pas le quart du temps qu'il faudrait pour tout tester et écrire une description complète (qui serait de toutes façons très vite obsolète).

Aussi je me contenterai d'énumérer les distributions trouvées avec une brève description et des liens pour approfondir le sujet (sur les illustrations aussi).
Il y a certainement quelques erreurs, merci de les signaler en commentaire.

Les distributions d'Openmoko

Depuis le début du projet, Openmoko a tâtonné dans plusieurs directions pour affiner ses choix de développement.

L'explication est simple : c'était la première fois que quelqu'un se lançait à fabriquer un matériel ouvert couplé à des logiciels libres dans le milieu hyper-fermé et ultra-concurrentiel de la téléphonie mobile.
Ils avançaient donc en terre inconnue et cela a conduit vers plusieurs distributions assez différentes.

Om2007.1

(crédit : Lorphos)

La première distribution crée à l'origine pour le Neo1973 n'est plus du tout développée.
Mais il est encore possible de la reconstruire en partant de zéro.

Om2007.2

Seconde distribution développée par Openmoko pendant l'année 2007, elle n'est plus supportée officiellement mais toujours maintenue par une communauté d'adeptes.

Om2008

Nom de code : ASU (April/August Software Update)

Cette distribution marque un virage important (tant en apparence qu'en profondeur) dans l'avancement du système d'exploitation du Neo Freerunner.
C'est la version développée actuellement par Openmoko.

Le rythme de sortie est plus fréquent et numéroté en fonction du mois :

• Om2008.8 est sortie le 8 août 2008 (8/8/2008 !)
• Om2008.9 est sortie le 19 septembre 2008

Une Om2008.11 devrait voir le jour prochainement en apportant encore pas mal d'améliorations.

FSO

FSO est l'abréviation de FreeSmartphone.org.

Ce n'est pas une distribution en soi mais plutôt un projet concernant les couches intermédiaires entre le noyau et les applications graphiques (via Dbus).
L'objectif est d'intégrer cette technologie à la distribution Openmoko lorsqu'elle sera arrivé à maturité.
Cependant, il existe une distribution construite autour de FSO pour démontrer le concept (Voir la page OpenmokoFramework du wiki officiel ou http://trac.freesmartphone.org).

Les distributions Communautaires

Elles sont développées (ou portées sur le Neo) par de vrais passionnés : chapeau bas !
Si l'une d'elles vous motive particulièrement, contactez son auteur sans attendre : toute aide sera la bienvenue !

FDOM

FDOM est maintenue par David Samblas et signifie "Fat and Dirty OpenMoko".

Elle se compose d'une Om2008 à laquelle ont été ajoutées un maximum d'applications et de correctifs ainsi que quelques améliorations "maison" comme un système de sous-menus et un script de mise à jour.

SHR

SHR signifie Stable Hybrid Release.
Le but de cette distribution communautaire est de réaliser une bonne combinaison de Om2007.2, Om2008 et FSO.

Autrement dit, reposer sur la fiabilité de la pile FSO en y ajoutant, via une architecture modulaire, les interfaces existantes pour Om2008 et OM2007.2 dans une image système stable ... "Et le tout avec une UI et un thème qui roxe sa maman, wesh cousin !" (dixit Ainulindale, Leader du projet).

Une pré-version est disponible pour tests seulement en attendant une version déclarée stable.

Debian

Qui ne connaît pas Debian ?

La célèbre distributions Linux a été portée sur Neo Freerunner depuis le mois d'août 2008.
Modulaire, elle fonctionne très bien avec le bureau xfce et Matchbox (comme ci-dessus) et la partie téléphonie s'utilise avec zhone.

Son installation peut se révéler ardue, à réserver aux inconditionnels de la ligne de commande pour le plaisir de taper "apt-get install".

Gentoo

Debian vous parait encore trop triviale ? Vous aimez compiler sur tout support ? Alors Gentoo est faite pour vous !

J'avoue que je ne connais pas grand chose sur celle-ci aussi je préfère vous renvoyer vers sa page sur le wiki officiel.

Pyneo

Je ne suis pas sûr que pyneo corresponde à la définition de ce qu'est une distribution.
Mais le concept est intéressant : il s'appuie sur plusieurs technologies (OpenEmbedded, D-Bus, Glib, enlightment et python) et fournit un ensemble de services (démons) pour constituer une interface graphique simple et efficace.

Il est difficile de deviner vers quoi ce projet va évoluer, mais il méritait d'être mentionné. A suivre, donc.

DeforaOS

Cette distribution développée par Khorben est en phase de conception mais il a partiellement porté une version sur le Neo Freerunner.

Elle serait basée sur un micro-noyau et aurait pour ambition le développement d'un système embarqué optimisé en faisant table rase de l'historique que peuvent avoir les solutions actuelles.

Hackable1

Hackable1 est un projet de distribution communautaire initié par Bearstech et piloté par Marcus Bauer (également auteur de TangoGPS).

Destinée aux appareils mobiles ouverts comme le Neo Freerunner, elle se base sur Debian et met en oeuvre les principes de Gnome Mobile.

Les autres éditeurs

Plusieurs sociétés (ou acteurs institutionnels) se sont impliqués dans la développement de solutions logicielles ou matérielles pouvant fonctionner avec les produits Openmoko.

RunningBear

Convaincu par les concepts proposés dans DeforaOS, Bearstech a employé son développeur pour travailler sur ce nouveau projet.

RunningBear sera basé sur un noyau Linux ou BSD, avec une refonte complète du système d'exploitation en vue de répondre aux problématiques de sécurité et de confidentialité.
Le principal objectif est de repenser efficacement la manière dont un OS embarqué doit travailler, pour éviter les couches logicielles superflues (souvent héritée des décennies précédentes) qui consomment inutilement les ressources des appareils mobiles.

Qtopia

Qtopia est une distribution de l'éditeur Qt Software (ex-Trolltech, racheté par Nokia en juin 2008) orientée téléphonie et conçue à l'origine pour le Greenphone puis adaptée pour le Neo17973 et le Neo FreeRunner.

2 versions co-existent :

• Qtopia 4.3.2 (sortie le 29 août 2008)
• Qtopia 4.4 également appelée QtExtended (sortie le 3 octobre 2008)

Voir la page de Qtopia sur le wiki officiel pour en savoir plus.

Poky Linux / Sato

Poky Linux supporte le neo1973 et provient de l’éditeur britannique OpenedHand.
Ce dernier, connu pour avoir créé le gestionnaire de fenêtres Matchbox a récemment été racheté par INTEL pour travailler sur le projet MobLin.

Sato est le nom de leur pile d'applications PDA/Smartphone simples et rapides basée sur GTK+.

Neopwn

C'est une distribution embarquée dédiée à l'audit réseau.
Basée sur une Debian dont le noyau, les modules et l'interface ont été personnalisés, elle intègre un maximum d'outils de pénétration et de tests.

NeoPwn est commercialisée sous forme de packs incluant au minimum une carte microSD avec la distribution pré-installée, une documentation, un DVD de restauration et une assistance technique.
Plusieurs tarifs existent selon la taille de la carte et les options choisies :

• pack carte : à partir de $79
• pack carte + matériel (adaptateurs + carte wifi externe) : à partir de $219
• pack carte + matériel + Neo Freerunner : à partir de $699

OpenMoKast

OpenMoKast n'est pas exactement une distribution mais plutôt une adaptation matérielle et logicielle afin de transformer le Neo Freerunner en récepteur temps réel de données radiodiffusées (radio, vidéos, services, etc ...).

Pour citer cet excellent article du Centre de Recherche sur les Communications du Canada :
Une suite logicielle complète a été développée au CRC et intégrée pour contrôler un récepteur externe et décoder ses divers services tels que DAB, DAB+, DMB, Slideshow, Visual Radio and Journaline. De plus, un boîtier s'attachant au dos du FreeRunner a été produit afin d'y loger le récepteur de type USB et son antenne.

Android

Comme vous le savez (a moins d'avoir vécu en ermite jusqu'à aujourd'hui), Android est la distribution développée par Google et son Open Handset Alliance.

Depuis que le code source a été ouvert, plusieurs personnes (comme Ben Leslie, Sean McNeil ou la société Koolu ) s'efforcent de le porter sur les plates-formes matérielles d'Openmoko.

Ainsi, les premières adaptations d'Android apparaissent pour le Neo1973 et le Neo Freerunner.

Mais il reste encore du chemin à parcourir, notamment la création d'un clavier virtuel (ce qui s'annonce complexe).

Un foisonnement bénéfique ?

A voir ce nombre de projets parallèles (et cette liste n'est pas exhaustive), on peut en effet craindre une dispersion des énergies.
Mais je pense que ce foisonnement est inévitable à chaque fois qu'une nouvelle porte s'ouvre vers le monde du Libre et c'est aussi ce qui fait la richesse de cet univers.

Même si cela peut parfois nuire à l'efficacité, la diversité est motivante et enrichissante : chacun veut avancer plus vite que l'autre et les meilleures idées seront reprises par la communauté.
Il est de toutes façons impossible de forcer tous les développeurs enthousiastes à coder pour un projet unique et une seule orientation

De plus il y a des types d'utilisateurs très différents, pour lesquels il est utile d'avoir un éventail de solutions : des plus originales aux plus classiques (pour ne pas dire rassurantes). Ainsi chacun pourra choisir celle qui lui convient le mieux.

C'est ce qui se passe avec les distributions GNU/Linux sur les PC, ici le schéma se reproduit (à une échelle différente toutefois).

Contribuez !

Toutes ces distributions (ou presque) sont ouvertes aux contributions et n'attendent qu'un coup de main de votre part.

Il faudrait également compléter la page Choisir sa distribution.
L'idée est que chacun puisse trouver rapidement la solution la plus adaptée à ses besoins. Mais de nombreuses informations et captures d'écran manquent encore.

Enfin sachez qu'il existe aussi un comparatif des distributions majeures à mettre à jour sur le wiki officiel.

Le futur ?

Les distributions existantes vont continuer à se consolider, certaines devraient fusionner (comme FSO et Om2008), quelques unes vont peut-être disparaître et d'autres vont sûrement naître.

Pourquoi pas les traditionnelles Ubuntu, Fedora et Mandriva qui lorgnent de plus en plus du coté de la mobilité ?
Ou des moutures issues d'autres acteurs comme LiMo, MobLin, Symbian Foundation, Maemo, PALM, ALP, ... ?

L'avenir promet d'être intéressant

My E-TEN glofiish Linux porting efforts have made me investigate a lot of internals of the E-TEN ROM file format, WinMobile ROM files in general, XIP, Microsoft flash partition tables, imagefs and other bits and pieces.

I'm basically able to fully 'decompose' a ROM image into all its individual bits, including the pre-installed CAB's, the pre-linked DLLs in the XIP and the contents of the imagefs. And all of that on Linux, if it wasn't for the weird XPRS / SRPX compression in CE5.x imagefs. Allegedly it's the same Xpress algorithm as used e.g. in hibernation files and certain M$ network protocols, but I was trying that and didn't get anywhere. Luckily, the tools at least ran inside wine.

It's surprising how little information there is about those internals of the operating system. You can find bits and pieces in the 'ROM cooking' scene, but those are mostly HTC specific and don't always apply to E-TEN. And most of the tools that people tend to create in this community are not FOSS either :(

Anyway, once I find some time I'll probably pack/publish the stuff that I've done now. Obviously the coolest thing would be to do a GPL'd implementation of e.g. imagefs and get that into Linux. Would be fun (I've never ventured into filesystem land!), but then, it's not like I have any spare time at hands.

Last night I was trying to make sense of some of the M800 hardware drivers (sergsm.dll, keypad.dll, keybddr.dll, etc.) but it's actually quite a bit harder than I thought.

I also wrote some perl script that uses haret TRACE capability to reconstruct the I2C command/response stream. so you can basically perform any action on the device, like pushing one of the capacitive touch buttons, and see what kind of I2C communication the CPU initiates as a result. The problem with this, though: The I2C bus runs too fast, so it loses some bytes. I tried to work around it by increasing the I2C clock divider, but it seems the driver actually re-sets the divider with every transfer (rather than just once when bringing the I2C host controller up).

I'm trying to find other options (I could clock the entire system down, but then this affects things like the LCM refresh and other important clocks), since I believe a clean I2C tracer is the right thing to do.

I've also spent a bit of time on the Marvell 8686 driver, as there is already some (not entirely polished and thus not mainline yet) GSPI transport code for the libertas driver. However, I didn't finish this since it is not the biggest priority right now. Also, interestingly, the GPIO and other related bits regarding the wifi chip are all present in the winCE registry. Marvell apparently made the driver in a way that E-TEN and others don't need any access to its source code but can fully parameterize it through the registry.

So as a summary: I was spending basically every awake minute during the last days on this project, but there's no real visible progress yet. I've just learned a lot, and hope to use that information soon to further improve the Linux port.

Oh, and by the way: It seems like I'll be talking about some of this work (and actually showing how it was done) at FOSS.in 2008 next week. Stay tuned for some good old fun ;)

As with actual progress on the device itself: I've spent quite a bit today again with reverse engineering some drivers, thereby discovering two GPIO's that seem to be related to GSM modem power management. Maybe that's the reason why my own humble attempt at a Linux GSM driver has so far been unsuccessful. I also seem to find an awful lot of indication that UART0 is actually connected to the GSM modem, too. This might be some strange copy+paste artefact from older glofiish devices' linux driver, or actually they might have two independent communications channel to the modem - wouldn't be the first time to see this.

Some other bits have hinted at an externally-provided UART clock, but that is apparently just a workaround of a S3C2442 serial controller bug.

I', still having fun wading through tons of ARM disassembly. It's been a long time since I last had any good reason to use IDA (Interactive Dis-Assembler) that much. It's the only proprietary software that I've been willing to license (and thus pay for) in something like a decade.

Le dépot http://downloads.openmoko.org/releases n'est plus accessible depuis quelques jours.

En effet Openmoko aiguise l'appetit de Sisvel.
Cette société s'est spécialisée dans l'exploitation de brevets à l'échelle internationale et s'est déjà attaquée à des entreprises comme SanDisk ou Thomson par le passé.

Comme pour les cas précédents, le (lucratif) sujet de discorde est la prise en charge des formats MP2/MP3 intégrée dans les images fournies par Openmoko.

Plutôt que de payer une licence d'exploitation exhorbitante, Openmoko a préféré retirer ses images pour en fournir d'autres où le support du MP2/MP3 sera retiré.

En attendant, les images "daily" sont disponible comme d'habitude à cette adresse :
http://downloads.openmoko.org/daily/

Pour information, il existe un autre format de compression ouvert et performant : le Ogg Vorbis (et un outil de conversion MP3 vers OGG).

Ce triste épisode nous rappelle le problème des Brevets Logiciels est toujours d'actualité.
D'ailleurs l'association APRIL lance une campagne d'adhésions afin de pouvoir peser dans la balance sur ce sujet (et de nombreux autres qui concernent la défense des Logiciels Libres) :

We are now 4 weeks after Openmoko announced the 'back to basics' plan. After one week they had all of us fooled. Most of us thought Openmoko hadn't done a thing. But a day later they gave us a rather long list of things they had done. After 2 weeks they even got a real name, the 'Optimization' team. In the 3th week some nice optimizations were made. And so we are at the 4th week.

What's on the menu?
Openmoko has planned a release before the end of this month. They want to surprise us with the release of Om2008.11. This release will most likely contain all the work done by the 'Optimization' team so far. You can find the list of bugs that they want to smoothen out here.

For that reason the 'Optimization' team will not begin new and huge tasks but will smoothen all the work already done. And do some minor bugs. So the testing team can begin testing the new release. So it's solid when it is released.

At which bugs will the Optimization team look?

• #69 speed up system initialization: Olv will merge his improvement into testing repo next week.
• #1489 sometimes volume is too low during a call: Tick will implement a volume control in qtopia dialer.
• #2031 scroll list implementation: Tick will improve etk_scroll_list to fit our designer's idea.
• #2113 suspend time come up right after you change the time: Jeremy will look into this.
  

Official status report

 I recently spoke about my intentions to develop some little games for Openmoko. I can now announce that my first project will be a Pong (yeah I know, I don't start big...). I just begun coding and already run into some difficulties. But I made a big step forward : I created an icon for my project. What? Isn't that a big step? Well you' re right...Here it is :

Nice, isn't it? And here an in-game screenshot :

 

Well now let's speak about the problem I have. I am developping this game with SDL. I am just drawing one black box and three white boxes and polling events (SDL_PollEvent(&event)), to know if there was a mouse click. That is not much and it is already lagging. Maybe polling is not the right thing to do? Also I've figured out that the "enable repeat" does not work for the mouse. I want to avoid continuous clicking and have a nice smooth movement while keeping  pressing on the screen... I will try to fix that during the weekend, more infos by the end of it.

During my seven hour stopover in Bangalore, I decided not to sleep and rather have a look about what I could do to find out more about the yet-unknown interface between the S3C2442B application processor and the 3.5G Modem in the E-TEN Glofiish M800.

Some initial poking in the WM6.1 registry led me to the (wrong) conclusion that UART0 might be used. It would have been a lot of data for a UART anyway...

So as it seems, they're using a SPI based interface. Not a bad choice, considering the various suboptimal alternatives. USB is way too heavyweight and power-consuming, and leads to inevitable problems when you want to resume the application processor from suspend (e.g. on incoming call). You just simply cannot afford the time to enumerate the USB, etc. Some shared memory / dual ported RAM interface like it is found in more integrated chipsets requires quite a bit of software work (synchronization of a shared memory region between two processors that have no common resources!) and requires a quite deep interface into the modem side. Something that E-TEN would unlikely get from Ericsson, I would say.

So SPI it is. Interestingly, the SPI master is in the modem, the S3C2442 acts as SPI slave. This adds the need for some kind of mechanism how the application processor can tell the modem that it actually wants to transmit an AT command. A simple GPIO line does that trick. The Modem responds by asserting the slave select line.

Interestingly, they even use DMA accelerated data transfers. So receiving data from the modem is less CPU intensive than reading data from NAND. What a crazy world.

Some more bits are found in the wiki.

I've already started to hack up a Linux driver. The SPI side is really simple. What is much harder is the fact that the Linux SPI core has no support for slave mode, and thus neither the in-kernel s3c24xx SPI driver. Furthermore, many of the traditional serial line analogies (baud rate, modem control lines, handshake, break, ...) no longer apply.

On top of the SPI, they seem to be running pretty standard AT commands. Nothing fancy at all. Thus, I'm optimistic that once the kernel driver is there, FSO or other userland can make use of it quite easily.

… Marcus Bauer, who writes TangoGPS (an app I like but rarely use because GPS eats battery), uses one of my rotate versions. Neat!

I really gotta make a new release, but first I must decide wether to move to FSO (of which I’m trying out fso-image since M4) or Debian. I’m kinda of bored of the “hard” way OpenEmbbeded paves for writing applications…

Here are my slides from last night’s presentation at the BLUG. I continue to be amazed about how interested some people in Beijing are about FLOSS, Network Services, and guangxi! We had a good discussion about why some people contribute to open source. Similar to many trends with FLOSS communities, most people were into contributing because they wanted to learn more. Some said they were interested in meeting new people while a couple of folks mentioned how their contributions got them a job — something recurring with many of my friends (myself included).

Why Share Source & High Priority Free Culture Projects Beijing LUG 2008 Get your own at Scribd or explore others: Technology General culture high

I then drilled down and started a discussion about what are possible priorities for FLOSS, then Free Culture, and then Autonomo.us network services. This then segued (not the nerd chariot) into a discussion about what the attendees top 3 priorities are and what the top priorities are for Chinese FLOSS communities.

Some stated that translation and localization are critical for Chinese FLOSS communities. However, we are not talking about just change some strings. What Chinese users prefer is a localized interfaces. CEO of Mozilla Online, Li Gong, told me this as well the other day — Chinese users prefer their own cultural interface.

Then I met Peter Junge, who organized the OpenOffice.org conference last week and sponsors the BLUG free beer through his employer Red Flag. I learned from him that Red Flag does just this by creating their own positive fork of OpenOffice.org called Red Office, which provides a cultural interface. Try it out, Clayton Cornell, from Sun said it is an interested usable interface.

The most interesting and tangible should be priority for Chinese FLOSS communities came from a fellow named Anthony Wong who said there is no good quality FREE (as in CC BY-SA or GNU FDL) Chinese dictionary for FLOSS. Currently, most people use proprietary dictionaries with StarDict. We discussed this further and what it would take to get this to happen and came to the idea that its:

• A great tangible project
• Should integrate with wiktionary and provide some filters for converting to StarDict and other formats
• Could take advantage of Chinese Public Domain rules to slurp in dictionaries
• Great project for those learning Chinese (like me!

There are still some other issues which need to be investigated such as pulling Traditional Character dictionaries from Taiwan or Hong Kong and/or other sources and converting the characters. Regardless, the goal is to make a Chinese Dictionary for free culture that anyone may contribute to to make better. Hopefully, no sensitive words will be filtered either! NOTE: Please, if you know more about this and/or have resources which can disprove the need or corroborate the need for this project, please do post a comment on this post.

Then, just yesterday I met up with Prof. Wang Chunyan, who is public project lead of Creative Commons Mainland China, along with new buddy Zafka, Handong and Stephen from CC China. We discussed all things CC China, how great their 2nd Annual photo competition is going with some 2000 high quality entries thus far, their upcoming CC B-Day in December, and what are the rules for Chinese Public Domain Status of creative works. I will save that for another post, but sounds approximately like works are in the public domain prior to 1957 in China right now. Then, government documents, official news, legislation, case law, and all official translations are uncopyrightable, with one caveat. Uncopyrightable works must have a form of attribution to the government in the form of a legal citation.

Overall, great last few days increasing my guanxi points while all you guys are checking your twitterrank asking if you are the real spamking As I started to outline in a previous post, the main things I want to follow up on with this discussion of priorities is for us in FLOSS, Free Culture, and Autonomo.us worlds to develop a list of top 10 priorities for a year which give contributors nice goals to work on. I really wish a project (which I won’t name here publicly but has an i and c in the name) could have taken this on to catalyze development and collaboration between FREE communities as the FSF has modelled so well with their high priority project list. However, we (myself included) are not ones to sit on our haunches and wait for a list of priorities! We hack for fun and incentives!

If anyone finds this interesting, please do post up what you think are priority projects for FLOSS, Free Culture, and Autonomo.us Network Services. If you have insight into China, please post that as well. I will brew this some more and come up with some summary of some collective priorities for associated communities.

The other take away is that it sounds like this Chinese Dictionary project, unless some pre-established work is done on this, is a good new project to build up with my Chinese colleagues

For the distracted OpenMoko Portuguese users and fan’s, tomorrow will be held a conference about OpenMoko in the Sapo Codebits event. Marcus Bauer, the TangoGPS creator, will talk about development of applications for the Neo Freerunner. I will post a video of the conference in the next days (the organization will record all the talks).

Sapo Codebits is a event inspired in Y! Hack Day, but with some addons, the event is composed by a programming and art contest, conferences, workshops and music concerts. I will participate in the programming contest, I probably will do some small application for my Neo Freerunner :).

USB host mode is a funny thing on the FreeRunner; it's one of the killer features of this phone, yet the means and ways of getting it working are never really as clear as they could be. The Openmoko wiki, for example, used to say that you needed new kernel modules to get host mode to work; when I asked about these modules I was told that they had been included for some time, and all you actually needed was to run a quick command or two. These I added to the wiki straight away...

The command line is a bit of a pain, however, especially if you want to enable USB host mode to use a keyboard. Keyboards are fun; and I'd previously said that we'd come up with a button to swap between modes. This is easily doable:

[EDIT]: By popular request I've packaged this all into an ipk file: Here

From the (now much improved) USB host Wiki page we get a helpful script that determines the current state of your USB mode and switches to the other:

#!/bin/sh
grep -q 'host' /sys/devices/platform/s3c2410-ohci/usb_mode
if [ $? -eq 0 ]
then
echo "0" > /sys/devices/platform/neo1973-pm-host.0/hostmode
echo "device" > /sys/devices/platform/s3c2410-ohci/usb_mode
echo USB-Port is in device-mode now.
else
ifconfig usb0 down
echo "host" > /sys/devices/platform/s3c2410-ohci/usb_mode
echo "1" > /sys/devices/platform/neo1973-pm-host.0/hostmode
echo USB-Port is in host-mode now.
fi

Create a file in an appropriate place named usb.sh and containing the above. This could be your home folder, or along with the rest of your applications. Chmod +x it.

Find a suitable icon for your button; I Googled up this one, although anything up to 64x64 pixels will do. Remember that png supports transparency and that the background on the FreeRunner is, by default, black. So pick something you'll be able to see! Save the file to /usr/share/pixmaps/usb.png

Create the file /usr/share/applications/usb.desktop

[Desktop Entry]
Encoding=UTF-8
Name=USB Mode
Comment=Switch between USB modes
Exec= /path/to/usb.sh
Icon=usb
Terminal=true
Type=Application
Categories=Application;Utilities;
SingleInstance=true
StartupNotify=true

Once that file is created and saved, you'll have a new icon menu on your main screen.

Ever since my blog post about certain E-TEN glofiish devices in late August, it might have been obvious that I've been up to something.

In fact, I didn't have much time, as usual. Finally, after something like about two full days of work, I can present some preliminary results: root@glofiish-m800:/proc# cat /proc/cpuinfo Processor : ARM920T rev 0 (v4l) BogoMIPS : 176.53 [...] Hardware : Glofiish M800 Revision : 0000 Serial : 0000000000000000 root@glofiish-m800:/proc#

You can also find a preliminary wiki page about the current status of hardware reverse engineering in the OpenEZX wiki. It doesn't really related to EZX or OpenEZX at all, but it somehow is related to the same thing: Bringing kernel+rootfs based 100% on open source to phones without vendor support. It also doesn't really fit into the Openmoko wiki, since as you can assume, this is by no means a project of Openmoko, Inc.

So far, it was pretty easy. I was taking the 'stable' branch of the Openmoko kernel git tree, adding minimal platform support to it (to get framebuffer, microSD and USB device working), and using haret to boot into a fso-terminal-image located on a microSD card.

Of course the really hard work now starts, getting all the hardware properly supported, especially the communication with the GSM Modem, as well as the power management related bits. Nonetheless, a foundation is laid, and I expect it to be not too hard to continue from here.

So maybe, if I can find sufficient time, we will see FSO on a 3G phone at some not-too-distant point in the future.

Now some of you might be asking: Why am I not working on improving the code for the Openmoko, Inc. handsets GTA01 and GTA02? Isn't it bad to support a non-open hardware manufacturer, plus pay the Windows Mobile license tax on a device, ...? After all, Openmoko, Inc. current business model is centered around the sales of their own hardware to support for the software development!

I don't think that this is much of a competition to Openmoko. Obviously, everyone wants truly open hardware, such as what Openmoko, Inc. is trying to do. Nonetheless, people (especially geeks/nerds/hackers) want devices with 3.5G or at least 3G, they want devices with real keyboards, higher capacity batteries, better mechanical design, camera, etc. This is just something that Openmoko Inc. has not been able to provide so far. There's probably not many people on this planet who feel as sad about this fact as I do.

We are now 3 weeks (and a few days) after Openmoko announced the 'back to basics' plan. Let's look at the changes.

After one week they had all of us fooled. Most of us thought Openmoko hadn't done a thing. But a day later they gave us a rather long list of things they had done. After 2 weeks they even got a real name, the 'Optimization' team. Now the third week,

What are the main things they did?

• The boot time of a bare image (without any GSM stack) is reduced from 50 to 30 seconds. That was done by replacing the well known U-Boot by Qi. Qi is a boot loader developed by Openmoko with the focus to do just booting. It was developed, because u-boot was getting to big. It wanted to support everything and it began to look more on a kernel. Qi has focused to leave everything (except the booting) to the kernel. Even initializing the screen is considered the duty of the kernel. So a boot menu isn't included. You can do multi-boot by the times you press the power-button. It's not yet advised for replacing U-boot with Qi, because you will not be able to use dfu-util anymore.
  
• They also looked into reducing the network registering time at the Qtopia stack (The GSM stack that is used in Om 2008.9). They have been able to reduce it by 32 seconds. There are no images yet, but it will be merged in the future.
• Also the suspend/resume issues still get attention. They looked into various bugs, like #1991, #1347. The first bug is when you try to resume, it will stay a black screen. The later is when you try to resume, it immediate suspends again without any reason. For the first one, they have to do a little more debugging. For the latter, they found a fix, but they are looking into a better fix. Btw. There are patches for #1884. That's the bug, when you push the power-button just after suspending, it will do a double suspend. It will be submitted very soon.
• They also worked on their python loader for faster booting python applications. They could already reduce the load time of the pyhon sudoku from 2.59s to 1.38s.
  

Official status report

Sean McNeil is still actively porting the Android to the Neo FreeRunner. Today there were new images. For a getting started manual, look in my previous blogpost.

In short

1. Make compatible Linux kernel (done)
   
2. Replace ARMv5 specific code (done)
3. Create images (done)
   
4. Replace hardware specific code (done)
   - SMS (done)
   - Calling (done)
   - Wifi (in progress)
   - GPS (done)
   - Bluetooth (done)
   - Accelerators (done)
   
5. Adding additional software, like on-screen keyboard
   

In depth
Most of the devices are already working in the first image that Sean McNeil has posted. Though Bluetooth wasn't fully patched in the images, because Sean forgot to apply one patch. So it didn't work. With the new images (That you can find on the same location as the previous), Bluetooth works magically. In the new image is Wifi still not working in all situations and can be unstable.

The biggest improvement in the new image is the screen redraws. Sometimes you could see the redraws, for example when you opened the 'Shutdown menu'. That has now been solved by implementing 'Page flipping' for the Glamo.

What's next?
By looking at the porting strategy above, you will see that we just need one thing. W'e need a working on-screen keyboard, before we can fully use the Android. To bad for us, Sean will not start to make something like that. There are 2 reasons for that.

Firstly Google has announced they would make an input device management system with an onscreen keyboard in the first quarter of 2009. Secondly it isn't that easy for making a onscreen keyboard. At the moment there are no java bindings for letting a program insert keystrokes to other programs (Due to security constraints). So if you make an onscreen keyboard, you would have to change every program to work with your onscreen keyboard.

So what's next?
There is still plenty to do:

• Optimizing the code and all the patches. (And sending upstream)
  
• Making a way to accept incoming calls. (On the HTC G1, there is a accept call button)
• Let suspend work reliable