Writing my own Free Plain Phone sw distro for GTA02

[Michael Sokolov]

Hello Openmoko community,

I have just ordered my GTA02 hardware unit from Golden Delicious a few
days ago, and I greatly look forward to receiving it in the next few
weeks (intercontinental shipping and all).  But the real purpose of this
introductory post of mine is to announce what I plan to do with it: my
desire is to write my own from-scratch Free Plain Phone software distro
for it.  (More specifically, take the existing & working U-Boot and the
Linux kernel with no or just minor changes, but bring up my own userland
from the ground up.)  Before anyone tells me that I'm crazy or why in
the world do I wish to do that, let me list my primary motivations:

Motivation 1, which can also be seen as a simplification of the task: I
am quite different from most free-your-phone hackers in that from the
functionality POV, I have absolutely no interest in a "smart" or
"feature" phone.  I have no interest in cameras, BT, Wifi, VoIP or
heavy-duty PDA functionality; I don't need my phone to display fancy
color graphics or play music in stereo.  Instead what I want is a phone
that I can carry in my pocket with good power management, i.e., use the
absolute minimum power required to stay registered with the cell network
and be ready to receive incoming calls and SMS while everything else is
powered off, I want this phone to ring when someone calls, I want it to
beep when someone sends me an SMS, and I want to be able to pull it out
of my pocket and wake it up to place an outgoing call or send SMS.

In order words, the phone functionality I am after is what people would
call a "dumb" phone, or I prefer to call it a Plain Phone to use a more
neutral / non-derogatory term.  Basically the kind of functionality GSM
phones had in the 1990s and early 2000s.  (And for me it isn't just the
level of functionality: I'd like to make the user experience as close as
possible to those ancient phones as well.)  With my Free Plain Phone SW
distro I would like to take the FreeRunner/GTA02 hardware unit and make
it function as a Plain Phone, recreating that rustic user experience and
level of functionality.  I'll keep the Wifi, BT, GPS and G sensor
modules always powered off at the PMIC and basically forget about their
existence, and instead focus on power management, talking to the GSM
modem block and doing the rustic Plain Phone UI.

Seen from this perspective, what most people see as major shortcomings
of the FreeRunner's HW capabilities are actually advantages for me.  For
example, I have absolutely no interest in using my phone as a web
browser or doing any other "data as in Internet" activities on my phone.
Don't get me wrong, I like the idea of being able to check my email,
look something up on the web or ssh into my server back at home from the
side of a road in the middle of nowhere.  And I do use a mobile device
for those functions - but I use a different mobile device, one with a
full-size screen and a full-size keyboard.  That mobile device is called
a laptop - not a phone.  What I'm getting at is that I see absolutely no
need for UMTS/3G/4G in a phone: UMTS better belongs in a laptop or a USB
stick plugged into one.  Thus to me a phone like GTA02 that supports
only plain GSM and no UMTS is a welcome simplification rather than a
drawback.

At this point one may well ask: "If your needs are so basic, why do you
want a Linux phone at all? Why not just get a 10 y old phone from Ebay
and be happy with it?"  Well, I do in fact use such an ancient phone
right now: I've used it to confirm that plain non-UMTS GSM1900 coverage
is still available with good signal strength in all of the local spots I
care about.  But here are the reasons why I want to build my own Free
Plain Phone functionality on a HW platform like GTA02 rather than use an
existing one from 10 y ago:

Philosophical motivation: I believe in freedom as a principle, much like
Richard Stallman.  Being a basic philosophical principle, freedom is
essentially orthogonal to technological preferences.  In my mind the
idea of freeing your phone should not be restricted to just "smart"
phones chock-full of fancy features; "dumb" or plain phones deserve to
be free too!

Learning motivation: that's the biggest one for me.  I am a knowledge
freak.  I want to know, know, know.  Like many people nowadays, I carry
my phone with me everywhere, the only exceptions being places like
showers.  It's an electronic device that sits within centimeters of me
all the time.  As such, the idea of this device being a closed/proprietary
black box over which I have no control is very bothersome to me.  But if
I write my own userland software stack for the GTA02, i.e., implement
100% my own UI, my own version of gsmd talking to the GSM modem, etc, I
can aim for the ultimate understanding of my phone.  I can use it exactly
the way I use my current Mot V66 (a classic/ancient Plain Phone, exact
same GSM bands as GTA02), but with an extra twist: every time I press a
button on the screen, every time I make or answer a call, every time I
send and receive an SMS I can say: aha, when the phone rings what
actually happens is that the GSM modem raises this IRQ, the PMIC enables
this and that power domain, the Linux kernel does such and such, my own
code in gsmd does such and such communication with the GSM serial port,
then this process is spawned, and it interacts with my own main UI
daemon in such and such way...

Gaining this level of understanding of the electronic device I virtually
never part with is what I'm really after.  For me that includes all
layers of both HW and SW.  The main feature of the GTA02 that solidified
my decision to use this HW platform for my Free Plain Phone is the
availability of schematics.  I would not be content with just a listing
of major components and links to GPL drivers: I want the schematics!
It is also awesome that the GTA02 schematics are freely downloadable
without having to buy the HW first.  I have downloaded the GTA02
schematics, printed them out and carefully pored over every page several
times over long before I gathered the cash to order the actual HW unit
from Golden Delicious.  I seek to understand every power domain, every
GPIO, every interface between modules in my Plain Phone.  Being able to
inspect the schematics of *any* electronic device before buying it
should be an essential consumer-bill-of-rights type of freedom: inspecting
the actual schematics is the only way for a truly smart user to know for
certain that what he is buying matches what he needs.  There are some
other phones out there that claim to come with schematics, but as far as
I could tell it's an only-after-you-buy type of deal.  Asking someone to
pony up the cash without letting them see exactly what is offered first
is NOT cool with me.

I realize that I will unfortunately have to treat the Calypso GSM block
as a black box.  If I had a spare million dollars laying around, I could
probably find an ex-Openmoko-Inc employee whom I could bribe for an
illegal copy of the 3 missing schematic sheets and of whatever mix of
partial source and linkable binary/object modules I'm guessing they must
have had for the Calypso firmware: still not stellar, but better than
what the community currently possesses, which is a block diagram on
schematic page 14 and a fully-built FW image.  But I don't have a spare
$1M laying around, so that is probably not an option. :-(

But even with the GSM modem being a black box sequestered behind a serial
port, I can still have the joy of understanding exactly how the rest of
the hardware in my phone works: the USB port, the battery charger, the
PMIC (or rather the non-GSM PMIC), the audio subsystem...  In this way
the GTA02 with only redacted schematics being available to the public is
still an improvement over my current Mot V66 for which I have no hardware
docs of any kind at all.

That brings us to the software part.  On the SW side I really do want to
bring up my own userland in a Linux From Scratch manner (on top of the
existing & working GTA02 Linux kernel), rather than start with one of
existing fancy distros.

My primary reason for that is my general strong dislike for "modern"
Linux distros and the "modern" software design approaches they espouse.
When it comes to desktop distros, I hate Ubuntu with a passion and
Debian isn't much better: my all-time preferred desktop Linux distro is
Slackware, and even that one started to get dehanced in my eyes
("modernized") in its later versions.  It is completely beyond me why in
the world would someone want to put an Ubuntu/Debian type of system on
an embedded device such as a phone, and the OpenEmbedded stuff isn't
much better in my eyes.

For an example of my personally-preferred way of building embedded Linux
systems, take a look at this one:

http://www.harhan.com/Hg/heclinux-am3517/

That Mercurial tree is a community-reuse version (customer's application-
specific bits removed, just keeping the generic stuff that would be
useful for reuse in other projects) of an AM3517 (OMAP ARM variant)
system I have built for a client in my day job.  The client in question
is a medical device company, and their machine (running my AM3517 Linux
System) is now working well enough to where they are in the process of
getting ready to submit it to the FDA for approval.  What I'm getting at
is that I'm pretty confident that if I build an embedded system "my way",
I can not just "do it", but do it right / do it well.

If Golden Delicious' GTA04 OMAP-based phone comes to reality, porting my
HEClinux-am3517 to it would probably be a slam dunk.  Of course the
GTA02 on which I plan to bring up my Free Plain Phone sw distro is
significantly more different, with a much older ARM version and all, but
the general approach I have used in HEClinux-am3517 for building an
embedded GNU/Linux userland (radically different from OE/Angstrom or
Debian etc) can work for any processor, hence I plan on using the same
approach in my GTA02 project.

As a more concrete example, I don't want my UI to use either GTK or Qt,
and in fact I don't want any pre-existing UI code period: I want to
design and implement my own UI 100% myself.  My UI design will be rather
monolithic, centering around Plain Phone functionality: making and
receiving plain old voice calls on the GSM network, receiving, replying
to and composing SMS, managing contacts, and that's about it.  (*No*
"apps" or the like.)  I will implement my Plain Phone UI in plain C
using just libX11, no GTK or Qt, because that's my programming comfort
zone.

I also don't like dbus: too modern for my taste.  Hence I will need to
implement my own version of gsmd that doesn't depend on dbus or any
other infrastructural backbone of a "modern" Linux distro.

Put another way, the way I envision the GNU/Linux userland of my Free
Plain Phone distro is that the only userland components not written by
me will be very generic embedded Linux stuff like BusyBox, an embedded
X11 server for the LCD+touch interface and an embedded sshd: the stuff
that isn't specific to phone functionality.  But for those userland
components which actually implement the device's intended functionality
as a phone (gsmd, main daemon for the rustic Plain Phone UI I want, call
audio control, ringtone generation etc), I really want all of those to
be written 100% by me.  Because the level of functionality I'm aiming
for is a very basic Plain Phone, I estimate the magnitude of the task to
be doable for me.

Why?  As I've already said, one of my primary goals in this whole project
is to gain an intimate understanding of my phone, understanding every
detail of it.  That most definitely includes the userland software in
the critical path of call/SMS handling and other Plain Phone
functionality.  Using one of the existing fancy distros for the
FreeRunner and treating that software as a black box would defeat the
point of the exercise: it would be no different in practical terms from
using a regular closed source phone.  Thus if I were to use existing
userland software for the Plain Phone functionality rather than write my
own, I would have to study it in great depth and become an expert on its
internals, rather than merely use it as a black box.  And because of my
strong distaste for the "modern" software design practices, it is
generally easier for me to write my own program from scratch than to
understand an existing one to the level I would be comfortable with.

Making it happen: I am serious about this project.  Although I will have
to multiplex my work on this project with my other projects and with
other obligations such as day job, family etc, I plan on starting it as
soon as I receive the GTA02 hardware unit I've ordered from Golden
Delicious earlier this week: I don't have much interest in running
already-existing SW on it.  I envision that my project will proceed
roughly in this order:

1. Learn the process for loading new code images into the phone, build a
   very basic rootfs image (using the techniques and principles from my
   HEClinux-am3517 project) that does nothing other than allow an ssh
   root login over the USB port, load it, get it to boot (debug board
   with serial console bring-out for the win!) and get the USB login
   to work.  Try doing it with the battery removed (USB power only) if
   possible.

2. Write the first inklings of the battery charger daemon: minimal power
   management code to enable battery charging and control the USB
   current draw limiter.  Charge the battery and see it boot w/o USB
   power.

3. Write the first minimal gsmd.  Have it save incoming SMS in an
   "airlog" file with no UI.  Try placing an outbound call or sending
   an SMS from the command line (from the shell accessed via USB port
   login session).

4. Write the bottom layer of my own UI, roughly taking the place of the
   X11 window manager.  Have the userland display *something* on the LCD.

5. Keep adding to each of the 3 major pieces started above (gsmd, UI,
   power management) until the functionality reaches the level I am
   after.

I will probably do this project in a Mercurial repository, free to the
world of course.

This concludes my long introductory post.  Now I just have to wait for
my GTA02 hardware unit to arrive, and then see what I can do with it.

Back to your regularly scheduled programming.

MS