Freerunner ships; new framework; interesting uses; Openmoko interns

So much going on in the past couple of weeks:

1. Freerunner is now shipping, although I doubt that anyone reading this blog doesn’t know this already. Buy yours at www.openmoko.com, join a group purchase to save on shipping and get a better price, or check out our growing list of worldwide distributors.

2. The Python-based FSO Stack, also known as the Openmoko Framework initiative, is available for very early viewing. Called FSO because it’s an implementation of the freesmartphone.org APIs, the goal of FSO is to make programming the phone as easy as programming a web page.

3. Joseph Reeves of Oxford Archeology pointed me at a great blog detailing the use of gvSIG Mobile on Jalimo on a Freerunner. Joseph is a regular contributor to Openmoko, and Oxford Archeology is soon to become an Openmoko distributor.

4. Mickey Lauer writes (excellently, as usual) about the three different major software stacks for the Neo family and how to decide which one is best suited for different applications. For anyone interested in experimenting with these stacks, note that both ASU and FSO are pre-alpha.

5. Clarification on external antennas:

1. The socket on the exterior of both the Neo 1973 and the Neo Freerunner is for an external GPS antenna.

2. The connector for an external GSM/GPRS antenna is under the rear cover, accessible when the battery cover is removed.

3. More details here.

6. A brief story about the Freerunner and Openmoko in general appeared on ABC TV here in San Francisco and also went to Associated Press. To see the video, just click 2 of 2 below the picture. Note that it takes a while to get to the video, but eventually it comes up.

7. Openmoko for robotics! There have been a (small) number of mentions about this, and I’d like to showcase these. Peter’s project a “… solar powered autonomous boat project … using a Openmoko as the on board computer. Peter’s post includes links to a number of video clips.

8. We have summer interns at Openmoko. Read their introductions here, here, and here.

Michael

Neo USB Host mode: Hub and Power Issues

As we know, the Neo USB port can be both a device and a host port. The earlier device, the Neo 1973, could not provide power in host mode. The mass production version, the Neo Freerunner, can provide a limited amount of power in host mode. For devices requiring more current than the Neo can deliver, it is necessary to inject this power somehow.

There is a lot more that needs to be documented on this topic, and I’d like to prototype and test everything first, but for now a good example is Brad Midgley’s modifications to a powered USB hub to charge his Neo 1973 as well as powering any attached USB devices. Note that this will need to be modified for the Neo Freerunner.

Brad has also ordered a battery powered USB hub; expect a review when he receives and tests this.

Future topics will include how to charge the Neo Freerunner when in host mode, if in fact this can be done.

Freerunner Reviews

Kevin Dean, who has been reviewing daily builds for the Neo 1973, has recently received a Neo Freerunner, and now will be reviewing the software for this Neo. His first review includes photographs.

Kevin writes:

I received my Openmoko Freerunner sample this morning via DHL, and like I did with the Neo1973, I took lots of pictures and blogged about it.

Some of the pictures aren’t the greatest (poor lighting in my bedroom and a photographer I am not!) but they get the idea across. The write up also gives a few tidbits of opinion on some of the changes that seem to get overlooked.

Anyway, the writeup can be read at:

http://monochromementality.com/index.php/blog/show/Day-One-Openmoko-Freerunner.html

Openmoko u-blox GPS chip protocol usage

What we call the “u-blox chip” is actually the ATR0635 ANTARIS 4 GPS chip manufactured by u-blox .

Joseph Reeves of Oxford Archeology asked if we had any code to illustrate the binary protocol used to communicate with this device. Thanks to Andy, Roh, and Daniel, we have the following starting points:

• http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox
• svn co http://svn.openmoko.org/developers/alphaone/u-blox
• u-blox code in the DM2 manufacturing test program

One Freerunner Per Archeologist

I’d like to bring to your attention an interesting project built around the Freerunner.

Joseph Reeves at Oxford Archeology is developing a unit to be used by archaeologists while in the field. Joseph writes:

——————————

One of the main attractions of the FreeRunner was that it would fit our needs with only a minimal amount of work. I’ve written on my blog on many occasions about what we want to with the FreeRunner; the most recent entry probably spells it out better than any of the others:

http://blogs.thehumanjourney.net/finds/entry/1

We will need software developed to allow us to record the data we need to record in the field, but we are confident that this can be achieved in house. We are lucky that the data we need to record is largely fixed; all we need is a suitable interface and the ability to save the data to both a location on the phone and (when in mobile overage) a database in our datacentre. We have identified SqlSync as a potentially useful piece of software in this regard and will be conducting testing soon.

The majority of our efforts have been in developing the package that we can provide to other parties, both fellow archaeological contractors and a wider business market. We identified two areas that we felt should be addressed immediately; the provision of a physical keyboard and a power supply option suitable for people working in remote locations for extended periods of time. We believe we have found solutions for both:

We have been in discussions with G24 Innovations, a UK company making solar panels designed for the developing world. They make an amazingly cheap cloth backed panel that we shall be testing next week: http://www.g24i.com/pages,products,40.html

We have sourced keyboards from another UK company, Hela. These are rollup rubber keyboards that have been specially produced for us with a mini-USB connector. Again, we shall hopefully be testing them next week: http://www.hela.co.uk/Duraflexcomfort/index.htm

G24 Innovations are also open to the idea of producing a panel for us with a built in Y splitter cable so that the FreeRunner, solar panel and keyboard can be used at once as a single device.

We have been in talks with Alternative Networks about distributing this package with service contracts to a wide range of business users as a powerful smartphone. Once we have assembled what we think would be a typical package we shall send a complete sample to Alternative Networks and move into further discussions. Their website can be found here: http://www.alternativenetworks.com/

Future updates about our status would therefore likely be centred around the progress we’re making creating an archaeological/business tool from the FreeRunner and the efforts we’re making in distributing this tool to other businesses and organisations that request it. Technical developments we produce are unlikely to be of great interest to the wider mobile hacking community (I was very pleased, for example, when I cross compiled my first app for the FreeRunner, but I doubt too many others would be too impressed) although will be crucial for our plans.

One element we are very keen to develop are the GPS capabilities of the FreeRunner to allow an Assisted GPS mode, but do not have the required knowledge in house to produce results.

Processing on Openmoko

“Processing is an open source programming language and environment for people who want to program images, animation, and interactions. It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool. Processing is developed by artists and designers as an alternative to proprietary software tools in the same domain. (www.processing.org)

Hanno Wendt and Sebastian Mancke of Tarent ported Jalimo to Openmoko, and then ported Processing to this environment. John Lee has been continuing this work and has the following to report:

Hi,

A brief status report about the current status of ‘Processing’ on neo.

* What is Processing?

Check http://www.processing.org/ . It’s a popular language among designers. It’s simplified java with its own java libraries. User app will be translated back to java before execution.

* Why?

We want to make neo designer friendly.

* Target

To make it run nicely on neo. Originally it runs (with a lot of errors) but it’s extremely slow.

* What have I done:

• tracing it. It brought me to different places such as java awt, classpath, cairo, xrender and x. quite time-consuming.
• doing experiments:

1. helloworld in java: 3 secs
2. helloworld in processing: 10 secs
3. paint 200×200 with dots: 2:05
4. paint 200×200 with floating point calculation: 2:25
5. paint 200×200 with hacked SDL backend: * 10 secs. *
   ( just a proof of concept. ignore most features. not usable. )

• profiling:

1. gprof failed because of dlopen.
2. jvm -Xprof failed because CACAO doesn’t support it on arm.
3. oprofile gives usable results.

• trying to improve it
• profiling indicated that the bottleneck was cairo. An upgrade to 1.6.4 makes quite flat distribution so there’s no obvious enemy now.

* What will I do:

The initialization of the jvm + java libraries is quite time-consuming. I’ll try to launch a processing ‘daemon’ in the background and load processing apps as external jar files.

* Call for help:

This issue is quite complex because it involves the performance of jvm, classpath, cairo and xserver. Also the hardware limitations such as 1) no FPU and 2) narrow bandwidth on gta02 make the situation even worse. Any help, suggestion, pointing direction will be most appreciated.

* Special thanks to:

jserv and olv for discussion and suggestion.

Regards,
John

Charging your Neo Freerunner

USB Charging from a wide range of input voltages

Joseph Reeves of Oxford Archeology is exploring ways of charging the Freerunner in the field. He has located a portable USB charging solar panel, but observes that the output voltage from the solar panel is sometimes outside of the voltage range the Freerunner will accept.

The Neo Freerunner can accept only voltages between:
Vmin = 4.0 VDC and Vmax = 5.3 VDC

A couple of handy DC-to-DC converters can accept a very wide range of input voltages and output a regulated 5VDC:

AnyVolt Micro
Vout: Adjustable 2.6V to 14V
Vin: 2.6V to 14V
Iout: 0.5A max input or output current at < 10V

Part number 5S5.1200LV from calex
Vout = 5 V
Vin = 3.5-16 V
Iout = 1.2 A

Joseph blogs about his Openmoko applications here

Openmoko “April Software Update” (ASU) and Qtopia

Openmoko has been working on some major changes to the software, and you can now take a peak at a very early alpha release.

In the words of Steve; “… this is to give people a sense of the direction, a glimpse of the future and not meant ( at this stage) for specific feedback or bug reports.”

Some highlights of this update:

• Switches the Window Manager from Matchbox to Enlightenment (E17)
• Ported Qtopia to Xorg, so it is possible to run Qtopia, GTK, ELF, and Python applications all at the same time
• Replaced the GTK-based basic phone suite (dialer, contacts, SMS) with ones based on Qtopia

It is important to note that GTK based applications are still fully supported.

An excellent first impression written by Ian Darwin can be found here.

If you have access to Freerunner and want to try it out, you can find the kernel, rootfs, u-boot, and dfu-util here.

Zecke has done some (much? most?) of this work and answers some questions:

Q: What do you mean when you say you worked on “Qtopia packaging”?
A: We are forced to compile Qtopia in one go, but after make install we split that up into a lot of packages. I reordered some files in the packages and created some new ones (e.g. where we want to have app installed but no .desktop file).

Q: You mentoin a resume issue. What issue is that?
A: We have at least two separate issues here.

1. Kernel config (defconfig-gta02) as used by OE will create a kernel that does not resume at all. defconfig-2.6.24 has more debug output which will “solve” this resume issue, so we expect this is some kind of timing issue on resume.
2. The infamous no resume after a while of sleep.

Q: What do you mean by “Fix the ugly icons, I know they are a visual offense.”?
A: The Qtopia icons are SVG but with “convert” of imagemagick it honored the viewbox of the svg and we scaled that image up, in contrast to rendering the svg in the right size.

Why did we decide to replace our basic phone suite? Quoting Kevin Dean:

The work done to port Qtopia to Xorg created a LOT of opportunity for the “Open” part of the Openmoko mission statement to be true. Third party developers have just as much ability to hack as they do with the 2007.1 stack (arguably more so) now that the base includes Qtopia but allows for other languages and toolkits. I think this will be made even easier with the service-based approach that will expose functionality cleanly across those toolkits/languages.

… I recognize the need to get something “finished” in a reasonable time and I infer Sean et al felt the need to go this way.

Sometimes people forget that Openmoko Inc. can’t make hackable phones unless they SELL hackable phones. Hardware isn’t free. Staffing, advertising, fabrication, procurement, shipping, design (et cetera) costs money. I think everyone here can truly respect that, if not like it. I’m happy that Openmoko was able to make a decision that will generate revenue more quickly without compromising the objectives in the first place.

Free Software projects have one major strength – the ability to share. I don’t see collaboration and adaptation to be a bad thing at all. I’m actually kind of glad that Qtopia will be an included part of Openmoko. Including it doesn’t diminish the ability for someone to write the application they would have liked to see as “Openmoko” but it does give people who aren’t writing applications some more functional applications.

> The QTopia apps do have a somewhat more conventional “cell phone” feel to them (see my screenshot of the Contacts “Overview” page here: http://www.darwinsys.com/tmp/contacts1.png).

This is good for a mass market product, I think. Having a hackable phone aimed at end users is a good way to go. For the users who never want to tweak, let it be familiar. For users who are fine hacking, give them the power to do so. With the expansions of Qtopia by the Openmoko development team, I think that balance it being struck.

> in hindsight, building the whole thing from scratch is a daunting task, and something that QTopia has been honing for several years.

FAQ: Frequently Asked Questions

Q: What will be the price of the Neo FreeRunner?
A: $399 USD.

Q: What components are included?
A: We have not yet decided.

Q: What are the volume discount details?
A: We will sell a “10Pack”, which is a package of 10 phones, for which we will charge $369 USD per phone. Note this is not for any quantity above 10, but rather only for multiples of 10.

Q: Will there be a separate “developer” or “reprogrammable” version?
A: No. All Openmoko products will be upgradeable and reprogrammable by anyone, at any time.

Q: Will I need a “debug board” in order to develop applications or to reprogram or update my Neo?
A: No. Anyone can download applications to their Neo, upgrade, or reprogram the Neo Freerunner with a standard USB cable.

Q: Can I damage my Neo Freerunner by accidentally corrupting the boot loader?
A: No. Every Neo Freerunner includes a fail-safe boot loader that can not be written to or erased using only a USB cable.

Q: Why would I ever need the “debug board”?
A: Only if you need the ability to single-step the hardware, such as when you are debugging the kernel or a driver, or if you accidentally corrupt or otherwise need to reprogram the fail-safe boot loader.

Q: How do I get the “debug board”?
A: It is a separate product, and can be purchased by anyone for $99 US.

Q: How can I ssh from my Linux computer into my Neo?
A: See USB Networking

Q: What sort of warranty does the Freerunner come with?
A: Phones with hardware flaws will be repaired or replaced (at our discretion) if the flaw is reported with 14 days for individual phones, and 28 day sfor phones shipped in “10 packs”.

Q: Where can I get the dfu-util binary?
A: http://downloads.openmoko.org/snapshots/2007.11/images/neo1973/

Q: Can the debug board that shipped with GTA01 be used with GTA02?
A: Yes, with the following restrictions:

• it won’t let you write to the NOR FLASH
• I2C and SPI aren’t available on the debug board

The main functions, JTAG and serial console, will be just fine, and you can always write to NAND FLASH.

Q: What are the best images to use on GTA01? Where can I find them?
A: Kevin Dean’s excellent reviews of the daily builds, along with his recommendations, are here. The images that Kevin recommends are always available here.

Q: What is stored in NAND FLASH and NOR FLASH on GTA02? What’s the difference?
A: Both contain U-Boot. The difference is that NAND FLASH can be updated by the boot loader, while NOR FLASH can ONLY be updated with the (GTA02) debug board. In case of an accidental corruption of NAND FLASH, the U-Boot in NOR FLASH can be used to boot and restore NAND FLASH.

(With the GTA02 debug board, your system is also “unbrickable”, even if you mess up the NOR FLASH. In this case, instead of a quick DFU download, recovery then needs the devirginator, or something equivalent.)

Q: How do I preserve my PIM information (contacts, calendar, etc.) when re-flashing to a later snapshot?
A: Copy the appropriate directories elsewhere BEFORE re-flashing the phone. Copy the files from the phone to a different computer using scp, or copy them to a micro-SD card (at /media/card/) using cp.

Then re-flash the phone, and copy the files back.

Note: Since this is early-access software, we do not recommend that you store valuable information on your Neo with no other backup.

Q: Where is PIM information stored?
A: If you’re using a pre-ASU snapshot, all such files are stored in ~/.evolution and are in “Evolution Database Format”; you could in theory copy this information to your desktop and access it via Evolution or EDS (or vice versa).

If you’re using ASU, this information is stored in ~/Applications/Qtopia/qtopia_db.sqlite. Note that Qtopia Desktop is too old and will not work with Qtopia version 4. Currently Qtopia will only sync to Outlook (we think). Openmoko would welcome a project to  write plugins for other applications.

USB Networking: Routing and Forwarding

When you connect your Neo 1973 to your Linux computer via a USB cable, most modern Linux distributions automatically configure the Ethernet-over-USB interface.

What doesn’t always get set properly is the routing to and from the Neo, and proper masquerading of traffic from the Neo to the Internet.

I think my setup is pretty representative:

• My Linux computer is running Ubuntu 7.10
• My local network is the 192.168.0.0/24 subnet
• My local network is provided by a router/firewall/DHCP server
• I’ll use the default Neo address of 192.168.0.202

For simplicity, we’ll use the default IP address of the Neo. Although the default configuration of many routers/firewalls/DHCP servers use the 192.168.0.0 subnet, almost all DHCP servers start at the low addresses (192.168.0.n where n is a small number) so the use of the address 192.168.0.202 is rarely a problem.

Simple routing to/from Neo

On your Linux host:

sudo ifconfig usb0 192.168.0.200 netmask 255.255.255.0
sudo route add 192.168.0.202 usb0

This should allow you to get a shell on the Neo via SSH:

ssh root@192.168.0.202

IP Masquerade and NAT

Your Linux computer must be told to accept network traffic to and from the Neo.

On your Linux host:

iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

Test from the Neo:

ping www.yahoo.com