Categories
embedded systems English articles Openmoko OpenWrt Tech

OpenWrt is supporting the Openmoko GTA02 “Freerunner”!

It’s done – the Openmoko GTA02 “Freerunner” is running OpenWrt!

There’s lot’s of stuff to do but let’s see what I spent most of my time the last few months for:

– kernel (2.6.28) is building and booting (merging the Openmoko and OpenWrt patchsets, whereof one (and that’s not ours ;)) consists of either over 620 little non-atomic patches or one 10MB patchblob [kudos to git!], is no picnic (thanks to the work of Michael “mb” Buesch at this point!)
– D-Bus and the freesmartphone.org reference implementation (they import the libc.so.6 via ctypes – I was really puzzled when python told me it can’t find my libc, because I was using the uclibc)
– Xglamo with acceleration (in the beginning Xglamo just crashed, even JTAG wasn’t available anymore; it took us weeks to figure out that a compiler bug was the cause (thanks to Felix Fietkau, Holger Freyther and Lars Clausen) – Lars btw. is currently making good progress to get glamo acceleration working within Xorg)
– the EFL (enlightenment foundation libraries) and enlightenment including illume (needs some more love to make it really fit into the OpenWrt-environment – currently <edje_cc> and <eet> are required as pre-installed host tools)
– paroli phone application suite (in case it’s working ;))

A few days ago we established the first OpenWrt<->OpenWrt phone call which worked out of the box after flashing our devices!

Hurray! 🙂

Categories
embedded systems German articles Tech Windows Mobile

1st try of GUI-programming on WindowsCE: MPD-remote-control in python for “Windows Mobile/CE”

“Windows Mobile”-Client fĂŒr MPD (Music Player Daemon)

Da ich bisher keine gescheihte und freie Möglichkeit gefunden habe “irgendwas” ĂŒber mein (******-)WM-Handy zu steuern, habe ich mich jetzt mal rangesetzt und mich nach einer Möglichkeit umgesehen eine GUI ohne diesen .NET-sh1t auf dem PPC zu erstellen.
Da ich sowieso bereits die Python-Umgebung auf dem Teil habe (und ich ja auch ein großer Fan dieser Sprache bin) habe ich mich nach einer TKinter-Portierung umgesehen. Diese existiert (http://fore.validus.com/~kashtan/) und funktioniert auch, jedoch ist das nicht die native WinCE-GUI, was heißt, zusĂ€tzliche Libs sowie ein anderes look’n’feel (wobei letzteres gegenĂŒber der WinCE-GUI nix heißen muss).
Ich suchte also weiter und bin auf eine Python-Lib gestoßen, welche ein API auf die WinCE-Gui bot: VensterCE (http://sourceforge.net/projects/vensterce). Es ist noch in der Entwicklung, reichte jedoch fĂŒr meine Testapplikation völlig aus.
Ich bastelte mir also (ĂŒberraschend schnell) eine (funktionierende) Applikation in Python, welche ĂŒber TCP/IP mit dem MPD sprach.
Der MPD (http://www.musicpd.org/) ist ein ressourcensparender extrem kleiner mp3-player-daemon, welcher sich ausschließlich ĂŒber TCP/IP steuern lĂ€sst. Weitere – auch grafische – Clients fĂŒr den MPD lassen sich hier finden: http://www.musicpd.org/clients.shtml.
Das Resultat kann sich in meinen Augen – fĂŒr ein Testprogramm – sehen lassen:

wm-mpc sowie wm-mpc

Wer Interesse daran hat soll sich melden. Ich möchte das jetzt nur nicht in solch einer unfertigen Version zum Download anbieten, da das Ding noch ein paar Bugs besitzt.

Categories
embedded systems German articles Tech

everything is total b0rken


Mein eigentliches Ziel welches ich mit den hier z.T. vorgestellten Komponenten verfolg(t)e soll in einer kleinen Bildergeschichte veranschaulicht werden.

Die Theorie:
+ + + + = die perfekte Multimedia- und TV-Lösung

Nochmal die lange Geschichte in kurz, welche die Praxis erlĂ€utert: Am Anfang war die xbox, welche auch gleich (erfolgreich) die Stellung als Multimedia-Center einnahm. Dann kam die nslu2 und die Idee aus xbox + nslu2 eine TV-Lösung aufzubauen. Via eBay bestellte ich mir die Terratec Cinergy T2 – DVB-T-Box. Auf der nslu2 ließ sich jedoch das MythTV-Backend nicht kompilieren (auch dass es ganze 3 Tage gedauert, bis es mit einem Fehler abbrach hat die Sache nicht besser gemacht (natĂŒrlich mehrmals mit verschiedenen Compilern versucht)). Zudem schĂ€tze ich die nslu2 mit ihren 266 MHz fĂŒr ein wenig schwach ein, um dvb-t in schön (deinterlacing, etc.) zu decodieren. Also holte ich mir fĂŒr wenig Geld ein IBM Thinkpad T21 (siehe ein paar Posts zuvor) ohne alles, was aber lĂ€uft und nun auch erfolgreich von der nslu2 via pxe bootet. Dieses sollte dann den DVB-T-Kram ĂŒbernehmen, hat aber nur USB 1.1 (die DVB-T-box benötigt USB 2.0), weswegen ich mir eine USB2-PCMCIA-Karte kaufte. Dies elĂ€uft aber nicht mit der DVB-T-Box (waurm auch immer), ebenso wie eine 2. Karte mit anderem Chipsatz. Auch mit zusĂ€tzlicher Stromzufuhr (http://www.linuxforen.de/forums/showthread.php?t=223377) und ein paar sonstigen Experimenten war nichts zu machen. Zudem klackert meine grĂ¶ĂŸte Festplatte an der nslu2 nur noch lautstark rum, dass super Maxtor-festplatten-Diagnose-foobar-Programm ist aber der Meinung die Pladde sei voll i.O. womit ich keinen Fehlercode bekomme, welchen ich benötige, um auf der tollen interaktiven Maxtor-Webseite die Garantieabwicklung fortzusetzen.

3veryth1nG 1s t0t4l b0rk3n…

Categories
embedded systems German articles Tech

2-Komponenten-Server-Lösung

Ich bin ja bisher sehr zufrieden gewesen mit meiner Router-Router-NSLU2-Lösung gewesen (Router 1 (wgt634u) routet und fungiert als openvpn-server, Router 2 (wl500g) als WLAN-AP und Printserver und meine NSLU2 als Data-Storage).

Auch wenn die NSLU2 mit (anti-untertakteten 266 mhz ARM) recht schnell fĂŒr solch ein openembedded-device ist, reicht die Rechenleistung nun nicht mehr aus (dazu, was darauf hĂ€tte laufen sollen, in einem anderen Post).

Erster Gedanke war, ein richtiger Rechner als Homeserver muss her, jedoch haben mich folgende Nachteile entschieden von dieser Idee abgebracht:

– teuer

– laut

– stromfressend

– groß

Jeder Punkt fĂŒr sich hĂ€tte bei mir schon starke Bedenken ausgelöst, aber alle 4 Punkte zusammen kamen gar nicht in Frage – eine andere, elegantere Lösung muss her:

Ein Thinclient ! … ?

Jedoch ein Modell was die Anforderungen erfĂŒllt, die ich erwarte (CPU ~600 mhz), war unverhĂ€ltnismĂ€ĂŸig teuer (eBay, etc.).

Bei einem Treffen der BeLUG (Berliner Linuxusergroup) dann die Lösung!

Jemand hatte ein altes Notebook ohne Display, ohne HDD und mit extrem schwachen Akku zu verkaufen – die perfekte kleine, leise, stromsparende Rechenmaschine fĂŒr mein Vorhaben! Und dazu noch QualitĂ€t! Ein IBM Thinkpad T21.

thinkpad_t21

CPU: 900 Mhz P3

RAM: 128 MB (wird aufgestockt – hat wer Notebook-SD-RAM fĂŒr mich)?

USB: 1.1 (brauch noch ne PCMCIA-USB2-Karte)

Dazu halt noch Ethernet, pcmcia, serial, parallel.

Aufteilung wird dann so sein: Thinkpad soll nur rechnen und via PXE von der nslu2 starten. NSLU2 fungiert als reines Data-Storage und ĂŒberlĂ€sst Rechnungen dem Thinkpad.

Soweit die Theorie. Sobald meine Haupt-data-Platte von Maxtor ersetzt wurde (klackert gut) kanns dann auch losgehen 😉

Werd euch auf dem Laufenden halten!

So long…

Categories
embedded systems German articles Tech

loop-AES lÀuft nun auch auf der NSLU2

Moin!

Habe vor wenigen Minuten endlich auch loop-AES auf der NSLU2 zum Laufen gebracht – unter DebianSlug.

Es ist ein normales littleEndian Debian-ARM-System. Es laufen ein SSH- und userspace-NFS-Server.

Hier die ersten Benchmarks:

foo.img ist ein 60MB großes aus Nullen bestehendes Image 🙂

Das NFS-Volume ist eine ĂŒber USB2.0-angeschlossende Platte – NICHT VERSCHLÃƓSSELT!

[daten@alice:~] $ time cp foobar/foo.img /Volumes/192.168.1.39-1/

real   0m18.774s
user   0m0.002s
sys    0m0.876s
> 3 MB / s – man muss aber dazu sagen, dass die NSLU2 ĂŒbertaktet ist und hier keine weiteren Dienste grad laufen.

Mit loop-AES-encryption sieht das ganze schon wieder ein wenig anders aus:

[daten@alice:~] $ time cp foobar/foo.img /Volumes/192.168.1.39/

real   0m50.315s
user   0m0.002s
sys    0m0.885s

Das Image ist immernoch 60 MB groß, das ĂŒber NFS eingehangene Volume ist jetzt aber AES256 Bit verschlĂŒsselt.

~1 MB / s – nicht gerade viel aber im Gegensatz zu meiner vorherigen WGT634U-Lösung mit rund 200 KB / s eine 500%-Steigerung 🙂

Ich geh’ pennen – gut n8

Categories
embedded systems German articles Tech

NSLU2 (Network Storage Link USB 2) da und gemodded

Hab’ lange nichts mehr von mir hören lassen, da ich leider noch einiges zu tun hatte (Klausuren, Arbeit, etc.); es hat sich jedoch einiges getan.

Ich habe (m)eine Linksys nslu2 bekommen (und auch gleich von 133 Mhz auf 266 Mhz hichgetaktet (oder besser anti-untertaktet), indem ein einfacher Widerstand rausgelötet wurde). 😛

NSLU2

Leider ist dort ein nicht standardmĂ€ĂŸiger intel-LAN-Chip verbaut, fĂŒr welchen es noch keine freien Treiber und deshalb hier leider Lizensproblematiken gibt (Debian z.B. weigert sich (verstĂ€ndlicherweise) nicht-GNU-Software in ihr Standardrepository mit aufzunehmen, weshalb es hier ein wenig Bastelei (welche glĂŒcklicherweise bereits andere Leute gemacht haben) bedarf, bis der Debianinstaller mit nativem nslu2-Ethernet-support durchlief.

Zudem gab es hier auch noch die Problematik, dass das Standarddebian und dessen gesamtes Paketrepository in der LittleEndian-Bytefolge kompiliert wurde, der vorkompilierte intel-Treiber jedoch nur im BigEndian zur VerfĂŒgung stand. Dieses Problem wurde jedoch auch schon gelöst – der Treiber steht nun auch in LittleEndian zur VerfĂŒgung.

Jetzt bin ich grad’ dabei mir einen eigenen Kernel fĂŒr die nslu2 zu compilen, da der Standardkernel einige Designfehler zu enthalten scheint und versuche krampfhaft meine Buildroot-Umgebung zum Laufen zu bekommen.

Zu einem spĂ€teren Zeitpunkt werde ich dann Benchmarks machen und evtl. den RAM nachrĂŒsten.
Bis jetzt kann ich nur sagen, dass dies wirklich mal relativ anstÀndige Hardware zu sein scheint (intel XScale 266 MHZ ARM-based cpu).

So long…

Categories
embedded systems German articles Tech

katastrophale Transferrate beim WGT634U / Alternative?

Moin!

Also vom Aufbau her ist jetzt alles wie ich es mir vorgestellt habe. Der WGT634U verdient den Namen “Router” nun wirklich und wird seinen Aufgaben als NFS-/Samba-, OpenVPN- und XlinkKai-Server und Torrent-Client gerecht.

Sogar meine Rechner booten via PXE von ihm, es lĂ€uft mein irssi, silc und muttng in einer screen-Session – eigentlich alles perfekt.

ABER: Die Datentransferrate ist miserabel! Es wird zwar gesagt, dass der Router einen USB2-Port besitzt, aber die Übertragungsrate kommt bei weitem nicht einmal an die von USB 1.1 heran – leider.

Der limitierende Faktor ist hier die CPU.

FlĂŒssiges mp3-Streamen geht noch sobald z.B. ein Torrent und der OpenVPN-Server lĂ€uft – beim Streamen von Videos ist hier aber schon Schluss.

Die Transferrate liegt beim Laufen des NFS-/Samba- und OpenVPN-Servers etwa bei 300 kb/s – das ist einfach mal dreckig!

Abhilfe schafft hier evtl. eine neue Anschaffung 🙂

Eine Linksys NSLU2.

Diese bietet 2 USB2-AnschlĂŒsse, ein Ethernet-Interface und von Haus aus nur die Funktionen eines Network-Storage’s. Eine bessere Transferrate erhoffe ich mir durch die bessere CPU (Intel XScale 266 Mhz, um einiges leistungsfĂ€higer als die in den Routern verbaute mips), sowie dann dessen einzige Aufgabe als NFS-/Samba-Server zu fungieren.

Als Alternative zur originalen Firmware kommt hier derzeit nur OpenSlug in Frage. Es wird jedoch derzeit auch an einem OpenWrt-Buildroot fĂŒr die intel XScale-Prozessoren gearbeitet, welche dann hoffentlich auch ein Firmwareimage fĂŒr die NSLU2 backen können.

Die durchschnittliche Datentransferrate soll hier bei ca. 5 MB / s liegen, was fĂŒr meinen Bedarf vollkommen ausreicht. Hier wird es aber wieder einen Abzug aufgrund der von mir angewandten 256-Bit AES-encryption geben des daran hĂ€ngenden Devices geben, welcher sich prozentual gesehen aber hoffentlich in einem akzeptablen Bereich befindet.

Ich freu mich 🙂

So long…

Categories
embedded systems German articles Tech

WRT putt und wieder heile gemacht

Zur Abwechslung habe ich mal wieder meinen WRT54G geschrottet. Die Power-LED blinkte nur noch heftigst – vom Anstecken des Stromsteckers an.

Ich hatte schon Angst das Teil hardwareseitig geschÀdigt zu haben, da ich zuvor versuchte den SD-Card-Mod zu realisieren (4 MB Flash sind doch etwas wenig).

Das DĂ€mliche war, dass dies scheinbar (oder meine verzweifelten nĂ€chtlichen Versuche danach das Ding wieder zum Leben zu erwecken) den NVRAM zurĂŒckgesetzt hat/haben und damit boot_wait auf off gesetzt wurde.

Bauteile fĂŒr ‘ne serielle Schnittstelle hatte ich fĂŒr den WRT leider nicht parrat und da innerhalb der nĂ€chsten Tage kein GeschĂ€ft offen hatte, in welchem ich mir solche hĂ€tte holen können (ich hasse Ostern :P), hab ich durch ein wenig Lesen im Netz mich entschieden den Flashspeicher kurzzuschließen (Pin 15+16) und siehe da – das Teil begab sich in den Debugmodus in welchem es wieder bereit war via TFTP Images entgegenzunehmen 😀

Nu funzt das gute StĂŒck wieder – JUHUU !!! 🙂

Auf ein neues Anlöten der SD-Karte – diesmal hoffentlich richtig.

Frohe Ostern! 🙂

Categories
embedded systems German articles OpenWrt Tech

Es ist getan – loopAES lĂ€uft auf OpenWrt!

Hi!

Es ist vollbracht! LoopAES ist auf den KAMIKAZE-branch von OpenWrt portiert – und es lĂ€uft.

Zwar nicht außerordnetlich gut, aber immerhin besser als unter WHITE RUSSIAN (kernel 2.4).

Hier einige erste Benchmarks:

Es wurde ein 100 MB-Image via NFS einmal auf eine verschlĂŒsselte und einmal auf eine unverschlĂŒsselte Partition eines am WGT634U angeschlossenen USB-Sticks kopiert:

Cipher: None (unencrypted)
# time cp image /wgt/notenc/
real 2m55.925s
user 0m0.005s
sys 0m0.532s

Cipher: AES256

# time cp image /wgt/enc/
real 5m32.948s
user 0m0.010s
sys 0m0.517s
Es wird noch optimiert werden. Wer die Sourcen haben will soll ‘n Comment schreiben.

Ich glaube die nacht wird noch lang 🙂

Categories
embedded systems German articles OpenWrt Tech

dm-crypt laeuft – aber scheiße

Hi!

Endlich habe ich es geschafft dm-crypt fĂŒr OpenWRT zum laufen zu bekommen – wirklich nach etlichen Stunden Arbeit.

Dementsprechend groß war auch die EnttĂ€uschung, als ich ein paar Benchmarks erstellt habe.

Ein 10 MB großes File auf eine verschlĂŒsselte Partition (dm-crypt) auf den WGT634U mit USB 2.0 und 200 MHz-CPU zu schreiben dauert genauso lange, wie das Schreiben des selben Files auf eine verschlĂŒsselte Partition (loopAES) auf den WL500G mit 125 MHz-CPU und USB 1.1.

Der Geschwindigkeitsvorteil, den ich mir durch den WGT634U in Sachen schreiben/lesen auf verschlĂŒsselte Partitionen erhofft habe ist somit nichtig.

dm-crypt scheint so oberflÀchlich betrachtet auf langsamer und unkonventioneller Hardware definitiv loopAES unterlegen zu sein.

Das Problem an der Sache ist, dass ich loopAES nicht fĂŒr den KAMIKAZE-branch von OpenWRT (kernel 2.6) portiert bekomme.

Der jetzige stabile Zweig “White Russian” mit dem 2.4er Kernel lĂ€uft ja nicht auf dem WGT634U, weswegen ich mich jetzt an die Portierung von loopAES fĂŒr KAMIKAZE mache 😉

Wer dennoch Interesse an den dm-crypt Paketen hat, soll nen Comment schreiben.

So long…