Planet OpenEZX

Michael Lauer: FSO meets EZX

mickey — 2008-07-02T12:08:16+00:00

Coming soon…

Michael Lauer: GTK, ASU, FSO? TMTLA!

mickey — 2008-06-28T06:15:33+00:00

With the new Openmoko Framework initiative (as posted in previous installments of this column) facing its first milestone release (nothing but solid phone calls, so don’t be disappointed. If you have no Openmoko device, check out the video in the same directory), we are now facing three different major software stacks for the Neo family (there are special-purpose variants, but I won’t go into details here).
As there is quite a chance that developers might be confused about that, I want to use this chance to sketch the big picture and answer some of the questions around the future of these stacks.

Products

Openmoko is selling hardware products. Openmoko funds work on software stacks, so that the actual hardware can be more than just a developer board, but rather approaching a useful mobile compagnion. As with all kinds of products, Openmoko products have a — more or less specific — target audience. However, as we learned during all these months since we sketched the first product in the nice summer of 2006, even this specific target audience is not completely homogenous. The existance of the three software stacks is both due to the fact that we all are still learning how to write software for mobile devices, but also because there are quite substantial differences in what people expect from and want to do with their Openmoko devices.

Stacks

So — what are these three stacks, where are the actual differences and who should run which stack? In a nutshell, it boils down to the following:

The Openmoko 2007.2 Stack, utilizing GTK+ and assorted applications. 2007.2, since it was the 2nd iteration of the GTK+ user interface that we released in 2007.
The ASU Stack, the combination of a classical smartphone stack based on Trolltech’s Qtopia ported to X11 and enhanced with an EFL-based launcher and new applications. You may have seen the term Illume which is the launcher of ASU.
The FSO Stack, also known as the Openmoko Framework initiative. This one is called FSO, because it’s an implementation of the freesmartphone.org APIs. You may also have seen the term Zhone which describes the framework testing user interface and is a minor part of this stack.

Openmoko 2007.2 is for people who are familiar with the GNOME Mobile initiative and who want to write applications that run on multiple devices running (parts of) GNOME Mobile. This includes Maemo, which runs on the Nokia Internet Tablets. The strength of the GTK+ stack is a UI and programming environment similar to what you run on your Linux desktop, if you’re into GNOME. The GTK+ has PIM applications based on the Evolution Data Server and runs the gsmd phone server. Although you can use them, the applications are still pretty rough und unfinished. Some people have problems with the stability of the phone server.

ASU has been started to integrate the Qtopia stack — ported to X11 — with a new set of graphically pleasing applications based on the Enlightenment Foundation Libraries. Qtopia is a more mature product than the GNOME Mobile stack and you can expect all the standard feature phone applications to work in a solid way. It uses the Qtopia phone server. Since — contrary to standard Qtopia — it does not directly use the framebuffer, non-Qt applications can safely share the screen with Qt applications, that is until you are writing applications that do not communicate with the framework. If you want to integrate, then you’re back to C++ and Qt.

FSO has been started to overcome the deficiencies both of the 2007.2 and the ASU stack, namely to come up with an extensible framework that gives developers the infrastructure they need to create solid and exciting software products based on the Openmoko platform. An infrastructure that supports competing UIs while we can collaborate on developing services, making the framework strong . Here, the focus is on stable highlevel services that you can access from whatever language or UI that supports dbus. People report that despite its infancy, e.g. the phone server part in FSO is already more solid than anywhere else.

Future

Right now, Openmoko’s priority is getting the ASU to a point where it is stable and satisfies the every-day use with the FreeRunner product. In parallel, Openmoko recognizes the framework initiative as critical for further iterations of their software stacks. The goal is to be able to take one application from one stack and replace it with an application from another stack. Once all applications are framework-aware, this goal can be reached — which also implies userdata compatibility between software stacks, of course!

In practice, this means once the framework has reached a certain extent (see http://trac.freesmartphone.org for our tasks, issues, and milestones), we can expect it to be seen in all kinds of products, likely including further releases of the ASU. Until then, the FSO image is already your best bet if you want to write something that is tailored for your special usecase. If you want, you could also help us shaping our framework-testing-toy Zhone into something that fulfills the daily needs

Of course, Openmoko would also love to see Openmoko 2007.2 getting more love, but they don’t have the resources to do it. If you are interested in working on it, here’s a strategy I’d recommend:

Remove neod, gsmd, and phonekit.
Integrate the framework phone subsystem and make the dialer talk fso.org OTAPI (substituting gsmd and phonekit).
Integrate the framework device subsystem and make the launcher use it (substituting neod).
Debug and polish the PIM applications.
(optional and only when it’s ready) Integrate the framework PIM subsystem and make the PIM applications talk framework.

I hope that answered most of your questions. If not, feel free to add more via commenting this article.

Michael Lauer: Momentum

mickey — 2008-06-15T23:11:16+00:00

Momentum is something really strange! It’s hardly predictable and you have to run to catch it before it goes away — but when it’s there, things are progressing like there’s no tomorrow

There’s a whole lot of momentum present in some of the projects I care about:

OpenEmbedded

OpenEmbedded will abandon monotone and move to git as its primary SCM. This will increase the wide-spread adoption of OE and attract new people. We will have more (shortlived) branches and merges will be easier. We will also revamp the commit policies a bit to introduce more stability to both the stable and the unstable branches.
Setting up the non-profit organization (german registered association e.V.) is progressing and we will soon have our legal entity.
Some couraged people are revamping our website into something that’s more accurate, structured, (and pretty). Good for both OE-novices and experts.

OpenEZX

OpenEZX developers started to push for mainline inclusion. This will greatly increase the visibility of our project.
OpenEZX developers are working on a 2nd stage bootloader that overwrites the MOTO kernel, but leaves the rest of the flash file system untouched — by this we can boot both an OpenEZX kernel from SD as well as the original system (with its kernel on SD), which makes testing a relief.
We found security holes in the MOTOMAGX kernel, which may enable us to put our own code on these systems.
Motorola has released new devices, apparantly running EZX. More devices for the platform!
Openmoko’s Framework and Zhone phone UI is going to provide a slick looking — working — featurephone userland for OpenEZX — the first releases are just a couple of days away. It’s now important we get kernel work finished, so we can release something that is a real alternative to the closed source MOTO system on EZX devices.

Openmoko

Openmoko successfully went into mass production of the Neo FreeRunner (GTA02) device. Finally, people will have the 2nd generation of the first truly open source hardware platform in their hands.
The Qtopia/Enlightenment based next generation software update is progressing nicely. I expect a release in the next couple of weeks.
The new dbus-centric Openmoko framework initiative as well as the Zhone bread-and-butter application will see a release within the next 48 hours.

Exciting times for Linux on mobile platforms, n’est-ce pas?

Stefan Schmidt: TechWeek in Vachdorf

Stefan Schmidt — 2008-06-12T15:28:43+00:00

Over the last week, directly after LinuxTag, I was in Vachdorf. If you like to know more about this small village take a look at OSM. Of course we mapped the whole village while being there.

The reason for being there was the TechWeek from Pengutronix, a company from my area doing a lot linux embedded projects for the industry. I already known some of the people working there privately. While being there I got known to the other ones. I must admit that it is a nice bunch of smart people loving what they are doing. What I actually appreciate a lot is their work to get their patches into mainline, even if it costs a lot of time and money. This is a not-so-common practice in the industry linux embedded world.

While hanging out there and having good talks about git, patch handling and submission workflows I spend most of my time working on geting some of the EZX patches mainline ready. We now have a svn branch that contains patches sitting directly on top of the arm git tree pxa branch. While working on this I also started to submit three one-line fixes upstream to get used to the arm-linux workflow. 2 Are already in the git tree, one is acked and waiting in incoming.

I enjoyed the week. Smart people, good food and hacking on stuff you like. Life could be that easy...

Michael Lauer: State Machines — Resistance is Futile

mickey — 2008-06-08T22:55:22+00:00

So I’m rewriting the call handling in the Open Phone Daemon for the second time now. Cowardly, twice I tried to get away without implementing a full state machine, but it always came back to me.

Telecommunication stuff is all about state machines, and honestly… they are your friend, not your enemy.

Yet another reason to see that my third semester in university with all the finite state machines was not superflous

Michael Lauer: Froscon Submission Deadline in 10 days

mickey — 2008-05-22T22:54:47+00:00

I just realized it’s only 10 days until the Froscon call for papers has its deadline. You should better get started submitting a paper — I will do the same. Looking forward to seeing you at one of germany’s nicest OSS conferences!

Stefan Schmidt: Talk and Radio Interview at the LinuxTag 2008

Stefan Schmidt — 2008-05-22T22:37:09+00:00

Next tuesday I'll be on my way to Berlin for the LinuxTag. It will be some busy days between giving a talk, an interview for Radio Tux and hanging out at the booth of my ex-employer.

Still I'm looking forward to it. This time I hopefully have some time to attend the technically talks. I look at you kernel track. And let Harald de-mystify the security of the micro waves around us.

Stefan Schmidt: SCM changes

Stefan Schmidt — 2008-05-09T14:24:40+00:00

Over the last days I did some changes to the SCMs for my private projects. Some got migrated from svn to git. Also some git repos changed the location. Please refer to the overview websites if you run into trouble:

http://svn.datenfreihafen.org/$PROJECT_NAME

http://git.datenfreihafen.org/

Stefan Schmidt: Recent OpenEZX progress

Stefan Schmidt — 2008-05-08T23:27:11+00:00

Since I left OpenMoko I have found some time to work on OpenEZX again. There are two nice things that happened since then.

The first one was that I got an 18bpp patch for all the second generation devices working. At least pxafb and fbcon are working fine now. I still need to test X more. :) The patch was from the gumstix patchset. Thank you guys.

The second was the boot_usb 0.2.0 release. We use this little tool a lot and SVN is stable most of the time. Especially after Daniel Ribeiro added support for initrd, commandline and setting the machine ID a release was needed.

Stefan Schmidt: OpenMoko Framework Initiative goes live

Stefan Schmidt — 2008-05-08T22:40:32+00:00

Mickey already blogged about it. This is something we talked about a lot lately. Sometimes frustrated sometimes with hope. It is something we never got right since the beginning.

Ease the development of new applications and services. Build your kick ass stuff on top of a good fundament. And if it does not give you what you need, extend it. It's not like other commercial frameworks where you have to deal with what you get. It's open, take it, extend it, send patches. :)

Let's hope the framework team get the resources they need for getting it done. I also have some private ideas how to contribute here. Once I have something ready I let you know.

As code is better then words, take a look at their git repos.

Michael Lauer: Openmoko Framework Initiative

mickey — 2008-05-05T16:02:47+00:00

I have not been posting about my work for Openmoko for quite a while. There are multiple reasons for that, ask me privately if you want to know… Today though, I want to post about a high-priority project inside Openmoko, Inc. — the new framework and middleware initiative which me and some guys will be working on.

I have been talking privatly about this to people on conferences, but now it’s going to be an official project. It’s something we attempted to do when we started back in 2006, but for some reason, we did it the wrong way. We tried taking existing components to make them fulfill our usecases and to fit our needs, which in some cases turned out to be impossible. This time we’re moving the other way round. We will take our usecases as the goal and create the necessary infrastructure to make it happen. If — while we’re on the way — can integrate existing efforts, even better. If not, we will eventually see how to merge with existing efforts. The goal is to get things done — now!.

Basically all this is about two components, which are independent, but closely related.

The framework.
A bread-and-butter application.

The Framework

The purpose here is:

Give people the infrastructure to create solid and exciting software products based on the Openmoko platform,
Support competing UIs while collaborating on developing services, and
Encourage framework users (e.g. application developers) to also contribute to the framework.

With this in mind, we define the following requirements:

Make it simple,
Concentrate on core services,
Be programming language agnostic,
Be UI toolkit agnostic, and
Try to reuse existing technologies as much as possible, but not at the cost of a bad API.

Our way to achieve this on a technical level is through dbus:

Chose dbus as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.
Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).
Optimize for Openmoko devices, but support multiple architectures (OpenEZX, Xanadu, …) and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.

The framework is not going to cover everything but the kitchen sink though, especially it’s not about:

Bootloader, Kernel, or System Init.
X-Window-System, Window Manager, UI Toolkits,
Application Launchers, Applications, or Fancy UIs.

The Bread-and-Butter application

The framework initiative is related to developing an application that uses the framework to turn a Linux-phone into a usable feature phone. The main goals for this application are:

Make it simple,
Concentrate on core features,
Have a beautiful, efficient and consistent UI,
Be easily extensible through scripting, and
Show the power of the framework.

This application is developed in tandem with the framework, because when you write framework APIs, it’s important to have existing API consumers. Without API consumers, APIs are just specs, could be awkyard, or plainly unusable — that’s why this bread-and-butter application is of central importance to the framework project.

I’m looking forward to spend a lot of time on this project and I invite all of you to participate. Most of the discussions will happen on the Openmoko developers mailing list and the FreeSmartPhone standards list We already have achieved some important basics thanks to great contributions by the moko underground people that are grouped around the neo1973-germany.de site and the IRC channel #neo1973-germany. I’m also looking forward to great results from this years’ Openmoko Google Summer of Code.
As for the current status, we will update the wiki page OpenmokoFramework frequently and sent status updates once and then to the mailing lists.

Good speed!

Michael Lauer: Conferences Ahead

mickey — 2008-01-22T01:56:44+00:00

So I have promised to travel much less this year, however some trips are inevitable. For the first two quarters in this year I’m looking forward to participate at least at the following conferences:

February: Fosdem’08 (Brussels) — standing at the OpenEmbedded booth.
March: OpenExpo’08 (Bern) — giving a talk and standing at the OpenMoko booth.
March: Bossa’08 (Recife) — EFL/OE code camp.
May: LinuxTag’08 (Berlin) — applied for a talk, but visit anyways.
August: Froscon’08 (St.Augustin) — will apply for a talk and visit anyways.

If you have a chance, then drop by and lets have a chat. Don’t be shy — people say, I’m a nice guy

Michael Lauer: Tempus Fugit

mickey — 2007-12-31T18:39:38+00:00

2007 was a very busy year for me. There has been great progress in the projects I care about, e.g. OpenEmbedded, OpenMoko, OpenEZX, Enlightenment, Maemo, Ångström, and some more. In 2007 I travelled more than in all the previous years in sum — lets see whether I recall where I have been:

Berlin (CCC, to meet colleagues),
Bermingham (once for GUADEC),
Bonn (for FROSCON),
Brunswick (twice, to meet colleagues),
Brussels (for FOSDEM),
Denmark (for Mobile Developer Days),
Siegen (to meet colleagues),
Taipei (to work at OpenMoko Inc.),
Zürich (for OpenExpo),
and some more which I forgot about

A couple of weeks have been spent by my wife and me moving into a new apartment, my office room drowned and dried, I received dozens of parcels, and I saw (too) many new PCBs.

I saw a 3-man project growing into a company (with some unfortunate collateral losses on the way) and did a tiny little share to bring the Asimo robot forward. I met many interesting people on various conferences and in Taipei, and made some good new friends. Oh, and last but not least I (finally) got my doctoral degree.

It was a good year, albeit a bit too hectic for my taste. For next year, I’m trying to focus on less things, but more intense. Bringing forward my dreams of ubiquitous computing, high level application frameworks, and fluid user interfaces…

I wish all of you who read this a blessed 2008 — may health and success be with you. See you next year!

Stefan Schmidt: Which wifi chip drives the Spectec SDW-82{1,2,3} SDIO cards?

Stefan Schmidt — 2007-12-10T16:28:12+00:00

Dear Lazyweb,

I'm interested in SDIO wifi cards that could be supported within a 2.6 linux kernel. Using them to add wifi connectivity to my EZX devices would be nice. EZX devices are based on PXA270 with full SD or microSD slots.

It would now be interesting to know if the Spectec SDIO cards are based on the Atheros 6000 SDIO chip. OpenMoko is working on a GPL driver for this chip. That would hopefully reduce the amount of work to get it running on other devices.

So anybody knows more about the chip Spectec use?

regards

Stefan Schmidt

Michael Lauer: Framebuffer vs. X11

mickey — 2007-12-08T19:46:14+00:00

Putting some new fuel to the neverending fire — whether the (undebatable) performance drawback of using a full-blown window system like X11 outweighs the benefits in flexibility; Just recently I built the Expedite benchmark utility (from the Enlightenment project) for my Neo1973 (266MHz armv4, VGA display, unaccellerated framebuffer).

Thanks to the Evas canvas abstraction, Expedite has tons of rendering backends, including ones for the framebuffer and X11. And here are the results of the jury:

I this is is quite shocking (I expected the framebuffer to win, but not by that far). With an average frame-per-seconds of 17 for the framebuffer backend and 11 for the X11 backend, this looks like X11 introduces an overhead of about 50% on my platform.I wonder how the directfb and SDL backends would score — I’m going to do these eventually. I’m also curious in the results of Gtk+/X11 vs. Gtk+/fb as well as Qt/X11 vs. Qt/Embedded. I’ll do that once I have nice benchmark utilities for the respective toolkits.

Surely this result only applies to unaccellerated framebuffers, hardware-accellerated xrender may win by far, but this is what we don’t have right now. The question is, did we bet on the wrong horse here? Do we really need all the goodies X11 give us? Do we really need a windowing system abstraction on a phone? Do we really need to run multiple toolkits in parallel? What do you think?

Michael Lauer: Usability through Bling

mickey — 2007-12-05T13:17:14+00:00

Let me point you to two publications I found interesting:

Interaction Designer Peter Sikking shows the necessity of a holistic approach in order to create stellar UIs.
Gustavo Sverzut Barbieri compares UI toolkits for “fancy embeded interfaces”.

Stefan Schmidt: Navilock BT-451 under linux and navit

Stefan Schmidt — 2007-11-15T20:58:34+00:00

Bluetooth GPS reciever just rock. Small, easy to use, no cables and useable with different devices. Once my day-by-day gadgets and notebook have all one build-in I can get it of it, but that will take some time.

So the toy is called BT-451 and has a u-blox ANTARIS4 SuperSense chip build-in. Getting it to work is easy:

hcitool scan
rfcomm connect hci0

After this you have a serial port (perhaps /dev/bluetooth/rfcomm/0) where all the NMEA data comes in. Just give this one to gpsd and you can use it in multiple applications. I also heard that this is even easier with gypsy. No more need to deal with rfcomm yourself. That screams for a test once it is in debian.

There is some more stuff I like about the BT-451. Once it had a fix I was able to put it in a pocket of my jacket, sit in my car and it still gets the position. Tested with driving home with my notebook on the seat next to be and tracking the drive with navit. Daniel also discovered that the USB plug is not only for charging, but also shows up as ACM modem and spies out the NMEA on /dev/ttyACM0. And once connected via USB it also works without a battery.

The above mentioned navit is one of the most promising stuff I like to use regulary with the GPS. It's a navigation system with a routing engine. Not only download maps and show them, but do real routing with vector based maps. As we all know maps are problematic. OpenStreetMap is working on this problem. Until this is useable everywhere I like to have some commercial maps I can route with on my linux system. Don't expect some vendor has got this ready. :(

But FOSS has, as almost, an answer for me. Navit support different vector maps for commercial CDs. Just buy such one, copy the files and navit handles the rest. Great.

No I just need to test the navit setup on my Neos. :)

Stefan Schmidt: Catching up with OpenEZX again

Stefan Schmidt — 2007-09-03T12:15:44+00:00

It's a long time since I really spent some hours on doing OpenEZX only work. A lot great stuff happened since then:

Alex Zhang worked out some of the differences on the sweet A1200 device. He offered patches to get at least usbnet working with the EOC chip and better support for the 18bpp framebuffer and touchscreen.
Daniel Ribeiro finally got the ezx-asoc driver working and was able to do a voice call. The first with our 2.6 based kernel.
Antonio Ospite made some nice progress in getting the GPS information on the gps-enabled A780's from mux14 and worked out the used protocol. This mean we are close before having full NMEA output from it and feed it into gpsd which makes the whole informations available to other applications.

Motivated from all this great work Mickey and me spent more or less a full day with OpenEZX work. Catching up with the newest stuff and getting OpenEmbedded integration into an even better shape as it already was. (Thanks for koen on taking care of this most of the time).

Besides this there was some ongoing work to make OpenMoko more useful on devices with QVGA screens. Based on the work Philipp Zabel we started an QVGA theme. Some artwork still needs a bit rework but it looks already pretty good. Mickey made some pictures and will link them from his on blog entry I guess.

Once wyrm has merged the outstanding patches into the svn and we have done more work on the QVGA theme we will go for an snapshot release for with kernel and rootfs.

Stefan Schmidt: Mobile Developer Days 2007 are over

Stefan Schmidt — 2007-09-03T11:53:16+00:00

Currently I'm with Mickey in a train back to Germany from Denmark. The last days I participated the Mobile Developer Days 2007. In contrast to the most other conferences I attend this one was not only about FOSS but more about developing software for mobile devices. Write applications in Python, Java, Open C, examples for location enabled applications, VoIP and rapid prototyping for artist are just a small extract of the program.

Mickey and me gave our talks about Open{Moko,EZX} and presented the community view in discussions.

Besides the different focus the event was also a lot smaller then the ones I usually attend. Around 40 people. So most of the attendees were speaker as well. Mixed up with the fact that many of the people are doing research in this area gave the conference a academic touch.

In the last weeks Mickey and me pondered if we really should attend as our travel and working schedules are pretty full, we did not got plane tickets and had to go two 10 hours train rides, etc.

In the end I'm happy we decided to go. Besides the talks especially the small group of people was a good place for interesting and informative discussions. Coming from the FOSS world and doing not much business besides OpenMoko it was quite interesting for me what people with a more commercial background are doing with mobile devices and what benefits and drawbacks they see in using FOSS for example.

During the days and nights we had some working session with normal OpenMoko stuff but also some hours on catching up with OpenEZX stuff. But that's another blogpost.

Stefan Schmidt: Conferences ahead. Going to RMLL and GUADEC.

Stefan Schmidt — 2007-07-07T17:02:08+00:00

After having a busy time with university, OpenMoko and getting my partime freelance going I now are getting more relaxed and looking forward to the next two weeks which I will spend mostly on two conferences.

Next week starts with my flight to France. I'm giving a talk about free software on mobile phones. It covers mostly OpenEZX and OpenMoko, but also tries to give an overview about other projects in this area. As my talk is at the first day I'm looking forward for the other talks, visit Amiens and doing having some time for OpenMoko related work.

Coming back from France means having a half day and a night at home and jumping over to England again. GUADEC will be full of meeting people, having fun and making plans for the upcoming month. I'll fly together with Daniel and his girlfriend and meet up Mickey in Birmingham. But besides OpenMoko related discussions I really looking forward to meet people behind Gnome.

Harald Welte: My reason for being away from OpenEZX

2006-12-04T01:00:00+00:00

This post should have been posted months ago, but only since very recently I'm allowed to talk about the real reason. You might have read about it, if you read my full blog, but I'm posting this again in the 'a780' category to make it appear on planet.openezx.org

I've been hired to be key element in the design and implementation of the OpenMoko platform and the first device it supports: The Neo1973 phone. While there is no provision in the contract preventing me from working on the OpenEZX project at all, this assignment has just sucked up all available time like a vacuum cleaner.

To OpenEZX developers, users and supporters: Please be assured that most of the work done on OpenMoko will eventually benefit OpenEZX quite a lot. So please stay tuned, and concentrate on the low-leve device-specific issues that need to be resolved with the Motorola EZX hardware :)

Harald Welte: A1200 LSM / SELinux update

2006-09-15T02:00:00+00:00

James Morris got quite interested when I told him that the A1200 uses SELinux to lock out the users (owners!) from their own phone ;) So we both did some further analysis, and it turned out that Motorola had actually released the source code to their own policy engine (MotoAC) with the A1200 kernel sources on opensource.motorola.com, whcih is good.

Still we didn't understand why you would use an unmaintained, at least three years old version of SELinux to base a forked policy engine on it - but obviously this is the world of Free Software and everybody is allowed to make his own decisions.

I've also catched up with the A1200 in general and found out that people have already managed to flash their own kernel into it, whcih is great. I wish I had more time to put into OpenEZX at this point, turning it into something that is actually useful. HINT: Skilled volunteers needed.

Pavel Machek apparently got one and is annoyed by the restrictive SELinux policies. By now I'm quite sure that it's not all too difficult to get rid of them ;)

Harald Welte: ROKR E2 Linux Phone review

2006-09-01T02:00:00+00:00

There has been an extensive review of the Linux based Motorola ROKR E2 phone at osnews.com.

Harald Welte: Wanted: Author and/or sources for EZX "qonsole" application

2006-08-29T02:00:00+00:00

The original author of the KDE "Konsole" program, Lars Doelle, is actively looking for the Author and/or the source code of the "qonsole" program, a terminal program for the Motorola EZX platform that is apparently derived from GPL licensed Konsole.

Since the legal status of qonsole never was clear, I always refused to host it on any of the OpenEZX project resources. I didn't really know of any GPL violation going on, but had a somewhat strange feeling.

If any of you has information on where the qonsole program originates, please make sure to inform either Lars or me about it. We know by now that it appears to originate from some chinese or singapore mobile phone forums.

It's good to see more software authors of GPL licensed programs actually caring about enforcement of their license :) I sincerely hope this can be resolved and qonsole either distributed in gpl-compliant way, or a re-implementation be found/made.

Harald Welte: Motorola ROKR E2

2006-07-10T02:00:00+00:00

I've found the ROKR E2, which is yet another Motorola Linux GSM/GPRS phone exclusively sold in china so far. Apparently since June 22nd, so it's a quite new thing. It's very different from the A7xx/E680x series in that it doesn't have a touch screen, but many more buttons. Also, it features a full-size SD card slot, which makes it theoretically SDIO compatible (I'm pretty sure they use some SDIO compatible SD host controller in there).

Let's see whether I can work with the Chinese language firmware. I already found out how to get it into boot-loader flash mode (by pressing the camera button on the upper right side while powering the device up). It looks completely different than the blob on the A780/E680, but that doesn't really mean anything.

As of now, I don't have any technical proof that the device runs Linux. I'll probably not find time to play with this toy before I get back to Germany. But if anyone has hints or further information on how to dig deeper into the ROKR E2, don't hesitate to send me an email about your findings.

Harald Welte: Motorola A728 and A732

2006-07-08T02:00:00+00:00

Just next to my hotel, there is a book store that also sells mobile phones. Among the Motorola models are the A728 and A732, both Linux based. They're about 160EUR each. I don't yet know whether that is a good price, but now after checking with some online shops I think it is.

So I guess I'll get one of each in order to investigate whether we can hack them from an OpenEZX point of view. Also, this finally allows me to obtain proof whether they're still shipping GPL incompliant or not.

I'll continue to look for an A768 and E895. Let's see whether I'll find some time to do some more serious 'shop browsing'.

Harald Welte: Some small A780 progress

2006-06-23T02:00:00+00:00

I've continued my work on porting the ts07.10 from Motorola's mux_cli to 2.6.x. It now compiles, although I have no idea whether it actually works as expected.

Since Linux 2.5/2.6 has undergone quite some sophisticated changes in both scheduling/context area (no more struct task_queue) as well as the tty layer (dynamically allocated and managed flip buffers, etc), the task has been a bit more challenging than the usual copy+paste+minor_fixup task.

I'll also be releasing the -ezx6 kernel soon (2.6.17 based) in the next couple of days, where I plan to merge mickey's various driver bits (LED, backlight, keypad fixes) and the above-mentioned mux_cli.

Harald Welte: Interview on OpenEZX at LWN.net

2006-06-12T02:00:00+00:00

For those interested, lwn.net is featuring the first part of an interview withe me on the status of the OpenEZX project. The way longer pert of the interview on gpl-violations.org will be posted within the next two weeks.

Now let's hope that I'll be able to fix that nasty netfilter bug that I'm hunting for weeks now and get back to OpenEZX kernel hacking...

Harald Welte: Not working on OpenEZX at the moment

2006-06-07T02:00:00+00:00

Due to lots of other "real life" and "real work" constraints, I'm not able to work on OpenEZX for at least another week :(

Harald Welte: Porting Motorola's TS07.10 MUX driver to 2.6.x

2006-05-27T02:00:00+00:00

Since Motorola has finally released the source code for the mux_cli.o and gprsv.o modules of their 2.4.17 kernel on opensource.motorola.com, I've started to clean them up and port them to 2.6.x.

Due to the questionable coding style of that original source code, and the many interface changes in the TTY layer between 2.4.x and 2.6.x, this turns out to be a bigger task than expected. With some luck, I'll find some time tomorrow at ph-neutral to finish the initial port.

Once that code works on 2.6.x, I already have a quite long list of TODO's. First of all, the lower-layer interface needs to be cleaned up. Ideally, the whole TS 07.10 implementation is a TTY line discipline that can be stacked on top of any UART, together with a virtual/fake UART that makes use of the Motorola specific TS07.10 USB transport.

Harald Welte: Touch-screen driver for A780/E680, lots of other progress

2006-05-19T02:00:00+00:00

As of today, the OpenEZX project has a working touch screen driver. I've been testing this with the Kdrive X11 server of OpenEmbedded, and it seems to work nicely on my A780 after calibrating with ts_calibrate.

This is such a major step forward, since the touch-screen driver requires a functional PCAP2 driver, which in turn comprises working SPI support, as well as some tricky SPI-during-hardirq for interrupt chaining.

If you're interested in giving it a try, there's the the -ezx6 quilt patchset including all this work.

Also, thanks to the work by Michael 'mickey' Lauer, I've managed to set up an OpenEmbedded environment to build a distribution for OpenEZX. You can find the first bunch of packages as well as a root filesystem that you can put on TransFlash on my OpenEZX developer pages.

The availability of a OE based root filesystem, a kernel with keypad, touch-screen, usbnet and framebuffer support actually means that all the [G]UI people can now start to work on making their favourite UI system work on OpenEZX. Given the amount of interest I've seen in this area, I'm confident that I still don't (yet) need to dive into UI development myself but can stay with the more technical low-level stuff.

Speaking of which, I've also hacked a nice tool called gpiotool, using which you can read/write GPIO configuration as well as individual GPIO pins from userspace. If I had written this earlier on, it would have saved a lot of time and hassle. But then, it's always hard pushing yourself to develop code that _just_ aids development and doesn't really add any functionality itself.

Using this tool I'm now investigating the AP/BP interaction (handshake). Let's hope that we can actually use the phone as a phone really soon.

Harald Welte: Motorola launching opensource.motorola.com

2006-05-15T02:00:00+00:00

Motorola seems to be making some progress internally. Today they've announced the availability of opensource.motorola.com, a web site dedicated to free and open source software used and developed in/by Motorola. This is apparently also the portal where they are starting to publicize the source code for their Linux based Smartphones.

While the source code there is not complete in any way [yet], it actually includes the kernel sources for the A1200 phone, too. After a quick read through it, it seems to be very similar to the A780 code (because of a very similar hardware architecture).

Some of the differences are:

FOTA (Flash on-the-air)
Power Management
Minor differences in boot loader / kernel handover
SE Linux

Harald Welte: A full day of EZX driver development

2006-05-14T02:00:00+00:00

Today wasn't exactly the most efficient day of development I ever had. Basically, the amount of progress made after 13 hours of hacking in the area of EZX device drivers is extremely slow. It didn't even help to not eat, not cook, and not get out of the bed for the whole day. Basically I started with "let's fix this quickly before breakfast", but it wasn't fixed even when I stopped working at 11pm.

My new SPI driver seems to be working fine, but I have massive problems with all the PCAP drivers. This is mainly touch-screen, but also ADC for reading battery voltage, etc. Somehow I cannot get it to produce any IRQ's.

Harald Welte: Debian sarge root filesystem image for EZX phones

2006-05-12T02:00:00+00:00

In order to get other developers going quickly, I have now provided a Debian sarge (arm) root filesystem and a corresponding kernel plus instructions.

Anyone who wants to see a stock Debian installation boot on his EZX phone, have a look at the files published here.

Harald Welte: OpenEZX virtual host running

2006-05-11T02:00:00+00:00

I've finally found the time to configure the OpenEZX virtual host. This means that I now have absolutely no problems to hand out developer accounts on openezx.org. I've also moved the EZX related subversion repository from gnumonks.org to this machine.

If you're working on free software for Motorola EZX smartphones, and are interested in getting some account where you can host your project(s) in svn / git, dump some code on http/ftp or just want a openezx.org email address, please let me know.

Harald Welte: Working on Bluetooth and GPRS/GSM support

2006-05-11T02:00:00+00:00

I've been working a bit on getting Bluetooth and GPRS/GSM support into my 2.6.x based kernel for the A780. Both are quite a bit challenging, even more than I initially thought so.

As for Bluetooth: In theory there is a bcm2035 chip, compatible to the Bluetooth HCI specification, attached to ttyS1 (BTUART) of the PXA270. However, there are some power management related additional signals hooked up to GPIO signals. I think I'm configuring them right, though. Also, there is some indication that the bcm2035 actually requires a bit of firmware loaded into it. Without a vendor data sheet and with only some stripped proprietary Motorola dload program this will require quite a bit more of investigation.

My initial 'demand' for Bluetooth would have been the possibility to use my Apple BT keyboard with the framebuffer console, providing a local console in case telnet dies for some reason.

On the GSM/GPRS front (yes, we actually want to use the phone as a phone sometimes), I've been wading through disassembled gprsv.o and mux_cli.o code. Both re-implementations are progressing slowly, but steadily.

The easier part seems to be mux_cli.o. I've now started to write some libusb based userspace code to test a ts07.10 implementation in userspace via the USB endpoints to the BP. Once the userspace code seems to be working, I can work on a kernel level implementation. The good thing about this is that there are actually quite a few GSM phones that support this multiplex on their serial port. So the resulting mux/demux driver will actually be useful for more people, not just Motorola Linux smartphone owners.

Harald Welte: A780/E680: SPI driver using hardware SPI controllers working

2006-04-29T02:00:00+00:00

So apparently there is no obvious reason for Motorola's driver using bit-banging rather than the controllers inside the PXA270. I now have a modified Motorola driver on 2.6.16.5 running that uses the SPI controller for the bus to PCAP2. Getting my own driver running should therefore be quite fast now.

I've also hacked a bit on the keyboard side, although it's not working yet.

Harald Welte: Working on new SPI/SSP drivers for OpenEZX kernel

2006-04-27T02:00:00+00:00

One of the fundamental interfaces on the Motorola EZX phones is SPI, which interconnects (among others) the PCAP2 peripheral with the PXA270. Motorola ships their 2.4.20 kernel with some ugly piece of spaghetti code driver for it. Apparently they've had difficulties driving the PXA27x SPI controller, and in the end decided to just 'bit-bang' the signals over GPIO. Obviously that's inefficient and CPU-intensive. I hope there is no real hardware problem preventing the use of the embedded SPI controllers.

First I started writing a driver against arch/arm/mach-pxa/ssp.c, only to discover later that this code actually predates (and therefore doesn't use) the generic drivers/spi/ interface. Since I'm a fan of generic interfaces, I chose to write a PXA generic driver for the drivers/spi interface, plus some EZX specific glue code for it.

One of the interesting bits is that the PCAP2 can interrupt the PXA, and it then acts as an external interrupt controller, whose registers you can access over SPI. So a PCAP2 interrupt can mean that some touch-screen event happened, that the headphone, USB or microphone jack state has changed, etc. All those various real interrupt sources need to be fed to individual distinct drivers (audio, touch-screen, USB). The Motorola kernel uses an ugly kludge of callback functions that those drivers can register with the SSP/SPI driver.

So in my new driver, I choose to actually model that bit of PCAP2 functionality as an external interrupt controller. This way the actual sound/touch-screen driver can just do request_interrupt() like they usually do. However, this means that I need to access SPI from within hardirq context, which again doesn't mix well with the architecture of the drivers/spi code (which is asynchronous and queues requests). So I need to implement a couple of synchronous SPI functions in addition to that.

This is now a lot of code, and I'm about to test and debug it, which is expected to be time-consuming and boring. I'll post a status update as soon as there's more information.

Harald Welte: OpenEZX: USB Ethernet support working

2006-04-22T02:00:00+00:00

After lots of hacking at FISL 7.0 in Porto Alegre, I've managed to get the PXA27x USB device controller to work in USB Ethernet emulation to work. I can now actually ping and telnet to the 2.6.16.5-running E680, using a debootstrapped Debian/ARM on SD-Card.

I'll publish the patches in one or two days, when everything has stabilized a bit, and the debugging code has been removed.

Also, at the event here, I've managed to convince quite a number of Free Software people that those Linux smartphones are actually quite interesting toys. Most notably, Keith Packard of Xorg fame has indicated he would probably be getting one and working on a lightweight UI. This motivates me even more to have a stable and fully working kernel environment finished soon.

Harald Welte: State of OpenEZX 2.6.x kernel development

2006-04-17T02:00:00+00:00

During my two days of EZX phone hacking, I've made significant progress. Probably the most important discovery was how to get a serial console on the USB plug, enabling other people to do further kernel development without physically modifying the phone - but it's still a long way to go.

A current list of TODO's:

find out why kernel doesn't boot with CONFIG_IWMMXT
find out why E680 SD/MMC works, but not A780 TransFlash
debug and fix pxa27x_udc in order to provide usbnet (nfsroot!)
debug and fix mtd support in order to be able to access system flash
port and cleanup video and sound drivers
port Motorola-specific SSP/SPI drivers into 2.6.x generic SPI stack
port all the driver specific dpm bits from Motorola's 2.4.20 to 2.6.x
clean up the already working keypad drivers
finish re-implementation of mux_cli and grpsv modules
look into re-implementing the proprietary flash fs drivers, though I don't think that is particularly important, we could run our code 100% on SD/TransFlash
create a modified bootloader that allows for multi-boot configurations. It could actually include SD/TF support for booting kernels from there.
check how the other (later) Motorola Linux smartphones differ and merge their device-specific code into our 2.6.x kernel tree
last, but not least, we need to do something about userspace. I'm not a GUI guy at all, and I haven't yet thoroughly investigated all the existing projects like OPIE, etc. I'm sure once the hardware support is there, some more GUI-savvy people will do something in that area, though.

So why am I stating this here? Because it's up to _you_ to help and take care of one of these tasks if we want to see the dream of having a fully-free software E680/A780 before they get phased out ;)

Harald Welte: 2.6.16.5 boots on EZX phones

2006-04-17T02:00:00+00:00

I've finally managed to get a 2.6.x kernel running on the Motorola A780 and E680. Apparently the problems I encountered are part of 2.6.14 (which was current mainline when I started the port). After merging my patches into 2.6.16.5, everything suddenly worked fine ;)

So what I've got now:

kernel 2.6.16.5 booting on both A780 and E680
USB host controller towards Neptune BP working
USB device controller partially working
MTD support for all flash partitions
SD/MMC support on E680 (TransFlash on A780 not working yet)
Framebuffer working on both models, with nice 4x6 tiny font

The main obstacle now is that TransFlash on the A780 is not working yet. The A780 is actually more important than the E680. For some strange reason, all the response bytes from the TF card appear to be zero (at least that's what the response FIFO of the PXA27x embedded SD/MMC controller reports). I've already tried a lot, but am a bit clueless after many hours of trial and error :(

Harald Welte: Running a serial console on the A780

2006-04-16T02:00:00+00:00

After about half a day of trial and error (which was related to a totally different problem, as it turned out), I now have a 2.4.20-based kernel with working serial console for my A780. Unfortunately the console requires soldering four wires onto test pads of the PCB - something that I achieved with 0.1mm diameter magnet wire (Kupferlackdraht for you Germans). The magnet wires are thin enough to get them through the TransFlash slot to the outside, without having to modify the case.

If you're interested in a bootup log captured from the STUART, check this one.

The rest of the day was spent debugging why my (still 2.6.14 based) kernel doesn't want to boot on the machine. As it turns out, booting stops somewhere in the early initialization after head.S has called decompress_kernel(). Debugging this problem has also caused me to actually write some ARM assembly code. For years I'm reading and debugging ARM code, but I've never actually written ARM asm from scratch. So my assembly code now prints one character for every stage of the booting process (ABCDEFGHI) and then stops. At the time the C code should print its first character, the device is already gone. So maybe something with the setup of the registers according to C calling convention, or setup of stack/heap is erroneous.

Interestingly, that startup code has not really changed all that much from 2.4.20 (which runs) and my 2.6.14 based kernel.

It's not unlikely that I'm [again] hunting a totally different problem. I'll probably merge my patches into 2.6.17-rc1 and see whether that works...

Harald Welte: Obtaining Asian Motorola EZX phones in Europe

2006-04-11T02:00:00+00:00

A couple of days ago, I was looking for a way to obtain Motorola Linux Smartphones in Europe, i.e. those plenty of models that are not officially sold anywhere but China and other areas of Asia.

I've now found a suitable importer specialized in importing Asian phones into the European market. In case you're interested, feel free to contact me for more details. The phones range between EUR 180 and EUR 300, but there's a minimum order of five phones. I'll probably be ordering around early may.

Harald Welte: Looking for Motorola Linux phones

2006-04-08T02:00:00+00:00

Since right now I only have E680i and A780, I would be interested in a way to obtain E896, A1200, A910, A768, A760, A732, A728 as well as ROKR E2. Most of them seem to be mainly sold in China / Taiwan.

If anybody knows a good source (importer in Europe) or some other way how to get these phones in the western half of the world, let me know.

Direct import would also be possible, but I'd need to know a serious exporter in .cn/.tw in order to do so. Any suggestions welcome.

Harald Welte: planet.openezx.org launched

2006-04-08T02:00:00+00:00

In the tradition of my main project netfilter (which has a planet.netfilter.org, I've now also opened a planet site for the OpenEZX project at planet.openezx.org.

This should give users the ability to stay up to date with current developments in the Motorola Linux smartphone hacking community.

If you know of any feeds that I should add to this planet, please let me know

Harald Welte: Booting kernels on A780 / E680

2006-04-07T02:00:00+00:00

It's a bit strange that I still have so much difficulty running my own kernel on the phone. As it appears, there are some subtle hardware (or bootloader?) version differences that made me struggle for so long.

Two out of my three A780, and my one E680 don't boot any self-compiled kernels but rather just crash. The third A780 however boots them just fine.

Obviously, as Murphy's law indicates, the phone it works on is my 'production' phone, i.e. the one I use for my day-by-day phone needs.

We really have to get to the bottom of what's going on here. Also, if there really are differences, then Motorola has to publish the kernel source for both versions under the obligations of the GPL. So far they have only released a single version.

Harald Welte: Downloading and executing your own code in RAM of EZX phones

2006-03-27T02:00:00+00:00

In the last two days I've written a small program that allows you to utilize part of the built-in firmware update mechanism of the Motorola EZX phones. In fact, what it does is to download an arbitrary (max 1MB) piece of code from the PC to the phone via USB, and then execute that code on the phone.

On the one hand, this might look like a security hole (but well, nobody really cares about security on mobile phones anyway). On the other hand, this should definitely speed up kernel and driver development within the OpenEZX project, since it basically removes the need to flash the phone for testing of some new code.

Also, once a working driver for the TransFlash slot has been cooked up, it would actually be possible to usb-boot the phone into an OS that mounts its files from TransFlash. This doesn't touch a single bit of flash memory and is therefore ideal for development and probably even something similar to what 'live CD' distributions are to PC systems.

Harald Welte: There's hope for running our own kernel on the A780

2005-11-18T01:00:00+00:00

Ok, now I am in contact with one guy that managed to run a working kernel that he compiled himself from the source code that Motorola Hong Kong has published.

This finally confirms that the kernel (even though it was requested for E68) works on a A780 without further modifications. On the other hand, I'm a bit puzzled why it won't work here. To figure out where the problem is, I've asked him to pass me the exact source tar-ball that he was using, plus detailed information on his cross toolchain.

I've also started over again from a 'vanilla' Motorola kernel tree and will give it another try. If this works, I'll re-try with the serial console, and if that works, move on to the 2.6.x tree (which I'm planning to make public this weekend, btw).

Meanwhile, I have confirmed that the bootloader is actually based on blob, and thus also needs to be released under the GPL. This, in turn, should facilitate the development of a GPL licensed host-side replacement of PST for flashing the phones.

I'm a bit worried since I'm busy with many other things over the next couple of weeks. But even while travelling, I'll have the full toolchain, sources, and everything with me.

Harald Welte: linuxdevices reports on OpenEZX, quote from Motorola executive

2005-10-29T02:00:00+00:00

linuxdevices.com reports about OpenEZX. In that report, it quotes Motorola's chief architect of mobile devices: Motorola had no immediate plans to support native Linux applications on its phones, in part due to carrier concerns about network health, security, and interoperability..

This is just not true. In fact, the A780 as it ships in Germany comes with a native GPS navigation and routing application called "CoPilot". Also, since the whole GSM stack runs on a different CPU than the Linux OS, there are no security/interoperability/network health concerns that I could think of.

Also, I have received reports that Motorola actually distributes a Linux SDK to selected third party vendors. Parts of those SDK's (the header files for the EZX libraries) have actually leaked, which support the position that there is a SDK.

In many ways, the EZX phones are a combination of a traditional Neptune-based Motorola GSM phone, plus a Linux-based PDA. Therefore, if any native Linux apps on the PDA half could influence the 'network health' in a negative way, then any other Neptune based phone could, too.

Harald Welte: OpenEZX wiki was launched

2005-10-23T02:00:00+00:00

Thanks to my friends at maintech, The OpenEZX project now has a Wiki.

I've only added some very basic information, but I hope that developers and users especially from motorolafans will contribute soon.

One of the important things we need soon is a project logo, for both the website and the wiki. Volunteers welcome :)

Harald Welte: Massive Response to OpenEZX announcement

2005-10-21T02:00:00+00:00

When I launched the OpenEZX page two days ago, I didn't expect such a massive (press) response to it.

All I did was to write a small announcement to my weblog, and it was picked up by a lot of press, such as lwn.net and golem.de.

Looks like this blog is read by a lot of people, and there's nothing I can't post here that doesn't get immediately distributed to a lot of places. Amazing ;)

Also, I've even received multiple requests for EZX-based consulting. Apparently there are companies who're interested in a 'fully programmable GSM phone'.

On a side-note, even Bruce Perens has now bought an A780 since he thinks it's "fun to hack". David Miller is pondering to buy one after his holidays in Korea... Let's only hope that they will actually find some time to get work on the EZX phone done. It's vital to have some basic running code ASAP in order to get more people to hack on stuff like the user interface.

After two days of full-time EZX kernel hacking, I now have a compiling 2.6.14-rc4 based kernel that has already half of the EZX-specific drivers merged.

I didn't really test to flash that kernel to a phone yet, mostly because I currently don't have an original E680 firmware that I could flash into the device if anything goes wrong. Also, before trying ti flash the kernel, I'd preferably like to have JTAG running. I'll publish my kernel tree as soon as I have confirmed it actually boots on the device.

Unfortunately I also have real work to do, and today is a full-time gpl-violations.org day, the weekend will probably be spent with some more librfid hacking. Stay tuned for some more OpenEZX news next week.

Harald Welte: There are other (more advanced) Linux Phone projects

2005-10-21T02:00:00+00:00

Since I'm getting that much coverage, I want to redirect some of that in the direction of the already-existing (and way more advanced, as of now) Linux phone projects.

There are multiple mobile phone projects at handhelds.org, esp. for the iPAQ H6315 and the HTC BlueAngel.

I didn't know about any of these projects so far, but I'll certainly look at their codebase and see whether any of the high-level (user interface) code could be re-used. But let me finish the low-level driver/operating system part first :)

Harald Welte: OpenEZX.org project launched

2005-10-19T02:00:00+00:00

Today I've started a small preliminary homepage about my A780/E680 hacking efforts at openezx.org. This also means that the old a780-hackers@lists.gnumonks.org list was renamed to openezx-devel@lists.gnumonks.org.

Expect no big news for some time, since I'm mostly working on porting/merging all EZX specific stuff into a 2.6.14-rc4 kernel.. a quite big job that will certainly take some time.

Stay tuned.

Harald Welte: E680 has arrived

2005-10-18T02:00:00+00:00

I've managed to obtain a 2nd hand E680 phone, which is based on the same Motorola EZX platform as the A780. The E680 are only sold in Asia, so the device I now have is actually a Chinese model.

Next on the plan for A780/E680 hacking is playing with the JTAG port, and trying to flash a non-OEM non-branded non-chinese firmware into the E680.

Once JTAG is running, I will be trying to port the drivers to a 2.6.14-ish kernel and compile and install that more recent kernel.

Harald Welte: A780 batteries/charger dead?

2005-10-16T02:00:00+00:00

I'm unable to recharge any of my two A780 batteries, at least not via USB. Since I'm travelling, I cannot try with the real power-supply charger. Let's hope I can somehow resolve this, and it isn't really some damage to the phone's built-in charging controller :(

On the A780 hacking front, I've now successfully confirmed that there are indeed JTAG pads on the PCB, both for the PXA270 and for the ARM7TDMI, which is great news.

I also think there is still hope that the USB device port could actually be used as a host port. At least the PXA270 supports various options for OTG. Now the big question is only whether this is compatible with Motorola's overloading of the USB (called Enhanced Mini USB).

Harald Welte: More A780 hacking

2005-10-01T02:00:00+00:00

Today was a very exciting day of more A780 hacking. You know, from time to time it's quite good to do something else than stupid netfilter development or the like ;)

So what I've been able to do? Well, I analyzed most of the device drivers from userspace side. I now know the key-codes of every keypad or other button/wheel/dial on the device, I know the touch screen and framebuffer. I can control the three different backlights.

Then I've learned a bit more about the architecture of the phone. The Xscale processor (PXA270 Bulverde) actually uses USB to talk to the Neptune chip. Neptune is a DSP with a synthesized ARM7TDMI on-chip. The PXA270 runs in host mode, the Neptune in device mode.

Interestingly, the Motorola developers have debugging callbacks in the stock kernel. So by registering a simple kernel module with the USB rx/tx functions, I now have hexdumps of the USB traffic between those two chips (also called AP and BP).

Then I called the a780, and I immediately received some nice hexdumps in the kernel ring buffer. The first thing I could spot was "IP: "+4930xxxxxxxx",1\r\n". There it was, the incoming phone number :)

Some other nice guy at motorolafans.com has managed to replace the proprietary userspace Bluetooth code with the stock Linux BlueZ codebase. He's working on Bluetooth keyboard support... that would really be nice. Using a Bluetooth keyboard with the Qonsole terminal emulator (or even a framebuffer console) of your phone :)

I'm really confident that the AP<->BP protocol can be worked out fairly quickly. Once this is done, we can start developing our own "phone" programs, and get rid of all the bloated embeddedQT and Java crap that is running on the phone. It has 48MB of physical ram, and the database daemon has a resident size of 2.7MB, the address book 4.5MB, the "phone" program has 6.6MB. This is really ridiculous...

At the end of the road, I'm dreaming of something small and efficient, running uClibc, busybox, DirectFB, ...

The USB device port of the device is called "Extended Mini USB (EMU)", because it apparently can be switched in more than half a dozen of different modes (by assigning various pull-up/pull-down resistors). Apart from a USB device, it can for example run a UART on that port. However, since the USB host port is already used for Bulverde<->Neptune communication, I don't think it is possible to run the phone in USB host mode. This basically rules out attaching a stock 802.11 wifi USB adapter, which is very sad.

Harald Welte: More fun with the Motorola A780

2005-09-30T02:00:00+00:00

I've now successfully built a compatible toolchain for the Motorola A780, thanks to this good site with instructions.

Obviously, one of the first things to do was to build busybox with a config that enables all the missing tools. For some strange reason, the A780 does not ship with the usual uClibc/busybox combination, but with the straight GNU tools (glibc, fileutils, ...). Unfortunately important bits such as less, top, strace, etc. were missing.

I've also managed to build matching ext2,jbd,ext3,sunrpc,nfsd and af_packet kernel modules. The VFAT partition on the TransFlash card was shrunk, and an ext3 partition added. Some hooks into the startup scripts, and now the ext3 is mounted when the phone is switched on. Some PATH and LD_LIBRARY_PATH mangling in .profile, and I have a very workable environment on the phone.

Obviously the most important goal would be to port the EZX arm architecture support into a recent 2.6.x kernel, and then run a full-fledged 2.6.x kernel on the device. With embedded IPsec, packet filtering, etc. That goal is very far, due to stupid proprietary device drivers.

So for now, I'll be looking into the kernel/userspace API's and the userspace/userspace API's in order to develop native userspace applications that can actually use the phone (i.e. make voice/data calls, use the headset/speaker/microphone, ...

Harald Welte: Running netfilter/iptables on your cellphone

2005-09-30T02:00:00+00:00

Yes, you're reading this right. I've managed to build iptables.o, ipt_*.o, iptable_filter.o, iptable_nat.o, ip_conntrack.o and the like for my Motorola A780 cellphone.

As of now, there's not really all that much need for it... but when I start running dozens of applications on the device, I better make sure to have a decent packet filter to the GPRS/HSCSD world.

But even then, in theory it should now be possible to NAT between the GPRS device one one side, and the usb-lan on the other side. Maybe I should try to bring my whole home network online via the A780 :)

OTOTH this doesn't fix the various security issues on the horizon. The A780 apparently ships zlib-1.1.3. I don't even know how many security vulnerabilities were fixed since then...

Harald Welte: Obtaining a root-shell on the Motorola A780

2005-09-13T02:00:00+00:00

I've recently acquired a Motorola A780 quad-band GSM cellphone. It's basically an Intel PXA270 based system with 48MB flash, a 256MB TransFlash reader, Bluetooth, a GPS receiver and MotaVista CEE Linux 3.0 (2.4.20 based).

As usual, the vendor tries to "lock down" the OS from the user. Luckily, some nice people of motorolafans.com have already found their way into the phone. Using their "linloader", you can put shell scripts on the TransFlash card and execute them by clicking on them in the explorer. Using that you can put the phone into a mode where it runs as usbnet 'device' with telnetd and samba.

By now I've already learned quite a bit about the phone. Interestingly, they are running glibc (not uClibc). The same goes for the rest of the device. No busybox, but rather the standard gnu programs. So it's much less of the typical embedded Linux environment, and more like a "regular" GNU/Linux system.

glibc-2.3.2, embedded QT, and some "ezx" class library on top. Add some J2ME runtime environment, a handful of different filesystems (vfat, cramfs, romfs, TrueFFS, mfs), a SD/MMC reader driver, a GPRS module, some strange "USB Logger" (looks like syslog-over-usb) and a number of userspace programs and there you go.

Oh, and yes, obviously the phone was delivered with no GPL license text, no source code and no written offer thereof. But that's a different chapter.