Openmoko

Table of Contents The Story Technical Specifications Prototypes & First production run (2012) Next production run (2013) – Out now! OpenPhoenux ecosystem Some more Goodies The Story All started off after Openmoko Inc. began to ship the ... [More] Openmoko Neo 1973 (GTA01) and Neo Freerunner (GTA02) in 2007, which are fully open source smartphones. A dream became true for many open source lovers and technology enthusiasts at that time. Sadly, Openmoko Inc. canceled their efforts for an open smartphone in 2009. But due to their openness (schematics, hardware specifications, software) it was possible for enthusiasts from the Openmoko community, with great support from Golden Delicious Computers (one of the german Openmoko distributors), to develop a new and modern open smartphone – the OpenPhoenux GTA04. Technical Specifications 1GHz ARM Cortex-A8 processor (DM3730) PowerVR integrated graphics (SGX530) 2.8” resistive VGA touchscreen HSDPA 3G modem (Option GTM601) 512MB RAM 1GB internal memory & SDHC card slot (up to 32GB) WLAN, Bluetooth, GPS, FM Transceiver Accelerometer, Compass, Gyroscope, Barometric Altimeter USB 2.0 OTG port, 2.5mm headset port, GPS antenna port, video out Prototypes & First production run (2012) Golden Delicious Computers and the enthusiasts from the Openmoko community started off with the idea of stuffing a BeagleBoard into a Neo Freerunner case and connecting an USB UMTS dongle to it – this was the first prototype GTA04A1, announced in late 2010 and presented at OHSW 2010 and FOSDEM 2011. Next, they started to integrate all of this onto a single PCB of the same size as the Neo 1973/Freerunner boards, so it could fit into their cases, use their batterys, antennas, speakers, buttons and touchscreens. This board was then called GTA04A2 – the second prototype, which had quite some problems. A redesign of that prototype resulted to the GTA04A3 “Early-Adpoter” boards, which were shipped to about 20 develpoers, enabling them to start with software development for the platform. The next step was to reach out to the people by presenting the project on other conventions like the FOSDEM 2012, Openmobility 2012, Linuxwochen 2012 and the LinuxTag 2012, to produce bigger batches of GTA04s. To finance the first production run of the GTA04A4 (which includes some more fixes over the GTA04A3) Goldelico collected pre-orders from interested people from the Openmoko community. They were able to collect about 250 pre-orders and were thus able to start the first big OpenPhoenux production run. GTA04 Boards in vabour phase soldering machineUnfortunately, “mass”-production turned out not to be an easy task. Goldelico had to find, analyse and solve a lot of problems within the production line and especially in the soldering process, which took a lot of time. Because of all the troubles the people who pre-ordered in the beginning had to wait about 1 year to finally get their devices. At the end of 2012 all problems were solved and the “Group-Tour” had successfully finished. The GTA04 team is very happy to have reached that big milestone. Now that there are about 300 GTA04s (A3+A4) out in the wild, the interest in the Linux/FOSS community seems to be growing for our project. To satisfy that growing demand Goldelico will happily produce more GTA04s of revision A5 (which will include some minor fixes over the A4). “Now as we have finally learned everything about mass production [...], it is time to kick-start the next [production run].” (Dr. Schaller, Golden Delicious Computers) Next production run (2013) – Out now! To finance the 2nd production run of about 200 more GTA04 boards Goldelico started to collect pre-orders just recently. The production should run smoothly that time, as there were no big changes and the process is known. Production will start in march 2013 and the boards should ship shortly after that. If you’re interested in pre-ordering one of those new A5 boards, check out the Handheld-Linux store. If you’re interested in getting a complete “OpenPhoenux 2804″ unit (GTA04 board build into an Openmoko Freerunner case) now you can get it from the first OpenPhoenux reseller Pulster.eu (stock is limited!). Pre-order your GTA04 (revision A5) now. Buy an OpenPhoenux 2804 (revision A4) from stock. OpenPhoenux ecosystem While preparing the next revision of the GTA04 and solving production problems, the guys at Goldelico started to experiment with other GTA04 powered devices. So it is no secret, that there is already an open GTA04 tablet prototype (OpenPhoenux 7004) and the ready to use GTA04 industrial module (OpenPhoenux 3704), which can be used e.g. in logistics (RFID), measurement (GPS) or guiding tasks (big sunlight readable screen & long lasting battery). The software for the GTA04 is already in a good shape as well. Besides the Debian (squeeze) hardware-validation image, there is the Debian based QtMoko distribution and the FSO based SHR distribution, which makes the GTA04 useable as a daily phone. Furthermore, a port of Replicant (fully open source Android) is in the works. All in all the GTA04 owners in the OpenPhoenux community seem to be satisfied with their devices, so is Nikolaus Schaller from Goldelico: “[...] I enjoy every day to be member of this OpenPhoenux community. Let’s make the OpenPhoenux fly to new levels next year!” (Dr. Schaller, Golden Delicious Computers) I really appreciate to see our community grow again and can just second Nikolaus’ sentence. I wish the community a successful year 2013, in which we can satisfy a lot of free software enthusiasts and freedom lovers needs. OpenPhoenux – Free your phone! Some more Goodies There are still some more goodies in the pipeline… So stay tuned! [Less]

The document is here: http://en.qi-hardware.com/wiki/Mini-slx9.

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by ... [More] means of a Duplexer. The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture: The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit. The second picture shows the top section of the duplexer: You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture. The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities. The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output. [Less]

Quite frequently, I need to take a quick textual note but when the content is sensitive, even just transiently, well, some things shouldn’t be left around on disk in plain text. Now before you pipe up with “but I encrypt my home directory” keep in ... [More] mind that that only pretects data against it being read in the event your machine is stolen; if something gets onto your system while it’s powered up and you’re logged in, the file is there to read. So for a while my workflow there has been the following rather tedious sequence: $ vi document.txt $ gpg --encrypt --armour -r [email protected] -o document.asc document.txt $ rm document.txt $ and later on, to view or edit the file, $ gpg --decrypt -o document.txt document.asc $ view document.txt $ rm document.txt (yes yes, I could use default behaviour for a few things there, but GPG has a bad habit of doing things that you’re not expecting; applying the principle of least surprise seems a reasonable defensive measure, but fine, ok $ gpg < document.asc indeed works. Pedants, the lot of you). Obviously this is tedious, and worse, error prone; don’t be overwriting the wrong file, now. Far more serious, you have the plain text file sitting around while you’re working on it, which from an operational security standpoint is completely unacceptable. vim plugin I began to wonder if there was better way of doing this, and sure enough, via the volumous Vim website I eventually found my way to this delightful gem: https://github.com/jamessan/vim-gnupg by James McCoy. Since it might not be obvious, to install it you can do the following: grab a copy of the code, $ cd ~/src/ $ mkdir vim-gnupg $ cd vim-gnupg/ $ git clone git://github.com/jamessan/vim-gnupg.git github $ cd github/ $ cd plugin/ $ ls Where you will see one gnupg.vim. To make Vim use it, you need to put in somewhere vim will see it, so symlink it into your home directory: $ mkdir ~/.vim $ mkdir ~/.vim/plugin $ cd ~/.vim/plugin/ $ ln -s ~/src/vim-gnupg/github/plugin/gnupg.vim . $ Of course have a look at what’s in that file; this is crypto and it’s important to have confidence that the implementation is sane. Turns out that the gnupg.vim plugin is “just” Vim configuration commands, though there are some pretty amazing contortions. People give Emacs a bad rap for complexity, but whoa. :). The fact you can do all that in Vim is, er, staggering. Anyway, after all that, it Just Works™. I give my filename a .asc suffix, and ta-da: $ vi document.asc the plugin decrypts, lets me edit clear text in memory, and then re-encrypts before writing back to disk. Nice! For a new file, it prompts for the target address (which is one’s own email for personal use) and then on it’s way. [If you’re instead using symmetrical encryption, I see no way around creating an empty file with gpg first, but other than that, it works as you’d expect]. Doing all of this on a GNOME 3 system, you have a gpg-agent running, so you get all the sexy entry dialogs and proper passphrase caching. I’m hoping a few people in-the-know will have a look at this and vet that this plugin doing the right thing, but all in all this seems a rather promising solution for quickly editing encrypted files. Now if we can just convince Gedit to do the same. AfC [Less]

Soon this years Open Hard- and Software Workshop (OHSW) will take place in Garching (near Munich) at the TUM Campus Garching. There will be a lot of intetresting topics to discuss and people to meet. Make sure to drop by if you find some time! The ... [More] agenda and further details are now available online: OHSW Homepage Agenda OHSW 2012 Further details about OHSW 2012 [Less]

The OpenPhoenux GTA04 production is finally making nice process. All the GTA04A4 (Group Tour 1) preorders should be ready and shipped soon! This is the lastest batch of devices, which has sucessfully passed Golden Delicious Computers’ QA process and ... [More] fulfilled the high quality claims. After a lot of production issues had to be solved in the last months, we’ve now found a method which provides us with a good production yield. After switching to vapour phase soldering [0], we got rid of most the soldering problems. GTA04 boards in the vapour phase soldering machine (1/2)GTA04 boards in the vapour phase soldering machine (2/2) Happy hacking to all new GTA04 owners! [0] http://lists.goldelico.com/pipermail/gta04-owner/2012-October/003241.html [Less]

So back from layout into graphics again! For the last few weeks, I've been working with Benoit Girard on getting progressive tile rendering finished and turned on by default in Firefox for Android. The results so far are very promising! First, a bit ... [More] of background (feel free to skip to the end if you just want the results). You may be aware that we use a multi-threaded application model for Firefox for Android. The UI runs in one thread and Gecko, which does the downloading and rendering of the page, runs in another. This is a bit of a simplification, but for all intents and purposes, that's how it works. We do this so that we can maintain interactive performance - something of paramount important with a touch-screen. We render a larger area than you see on the screen, so that when you scroll, we can respond immediately without having to wait for Gecko to render more. We try to tell Gecko to render the most relevant area next and we hope that it returns in time so that the appearance is seamless. There are two problems with this as it stands, though. If the work takes too long, you'll be staring at a blank area (well, this isn't quite true either, we do a low-resolution render of the entire page and use that as a backing in this worst-case scenario - but that often doesn't work quite right and is a performance issue in and of itself...) The second problem is that if a page is made up of many layers, or updates large parts of itself as you scroll, uploading that work to the graphics unit can take a significant amount of time. During this time, the page will appear to 'hang', as unfortunately, you can't upload data to the GPU and continue to use it to draw things (this isn't true in every single case, but again, for our purposes, it is). Progressive rendering tries to spread this load by breaking up that work into several smaller tiles, and processing them one-by-one, where appropriate. This helps us mitigate those pauses that may happen for particularly complex/animated pages. Alongside this work, we also add the ability for a render to be cancelled. This is good for the situation that a page takes so long to render that by the time it's finished, what it rendered is no longer useful. Currently, because a render is done all at once, if it takes too long, we can waste precious cycles on irrelevant data. As well as splitting up this work, and allowing it to be cancelled, we also try to do it in the most intelligent order - render areas that the user can see that were previously blank first, and if that area intersects with more than one tile, make sure to do it in the order that maintains visual coherence the best. A cherry on the top (which is still very much work-in-progress, but I hope to complete it soon), is that splitting this work up into tiles makes it easy to apply nice transitions to make the pathological cases not look so bad. With that said, how's about some video evidence? Here's an almost-Nightly (an extra patch or two that haven't quite hit central), with the screenshot layer disabled so you can see what can happen in a pathological case: And here's the same code, with progressive tile rendering turned on and a work-in-progress fading patch applied. This page is a particularly slow page to render due to the large radial gradient in the background (another issue which will eventually be fixed), so it helps to highlight how this work can help. For a fast-to-render page that we have no problems with, this work doesn't have such an obvious effect (though scrolling will still be smoother). I hope the results speak for themselves :) [Less]

Ledtoy created by Werner, it is a LED-based signal device (for viewing from up to ~10 m),  which uses motion to produce 2D images with a single line of flashing LEDs. you can find all design documents and software code at project home, You can find ... [More] more pictures & videos http://en.qi-hardware.com/wiki/Ledtoy, (here is youtube link for easy review) [Less]

Recently, we create a new software project named fpgatools, fpgatools is a toolchain to program field-programmable gate arrays (FPGAs). The only supported chip at this time is the xc6slx9, a 7 USD 45nm-generation fpga with 5720 6-input LUTs, block ... [More] ram and multiply-accumulate devices. *) maximize chip performance *) fast development cycles *) independent toolchain that only depends on other free software *) reconfigure on-chip *) include get-started tools such as jtag, debugging, parts data and designs for prototyping hardware *) design flow that includes asic manufacturing *) lightweight C implementation without GUI *) supported platform: Linux *) license: public domain The first support chip is xc6slx9, so we start with a minimal xc6slx9 qfp144 board. as you can see in those pictures. it is a very simple board without design a PCB. here you can find how to soldering this board step by step and where get those components. After soldering this board. the first step will be the hardware test. for make sure your board is working. after connect all those power/jtag pins. you can use a UrJtag to test the board. just a simple command ‘detect’ it should output something. Then we need make sure the osc and a real configure bits file can working on this board. so we wrote 2 simple configure bits files here. we also need a host program to load the configure bits file to board. you can find it here, named mini-jtag. by reading the Makefile you will understand how they works.(like just type ‘make’ is enought [Less]