FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

Hello ex-Openmoko community,

The purpose of this announcement is to let everyone interested know
that my effort to liberate the original, fully functional (non-OsmocomBB)
firmware for the Calypso GSM baseband (as found in Closedmoko GTA0[12]
smartphones and many simpler feature phones) has not been abandoned.

Lacking the source or even semi-source for the specific version of the
Calypso GSM firmware that was used by the Closedmoko company (FIC), I
am taking the alternate approach: starting from the already-liberated
version of the same Purplelabs GSM stack for a different Calypso phone
(TSM30, aka SPT2C platform), and seeking to back-port it to the
Leonardo (reference board for basic Calypso phone designs) and to the
GTA02 GSM modem.

Specifically, I have just made the first successful step on that long
journey: I have successfully recompiled the Calypso GSM firmware image
from HispaPhreak's source code release, and done so without resorting
to a Windows machine or VM - using Wine version 1.5.23 under Slackware
Linux version 13.37.  Of course it still targets TSM30 hardware, so
don't even think about flashing it into a GTA02, but it's just the
first step of an exciting journey ahead.  Previously I kept saying
that HispaPhreak's TSM30 release *seemed* to be the complete source
for the GSM stack running on the Calypso, but now we know that it
actually *is* complete - yay!

I am doing this work in a Mercurial source control repository, and of
course I share it freely with the world.  Until I get my new Solaris
ZFS-based server up, I have temporarily hosted the Hg repository here:

http://www.harhan.com/Hg/FreeTSM30/

The README file at the top of the Hg source tree summarizes what has
been done before me, what I have done, and what I plan to do next.
The ultimate goal of this project is to back-port the code to run on
the GTA02 Calypso, producing a new GSM firmware image that comes as
close as possible to the original Closedmoko one, but is fully built
from source, no binary blobs.

Of course I am lucky to have a GTA02 unit, which has become a rare
privilege now that the stock has apparently been exhausted.  To those
who don't have a GTA02, desire one, but can't get one because of the
discontinued production and stock exhaustion: don't despair yet!

After we are done liberating the Purplelabs Calypso firmware and
getting it to run on Leonardo/GTA0x platforms (not SPT2C/TSM30), we
can then address the hardware shortage problem by building a new
Calypso-based phone motherboard - essentially do what Golden Delicious
did, but instead of going to that UMTS modem, keep the Calypso.  My
FTP site already has the complete schematics for the Leonardo board
(TI's reference design for a Calypso phone), the PCB layout of the
Calypso block can be recovered by sending a dead GTA02 board to a PCB
reverse engineering shop (think "pirate manufacturers"), and I have
some ideas as to how/where we may be able to obtain some Calypso chips
and related components.  But this is a topic for much much later -
let's get the firmware liberated first, using our existing GTA02s.
Just don't despair if you aren't one of the lucky GTA02 owners.

Viva la Revolucion,

Michael Spacefalcon,
formerly Michael Sokolov

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

Harley Laue  wrote:

> While I think the project you're working on is great, you come off 
> sounding petty using terms like "Closedmoko." I /still/ don't think any 
> open hardware phone has come out without some kind of NDA attached to 
> some part (I could be wrong.)

My beef isn't so much with the NDA itself, but with their unwillingness
to break it all these many years after the company has gone defunct and
all engineers have been let go.

I have lost count of how many NDAs I have broken, but it is probably
somewhere around 20.

It would be *so* easy for one of those guys to leak the ware completely
anonymously without ever being identified...  Hence their refusal to
do so is what makes them criminals in my eyes, and they shall always
remain so until and unless a leak occurs, anonymous or otherwise.

Just to be clear, I shall continue with my FreeCalypso project based
on HispaPhreak's release whether or not we ever get a leak of the
Closedmoko bits.  After all, the latter were mostly object code as
we've all been told (let me guess guys, your TI bits have files like
l1c.lk, l1d.lk, gmm.lk etc, right?), whereas HispaPhreak's version is
100% full source.  It is unfortunate that the full source version
targets the wrong hw platform, and it will take some work to back-port
it to Leonardo/GTA0x, but the result (a full source fw version for the
GTA02) will certainly be worth it.  But if someone does leak the
"semi-source" for the "moko" version, it would probably help a lot
with guiding the back-porting effort, particularly when the time comes
to recreate the moko-specific logic of the AP and BP signaling each
other to wake up.

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

Patryk Benderz  wrote:

> There is leaked TSM30 source code for this GSM chipset firmware...

Yes, that's exactly what I'm using as my starting point.

> maybe there also is some documentation?

As far as hardware documentation goes, all of it is neatly gathered on
my FTP site: /pub/GSM/Calypso on ifctfvax.Harhan.ORG.  100% complete
as far as I can tell - haven't spotted any omissions yet.

But software documentation is a different story.  The TSM30 source
release is just bare code, no documentation whatsoever, excepting the
scattered comments in the *.[ch] files and build scripts themselves.

My common sense tells me that TI had most likely provided its customers
(handset manufacturers) with some hand-holding documentation on how to
work with their firmware - where to go to make product-specific UI,
hardware support, etc changes, how to flash the firmware, how to talk
to it - setting IMEI numbers, RF calibration, testing, etc.  If some
kindred soul would be willing to leak that documentation (e.g., put it
on a .onion and have some disposable tormail.org account post a link
to it), it would be immensely helpful to the FreeCalypso project.  But
I won't sit and wait for it with bated breath - I'll just bite the
bullet and painstakingly study the code to recover that knowledge.  It
will take longer, but the project will still proceed.

> Did you checked this?
> http://tpb.noflag.org.uk/torrent/6834542/TSM30_Source_Code
> http://www.monova.org/torrent/4899164/TSM30_Source_Code.html

I'm the guy who sent that ware to Cryptome.org, from where those
torrents were then made. :-)

joerg Reisenweber  wrote:

> You also know that 
> what Openmoko had access to (mostly the AT interpreter) plus much more is 
> available as leaked source in internet since ages.

And you know as well as I do that the widely-available version, the
one I am currently using as my starting point, is set up to target the
wrong hw platform and the wrong feature configuration.  Being able to
take a peek at a version that is already configured as necessary, even
if that version is mostly binary objects, would be a very helpful aid
for the FreeCalypso project seeking to recreate that configuration
starting from the "wrong" but full-source-available version.

But I will persevere nonetheless, with or without the bits which you
are hoarding.

> "We" also granted access 
> to what we had to many volunteers that didn't sound as lunatic and mad as you 
> did - your fault.

It isn't just me that you are hurting - it is the entire GTA02 user
community.

I am pretty confident that I can rip out the TMS320DA250 ties from the
FreeTSM30 code base, and make it run on a Calypso-only phone.  I will
also *attempt* to recreate the changes you have make for the "moko"
version (custom AT commands, wake-up signaling, whatever else is there
that I'm unaware of), that is, recreate them independently while being
denied a peek at your version.  If I succeed in that part, great.  But
if not, I will just screw the GTA0x and find a Calypso-only phone to
use, with no AP and hence no need for the wake-up logic, etc.

Either way, I will have a working cellphone in my pocket, running my
FreeCalypso firmware - which is my goal.  But your refusal to share
the moko-specific modifications you have made to the firmware will
make it less likely that my firmware will be a functional drop-in
replacement for the old one, which obviously has a direct bearing on
others' ability to benefit from my work.

So in the end it will be the community which you are screwing, not me.

> C) you threatened our engineers in private mail (one or 2 years ago),

Not just private email, but quite publicly too, on this very list.

> to a degree where anybody else would've sent the police

Why don't you go right ahead - I challenge all police forces of the
world to try to stop me.

> To me you sound like a silly consequential angry child.

This "silly consequential angry child" will produce a working,
fully-functional, full source, illegally-free GSM firmware for the
Calypso, and make it available to the entire worldwide community of
lawbreakers, anarchists and revolutionaries.  That *will* happen with
or without your help.

The *only* part that isn't certain is whether or not that firmware
will be usable on GTA02 phones as a drop-in replacement for the old
binary-only one.  If it isn't, the community will know whom to blame.

> Oh, anybody said "glamo"?

You mean this:

$ hostname
ifctfvax.Harhan.ORG
$ ls -l /pub/GSM/GTA02/Glamo
total 2808
-rw-r--r--  1 msokolov   248664 Oct 20  2011 Glamo_3362_CmdQ_Spec1.pdf
-rw-r--r--  1 msokolov  1919990 Oct 20  2011 Glamo_3362_Datasheet_V1.0-Full.pdf
-rw-r--r--  1 msokolov   147740 Oct 20  2011 Glamo_3365_2D_Engine_Spec_v1.0.pdf
-rw-r--r--  1 msokolov   390670 Oct 20  2011 Glamo_3365_3D_Engine_Spec_v1.0.pdf
-rw-r--r--  1 msokolov   102131 Oct 20  2011 
Glamo_3365_MPEG_Engine_Spec_v1.0.pdf

Available via anonymous FTP, as usual.

Viva la Revolucion,
SF

___

Re: FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> Aha, and do you know how those files made it there?. You obviously don't
> which is a shame.

"Shame"?  You call it "shame" that I protect the anonymity of
contributors who have chosen to be anonymous?

The person who contributed the files in question to my FTP server
chose to be anonymous - hence anonymous it stays.

Are you trying to tell us that it was you or someone you know?  If so,
here is my sincere heart-felt thank-you, and a welcome to my side, the
dark side.

Alex Samorukov  wrote:

> I dont understand where is 
> achievement and i would expect that anyone with basic compiler/linker 
> knowledge and some free time will be able to repeat this.

You've obviously missed the most important part: my work in now in a
public Hg repository, including my still-ongoing work to further
Unix-ify the build process, i.e., make it less Windows-ish - an obvious
prerequisite to any actual porting & pruning work.

Thanks to this work being done in an open, public source control
repository, others *won't have to* duplicate it.

The work continues; anyone interested is encouraged to check the Hg
repository periodically.  Expecting to do the next hg push in a few
days.  I'm also working with a comrade on setting up a new web home
for this FreeCalypso project, with its own wiki and mailing list, so
we can be our own bona fide community.

> It is also absolutely clear that distribution of this sources or 
> firmware will be illegal,

If you have chosen to live and accept citizenship in a country where
such things are illegal, I feel sorry for you.  If you like, I can
give you a free immigrant/refugee visa to come to my country that has
no such repressive laws.

But otherwise, please keep your draconian laws to yourselves, and
don't try to impose them on those of us who do NOT live or hold
citizenship in any country with copyright laws.

> so it will not be possible to integrate in 
> qtmoko or shr or any other open source product.

But phones with the firmware flashed into them can instead be made
available on the Silk Road, the same place where you would go to
freely buy alternative medicine products such as cocaine, heroin or
MDMA.

(No, I don't use any of the just-listed products myself, but I know
 many wonderful people who do.)

> It is also very clear that osmocom bb team did much more interesting job

When they get their entire stack running on the Calypso, have power
management that is no worse than the original fw, and implement 100%
of the original stack functionality, including fax calls, CSD
(circuit-switched data) and GPRS, then I'll look at it.

Until then, I shall continue working on the FreeTSM30/FreeCalypso code
base.

Patryk Benderz  wrote:

> right... now I remember - Michael Sokolov.

I am not using my old name any more, I go by Michael Spacefalcon now.

Yes, I know, my Ancient UNIX email address still has my old last name
as part of my login name - a login name is harder to change than a
gecos field; see http://xkcd.com/910/  I will always keep this email
address for backward compatibility, but I will also have a new one
based on my new name when I get my new mail server set up.

> I am glad you have changed your MUA

Nope, no changes there.

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

Alex Samorukov  wrote:

> > Which country is that?
> >
> dprk ? :)

Yes, I love it.

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: FreeTSM30/FreeCalypso project started

[Michael Spacefalcon]

Bob Ham  wrote:

> You moved from Canada to North Korea?

I have never lived in Canada.  I don't live in North Korea either.  In
fact, I don't "live" anywhere at all - being an active-duty
internationalist operative, I only *operate* in various countries,
working against their governments and laws, but don't actually "live"
in any of them.

I don't understand why the people here find this concept so difficult
to grasp - that's just how all military forces work.  Both of my
grandfathers were in Germany in the 1940s as part of the Red Army.
They were on German soil, but they weren't "living" there, and they
most certainly did not obey any of the German laws that were legally
in effect at that time - instead they obeyed the orders of their
Soviet Army commanders.  Ditto with me and the countries I operate in.

This will be my last post in this particular subthread; any further
mails involving the subject of countries won't elicit any response
from me.  Drop the subject and move on.

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

New GTA02s (was WIKI is in read-only mode?)

[Michael Spacefalcon]

Radek Polak  wrote:

> But one day your GTA02 will stop working - it might fall on the floor or 
> whatever. GTA04 is only replacement -

Although it may be the only available replacement at the present
moment, it shouldn't remain that way for long.  We, the FreeCalypso
community (see below), need to make an effort to produce a new
GTA02-like phone, Calypso-based.

The first naive thought would be to contract with some pirate
manufacturing company to make verbatim unauthorized clones of the
GTA02, by reverse-engineering the GTA02 PCB and copying it verbatim,
layer for layer, trace for trace, via for via.  But it probably
wouldn't be the wisest choice in technical terms, even if all of the
components were still readily available (which they aren't) - the
GTA02 board includes some really stupid design choices which I would
want to get rid of if we're going to the trouble of building new
boards - the Glamo being first and foremost.

Because the single most important feature I seek to retain from the
GTA02 is the Calypso, we will probably still need to send a dead GTA02
PCB to a pirate manufacturing / reverse eng shop to recover the PCB
layout withheld by Closedmoko-Inc.  (We already have the schematics
for the Calypso block, TI's Leonardo reference design, but the
corresponding PCB layout is currently missing.)  As for the rest of
the GTA02 board, i.e., the AP realm, I would want to simplify it quite
a bit - take the Glamo, Wifi and BT out, connect the audio directly to
the Iota (Calypso's analog part) so that nothing on the AP side needs
to remain powered during a long voice call, and if the original
Samsung AP is no longer available (which is probably the case),
replace it with whatever other AP we can find that does the minimal
functionality we need using the least amount of battery power.

The Calypso chips themselves can still be obtained on the grey market.
And once that supply runs out, we'll need to send a Spetsnaz unit into
whatever TI facility has the old IC fabrication masks, seize those,
and take them to some Chinese fab to restart the production of those
chips.

> that's why it's important to support 
> GTA04 - either by donation or buying the device.

Not being Calypso-based, the GTA04 is a massive downgrade from the
GTA02, and can't really be seen as a replacement except a very feeble
one.

Therefore, anyone who wishes his/her phone to be a *phone*, rather
than a PDA or whatever, who sees the GSM processor as the most
important part of the phone, rather than some unimportant "modem", and
for whom the concept of a Free Phone means running fully source-enabled
firmware on the actual phone (GSM baseband) processor, should NOT waste
his/her money on a GTA04 downgrade, and should instead donate to the
FreeCalypso project - the latter will need to raise funds to pay for
the professional pirate-manuf reverse engineering of the GTA02 PCB, to
buy Calypso chips on the grey market, and to build the actual new
Calypso phones.

The firmware will be the user's choice of FreeCalypso or OsmocomBB.  I
choose the former, but others can use whatever they like.

> Maybe i am wrong but openmoko as company is for years dead and nobody of the 
> old admins is willing to spend much time on maintaining the infrastructure. I 
> guess the number of spammers is now 1000x higher the number of contributors, 
> that's why it's readonly. And it's no wonder that GTA04 has separate wiki 
> because of these reasons.

Dr. HNS of Golden Delicious has been saying for quite a while now that
with Openmoko being effectively dead, the Openmoko community is in
need of a new successor/replacement, and that successor/replacement is
OpenPhoenux.

I agree with the first part, but not the second.  There is not one but
TWO camps seeking to continue the work of Openmoko in different
directions: one is OpenPhoenux, the other is FreeCalypso.

In order to become a bona fide new community, FreeCalypso needs its
own web presence, its own wiki and its own mailing list.  I already
have a set of physical servers in my own sovereign micronation, all
that remains to be done is the software setup - sysadmin stuff.  I
will post an announcement when the new FreeCalypso community home is
up.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Building a new totally free phone

[Michael Spacefalcon]

Bob Ham  wrote:

> Please allow me to address a question to the community as a whole: if
> you can produce a free phone then why aren't you?  Do it!  What are you
> *waiting* for?

Well, as you've asked the community as a whole, without restrictive
language to exclude any particular factions of the community (e.g.,
the illegal faction, which I'm heading), I'll take the liberty of
posting my answer.

I am in fact working on building a new phone - as in new physical hw.
However, the type of phone I'm seeking to build is quite different from
what Canonical tried to fund, and from what most of this community
seems to be interested in.  I personally will never be happy with a
smartphone *of any kind* as my everyday phone - instead the kind of
phone I want is the kind we all had in the 1990s - a plain or "dumb"
or feature phone.  And that is the type of phone I'm working on
building - a plain old-fashioned "candybar" phone without any smarts,
and no application processor to run Linux or any other smartphone OS -
only the traditional ARM7 baseband processor running traditional RTOS-
based GSM phone firmware.

But the plain/dumb/feature phone which I'm working on building will
have one key difference from the ones you can buy for $20 on ebay: it
will be 100% free as in freedom, in terms of both hardware and
firmware.  In the case of hardware it means publishing full,
*unredacted* schematics and PCB EDA files, and choosing only those
components for which full documentation is available.  As for the
firmware, yes, it will be an RTOS phone, no Linux or the like, no
application processor, but the full C source for that RTOS-based
firmware can still be published.  And because such a totally free
phone can never, ever, ever be produced legally, I am doing it as an
explicitly-illegal project, under the aegis of the international
community of outlaws, criminals and lawbreakers - i.e., my brothers
and sisters.

Of course a project of this magnitude won't happen overnight.  But I
handle it the same way I've handled all other projects which appear
totally insurmountable at first: I divide the problem into bite-sized
chunks, and work on the initial stages without worrying too much about
what difficulties may lie in the later stages - I'll deal with those
when the time comes.  The FreeCalypso phone project has the following
rough roadmap:

1. Build the FreeCalypso software/firmware first.  In May-June of this
   year I have found some new and exciting TI firmware source leaks
   (archived on my mini-Wikileaks at ftp.ifctf.org) which will
   hopefully make it unnecessary for me to sacrifice my life in a
   gunfire exchange with the German or Russian police after kidnapping
   a moko-hoarder: these new leaks appear to be much closer to TI's
   "mainline" than the famous PurpleLabs TSM30 source, and I'm quite
   confident that by using these new leaks I can recreate something
   very close to what Om-Inc and its former employees/contractors have
   wrongfully withheld from Humanity - but in full source form.  (The
   LoCosto leak in particular, which I'm backporting from LoCosto to
   Calypso, has the GSM stack in full source form, unlike what Om-Inc
   purportedly got, and it appears to be from the same time frame as
   Om's version - much newer than the TSM30 one.)

I am working on this sw/fw part right now, using the Pirelli DP-L10
feature phone and the GTA02 GSM modem as my two bring-up/test
platforms.  In fact, the Pirelli phone fits me almost perfectly in
terms of hardware features, and I have thought long and hard about
just settling on it as my hw platform.  But there are a few problems
with this existing platform which have ultimately swayed me to my
current plan of biting the bullet and building my own phone hw instead:

a) No schematics could be found for this phone.  (The OsmocomBB folks
   are also hacking on Compal/Motorola phones for which there are full
   schematics, but their hardware features are insufficient for me: I
   would really miss the tri-band support, the loudspeaker and the USB
   charging capability.)  Schematics can be reconstructed by PCB reverse
   engineering given enough determination, but it would be hard to
   justify the effort given the other two problems:

b) This particular phone has a bunch of extra chips beyond the
   essential Calypso chipset, and for most of these extra chips no
   docs can be found.  While they support functionality which I can
   easily live without (camera and WiFi), their presence would
   tremendously complicate any attempt to reconstruct the full
   schematics, and may throw up issues when the time comes to implement
   thorough power management: how do we ensure that these undocumented
   and unsupported chips are fully powered down?

c) The biggest show-stopper of all: the supply of these phones on the
   surplus market appears to have been exhausted.  I've managed to grab
   a few before they disappeared, so I've got enough for my sw/fw
   development and tes

Re: Building a new totally free phone

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> I invite you to visit me at my home

If you meant it seriously, you might as well give your address or GPS
coords (by unicast if you prefer) - but I highly doubt that you meant
it seriously.

> trying to force me to hand to you

Hand to me?  What me?  There is no "me" - I could be dead tomorrow and
absolutely *nothing* will change.  I have never, ever, ever asked any
of you "Open"moko bastards to give anything to "me".  Instead I have
merely voiced the demand that the materials be released freely to all
Humanity - with a capital 'H' - and yes, I have indeed contemplated
being the one to sacrifice my life in order for the remaining 7 billion
people on Earth to gain free unrestricted access to a working turnkey
GSM firmware package in the form of COFF objects with full symbolic
information - a format which any embedded software engineer worth his
or her salt should have no problem working with.

[FYI, there is a patch to GNU Binutils which enables objcopy and objdump
 to read TI's COFF.  The support isn't perfect, but it can easily be
 improved if need be - and I also invite you to grep for my name in the
 binutils ChangeLog files.]

> the MOST SECRIT SOURCES that everybody [...] had access to since ~2011.

The reference to "~2011" makes me suspect that you are talking about
the TSM30 version - it was indeed late 2011 when this code (first
released in 2004 apparently) became widely available once again - and
the latter happened because *I* had sent it to Cryptome on a CD-R.

And you know as well as I do (or would know at least, if you ever
actually *looked* at the modem code you're sitting on) that the TSM30
version is drastically different from what you got from TI as Om-Inc:
different RTOS (Nucleus vs. SOS), different code structure, different
flash file system, totally different hardware (ABB, RF and probably a
different Calypso variant), almost everything is different.  Heck, the
TSM30 code isn't even TI, it's Purple Labs, a company that bit the
dust.

OTOH, if you are talking about something *other* than the TSM30 code,
something that "everybody passing the idiot test" supposedly has
access to, why don't you try being transparent once for a change, and
actually post a URL?

> everybody passing the idiot test

Like anyone else, I have my own strengths and weaknesses.  What I'm
good at is designing and writing embedded software, and some hardware
too.  I've been doing it professionally since ~2000 (and as a hobby
long before that), and I make enough money doing it to support not
one, but two full households on my sole income - so I guess I probably
do it pretty well.  I do it on the hobby side of my life too, so you
can look at any of my projects and judge for yourselves.  Like this
one, for example:

http://ifctfvax.Harhan.ORG/OpenWAN/

I'm sending this email through the Internet connection served by that
SDSL modem designed and built by me: hardware, firmware and the logic
in the FPGA - not to mention all the reverse engineering that was
needed to get to this point.

But I have my weaknesses too.  I am NOT good with people, and I am NOT
good with finding information that is passed around in a "hush-hush"
manner.  I don't do *anything* "hush-hush": if I have or find something
that may potentially be of value to others, I announce it publicly and
openly, on the relevant mailing list.

I absolutely do not understand how someone can be like you.  I
absolutely do not understand how ANY human being (or so-called human
being) can be as cruel and callous as the three of you (JR, HW and PF).
It's one thing to be slow with releasing things on occasion.  I've been
slow with releasing my software many a time, mostly because of my
handicaps with modern technologies and my heavy use of seriously
ancient gear - as well as my fear and distrust of any servers or online
services other than my own.

But it's an *entirely* different thing when you are holding something
that someone else is very willing to DIE for, something that you could
easily share with the whole world at absolutely zero cost, risk, loss
or other detriment to you, and yet you STILL refuse to share.  It
absolutely baffles and boggles my mind that there are such cruel people
living on this planet, and *especially* in the so-called community of
so-called freedom and openness.

And because it is so totally incomprehensible to my mind how someone
can be like you, and be able to live with yourself while watching
someone else's life wither away because of your selfishness, I find
myself at a complete loss as to how one should interact with people
like you.

> And I even promise I won't call the police or any other officials. 

It doesn't matter whether you call them or not - I am still the most
wanted criminal in their eyes.

Your country is a police state, no different from the way it was in
WW II and just before, and I have no desire to go anywhere near it.
Unless, of course, I were to enter it in the same manner in which both
of

Re: Building a new totally free phone

[Michael Spacefalcon]

Nick  wrote:

> Your free phone idea appeals to me enormously, Michael.

Yay, one more supporter!

> However, can GSM really be a base for secure communication anyway?  

I see that after your post, the thread on the mailing list veered off
into a discussion of security.  But that diversion totally misses the
point: it isn't so much about secure communication as it is about the
Four Freedoms of software:

http://www.gnu.org/philosophy/free-sw.html

When it comes to the matters of free software philosophy, I am very
much like RMS.  I have a major problem with carrying a device in my
pocket containing firmware for which I lack the source - not because
it is a security threat, but because it's morally wrong.

The only difference between me and RMS/FSF is on the matter of
legalities.  While I define free software in terms of exactly the same
4 freedoms as the FSF, RMS and the "conventional" free sw camp add an
additional condition that these 4 freedoms be exercised legally -
whereas I add no such extra clause: whether it's legally free or
illegally free, it's still free software to me.

There also are some practical considerations that affect only feature
phones and not smartphones.  I have yet to encounter a phone UI design
that doesn't suck, and I hope that most people on this list will agree
with me that being able to customize the UI to one's preferences is an
essential freedom that a geeky, empowered phone user should have - and
I mean *really* customize the UI, not just twiddle menu settings, but
being able to study, modify or even totally rewrite the UI code.

Smartphones have a separate application processor to run the UI, so
you can indeed play with the UI on Linux to your heart's content while
keeping the modem as a black box.  But this approach does not work for
a feature phone where the UI and the modem are tightly integrated into
a single whole.  Exercising full freedom over the UI code in a feature
phone requires having a complete and rebuildable source for the
firmware suite as a whole.  (Having the GSM stack pieces as binary
objects to be linked with the UI source would work too, but then one
gets tied to a proprietary compiler toolchain, etc.  In any case we
already have full source for the GSM stack thanks to the TSM30 and
LoCosto leaks, so it's a solved problem now.)

Now look at the situation from the perspective of a user who does NOT
want his or her phone to be anything other than a plain phone.  For
such a user, a non-smart feature phone ought to be ideal, but if the
user also wants the freedom to fully own the UI design, s/he currently
has to pay for an otherwise completely unnecessary application
processor.  And when I say "pay for", I'm *not* referring to the
purchase price of the device - I would gladly pay a lot more for my
ideal Free Dumb Phone than the most expensive GTA04 or Ubuntu Edge or
whatever.  Instead I mean pay for in terms of carrying extra weight,
extra power consumption, extra system complexity otherwise unneeded,
many additional points of failure, etc.

*That* is what I seek to rectify with my Free Dumb Phone project,
aside from the moral issue.  Freedom is a right that all phone users
should enjoy, not a privilege that's limited to just Linux smartphones
to the exclusion of non-smart feature phones.

> I've heard that the encryption used is really crappy, and while some 
> things like MITM forced reregistration to disable encryption and 
> ease surveillance could be countered by appropriate phone settings, 
> if the best encryption algorithm available can be cracked by a home 
> PC in a few days, you're still screwed.

The GSM encryption is a red herring - it makes absolutely no difference
whether it's there or not.  Imagine if the GSM encryption were perfect
and unbreakable - what would change?  Nothing.  The over-the-air
encryption is only between the mobile station and the network.  In a
public phone network, where you can dial the phone number of any
stranger and hear each other's voices if the other party answers,
encryption can't be end-to-end.  The network has to be able to decrypt
with one end's key and re-encrypt with a different key for the other
end, so the network itself has (and must have) access to the cleartext
form of your digitized voice.

If I am the world's most wanted criminal and enemy #1 of all major
governments, and they want to spy on my phone conversations, they
aren't going to bother with cracking GSM over-the-air encryption,
they'll just put in a "lawful intercept" at the switch.

The only way to render all "lawful intercept" mechanisms ineffective
is to use end-to-end encryption.  That won't work when calling
strangers, or calling the transit line to check bus/train schedules
etc, but it's a very feasible mechanism for private and secure
communication mechanism among family members, friends etc.

Here in USA we have one advantage over the EU etc lands where most
people on this list seem to be located: CSD (circuit-switched data)
calls stil

Re. Building a totally new smart phone

[Michael Spacefalcon]

Adam Bogacki  wrote:

> I have not been able to find working links to freecalypso-sw anywhere.

Not able to find *working* links?  So the link I had posted earlier in
this thread:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/snapshots/freecalypso-sw-SE52Fru5.tar.bz2

is not working for you?

There is also a Mercurial source repository where the development
takes place:

https://bitbucket.org/falconian/freecalypso-sw

But if it gets taken down because some suppressive person reports it,
don't blame me.  Of course Mercurial is a distributed SCM just like
git, hence even if bitbucket.org takes it down, no source or history
will be lost - but it will make the project inaccessible to others
(except via the occasional snapshots which I post on my FTP site)
until we (the FreeCalypso community, currently consisting of one
developer and a few supporters watching from the sidelines) find a new
Hg webhost.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Re. Building a totally new smart phone

[Michael Spacefalcon]

Adam Bogacki  wrote:

> Now that I have dir 'freecalypso-sw-SE52Fru5' I am not quite sure what
> to do.
> Is there some documentation available, or a man page ?

No documentation has been written yet, because there is nothing to
document yet: all that's there is a FreeNucleus RTOS skeleton and some
host tools for pushing code images to the Calypso.  See my earlier
posts in this thread for my planned roadmap of adding "meat" to this
skeleton.

The FreeCalypso project is still in a very early stage - most projects
aren't even announced at all when they are this early in the development
process.  The only reason why I'm releasing this code at all is to
satisfy the moral requirement: on my planet it is a crime to have some
ware and not share it, no matter what the ware is.

If you want to play with the current code just for fun (there isn't
anything more that you would be able to do with it), you should be able
to at least compile it, and if you have one of the two supported phone
models (DP-L10 or GTA02), even run it and see the serial output from
the FreeNucleus demo app.  The steps are:

1. Build and install the arm-elf cross-compile toolchain.  Look in the
   toolchain directory and it should be obvious.

2. Using that toolchain, compile the target-utils part.  (Just run make
   in the target-utils subdir with the toolchain in your PATH.)
   You'll get the loadagent.srec image.

3. Compile loadtools - again, just run make in the corresponding
   directory.  These are host tools, so they need to run on whatever
   Unix/Linux machine you'll be using to push code to the Calypso.  If
   you are doing this with a Pirelli phone, FreeCalypso loadtools need
   to run on your PC/desktop/laptop.  If you are playing with a GTA02
   instead, you will need to either make a special cable to get to the
   Calypso via the headphone jack, or build loadtools to run on the
   GTA02 AP.

4. Once you've got loadtools, loadagent.srec and a compatible Calypso
   phone, you can actually try running this stuff.  If you have
   successfully passed steps 1 through 3, but are having difficulties
   with this step, ask and I'll help you.  If you are still struggling
   with one of the previous steps, work on that first.

A command like this (from a laptop with a Pirelli DP-L10 phone
connected and showing up as /dev/ttyUSB0):

fc-loadtool -h pirelli /dev/ttyUSB0

or like this (from the GTA02 AP, talking to the Calypso part of the
same phone):

fc-loadtool -h gta02 /dev/ttySAC0

should produce output that looks like this:

Sending beacons to /dev/ttyUSB0
Got beacon response, attempting download


The 3 lines beginning with "FreeCalypso loadagent running" will be
printed by code running on the Calypso chip itself, which you would
have built in step 2.  Once you are at the loadtool prompt, you are
interacting with the host utility you would have built in step 3,
which is in turn communicating over a serial channel with loadagent.srec
running on the Calypso.  Loadtool has commands for things like peeking
and poking registers, dumping and programming flash, etc.  But right
now the only documentation is the source code.  Type exit, quit or ^D
when you are done - it'll reboot the Pirelli phone or power off the
GTA02 GSM modem.

5. The Nucleus-based skeleton for what is meant to become the main GSM
   firmware lives in the nuc-fw directory.  You can build it as soon as
   you've got the arm-elf toolchain from step 1.  Unlike loadagent,
   which is meant to remain "universal" for all Calypso phones (just
   like TI's FLUID), the main firmware obviously has to be configured
   for a specific target.  The snapshot you are looking at has the
   beginnings of the configuration mechanism, but the latter doesn't
   do anything yet.  For now all that's there is the Nucleus demo, and
   it happens to be the same for all phones, so just type make in the
   nuc-fw directory with the toolchain from step 1 in your PATH.
   You'll get ramImage.srec, which you can run on your Calypso phone
   with the fc-xram utility:

fc-xram -h pirelli /dev/ttyUSB0 ramImage.srec

If you are doing this with a Pirelli DP-L10, you should see the output
from the demo app pouring on your terminal when you run the above
command.  Type ^\ to kill the fc-xram process on your host, but to stop
the demo app running on the phone and make the phone usable again,
you'll have to pull the battery and put it back in.  (And then reset
the clock, as this phone doesn't have a separate RTC backup battery.)

If you are playing with a GTA02 instead, you can run the same
ramImage.srec image, and you can push it with the same fc-xram command
either from inside the phone (from the AP) or from an external host
via that special headphone jack cable, but the demo app's output will
always go to the IrDA UART (unless you change the code in demo.c), so
you won't see anything unless you have that special serial cable.

That's all that one can do with freecalypso-sw for now.  My planned
next step is to at

First small steps toward free GSM firmware

[Michael Spacefalcon]

Hello Om community,

I am very pleased to announce that after many years of searching, I
have finally found a copy of TI's firmware deliverable package for
their Leonardo development board, i.e., for their Calypso/Iota/Rita
chipset reference platform.  It is the package which TI must have
given to all of their chipset customers including Nokia, Motorola,
Compal, FIC/Openmoko, LG, BenQ and many others, and which was used by
all of these companies as the starting point for making their unique
proprietary firmwares.  This Leonardo firmware source can be found
here:

ftp://ftp.ifctf.org/pub/GSM/TI_src/Sotovik/

It is a source with some object blobs unfortunately (but that was
expected), but it is complete in that one can build a functional fw
image from the included sources and object libraries.  This original
code will NOT run on a GTA0x modem; it runs on the Leonardo board
instead.  If you are curious as to what the Leonardo board looks
like, you can see a picture of it on page 10 of this TI document:

ftp://ftp.ifctf.org/pub/GSM/Calypso/chipsets+refdesigns.pdf

However, I have known for a long time that Om's GSM modem is actually
very close to the Leonardo board in terms of how the Calypso/Iota/RF
chip interconnections are wired.  (I already knew this fact ~2y ago
when I first saw the doc/calypso-signals.txt file in the OsmocomBB git
tree - read that text file and judge for yourselves.)  The implication
from this hardware similarity is that it should be quite easy to take
firmware code that runs on the Leonardo board and port it to run on
the GTA0x modem instead.

I have just proven the above hypothesis by producing a leo2moko port,
i.e., a port from Leonardo to moko.  You can find the Wine-buildable
source here:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/

You can build that source under Wine (see instructions in the README
file inside the tarball) and produce an S-record image which you can
then flash into your GTA0x GSM modem with fc-loadtool - the latter is
my free replacement for TI's proprietary FLUID.

My own limited experiments indicate that this firmware is able to dial
voice calls (makes the other party's phone ring), receive voice calls
(I dial the number of the test SIM card in my GTA02 and see RING
messages appearing in the AT command channel), and even make CSD
(circuit-switched data) calls successfully - being the outlaw that I
am, I take great joy in playing with CSD (which I plan on using for
encrypted voice further down the road) and thereby showing my middle
finger to the NSA etc.  However, I have NOT fully tested the "normal"
voice call operation: I have only verified that the fw places and
answers these calls, but I haven't tested the actual voice audio.  The
latter omission exists because I have very poor understanding of the
Linux-based software that needs to run on the GTA0x AP, and on my test
GTA02 I run a very minimal buildroot environment on the AP.  I have
not yet figured out how to configure the AP-controlled audio system to
pass the voice path between the GSM modem and the physical earpiece
and mic, hence my current inability to test this voice path.

Therefore, I encourage other community members to play with this
firmware and see if it actually works end-to-end for voice calls.

Viva la Revolucion,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> > then flash into your GTA0x GSM modem
> Wait, it works both on gta-02 and gta-04?

By GTA0x I meant GTA01 and GTA02.  GolDeliCo' so-called "GTA04" is
rather badly misnamed: GTA originally stood for "GSM-TI-AGPS"; thus a
device that does not use a GSM chipset from TI cannot be properly
called GTA0x.

It is also quite misleading that Nikolaus markets his product as an
"upgrade" to the good old Openmoko phones, as it is actually a
downgrade: it replaces a free-able GSM modem (i.e., one on which the
ability to run 100% free fw is within reach) with a non-freeable one,
i.e., one on which such freeing is totally out of reach.

And for the record, regarding the recent prolonged debate on this
mailing list about the freeness of GolDeliCo's product or lack thereof,
I agree totally with Bob Ham.  However, I differ from Bob in that in
my view, the closed proprietary nature of Nikolaus' product is not
worth shedding any tears over because it is a useless product in the
first place.  The good old GTA02 from Openmoko is a MUCH better phone
than any "GTA04".

> Also, did you test if data connection works?

Only CSD, not GPRS.  I.e., I have tested CSD and saw it working; as to
GPRS, I haven't tested it because I have not yet learned it well
enough, but I suspect that it works - please test it yourself and let
the list know what you find.

> I don't use phone calls,
> only encrypted ssl over tcp over 3g/wifi.

There is no 3G on the real GTA0x, i.e., on GTA01/02.

> I am very interested if this can be flashed to gta-02 device,

I have it flashed into mine. :)

> (unfortunately I don't own gta-04).

Don't say "unfortunately", you are very fortunate to have a much
better device, which are sadly no longer made, and even more sadly,
the leftover stock of Om-made ones is rapidly being destroyed by
people like Nikolaus who cannibalize these great phones for plastic
parts to make their inferior "GTA04"...

> Also, is there is a possibility to
> change IMEI during flashing?

Yes, you can change the IMEI quite easily to whatever you like, and in
fact the ability to do so is completely independent of which fw you
use: my current leo2moko port, the future full FreeCalypso fw, or even
the original factory fw from Om.

The modem has a total of 4 MiB of its own NOR flash, divided (hw-wise
inside the chip) into two banks: a 3 MiB bank at the lower addresses
and a 1 MiB bank at the higher addresses.  The lower-addressed 3 MiB
bank holds the fw image - that is what you erase and overwrite when
you reflash from moko10 to moko11 for example, or when you flash my
FreeCalypso firmware.  The higher-addressed 1 MiB bank (or more
precisely, 7 sectors of 64 KiB each within that bank) holds the modem's
FFS (flash file system) in a TI-invented format - one which I had
successfully reverse-engineered even before I found the source, I
should add.

Whatever you do, DO NOT DESTROY YOUR ORIGINAL MODEM FFS!  The original
GSM modem FFS from Om's factory contains RF calibration data, and if
you lose these calibration values, your precious GTA0x will become a
brick (at least GSM-wise) unless you can get that RF calibration
redone.  For an idea of what kind of special RF test equipment would
be needed to redo the RF calibration, see this document from TI:

ftp://ifctfvax.Harhan.ORG/pub/GSM/Calypso/rf_calibration.pdf

Needless to say, redoing the RF calibration would be *very* expensive.

My fc-loadtool utility (which you will need to compile from source
from my freecalypso-sw Mercurial tree) allows one to read out the
content of a flash memory region and to save it into a file.  If you
are going to do any hacking at all on your GTA0x GSM modem, I recommend
that you make a dump of your FFS sectors (containing these precious RF
calibration values) and save that dump very securely, before you do
anything else.

The IMEI is stored in the same FFS as the RF calibration values, just
in a different part of the directory hierarchy: the IMEI lives in an
8-byte file named /pcm/IMEI; the RF calibration data live in a bunch
of files under /gsm/rf.  I have not yet written a utility to edit that
/pcm/IMEI file inside the FFS image in a user-friendly manner, so for
now you would need to use a hex editor - the IMEI is stored in a very
simple unobfuscated form in that /pcm/IMEI file.

> Sorry if my questions are a little bit off topic. Anyway I am very
> interested in free fw for my devices - OM gta-02 and n900.

See above regarding Om GTA02.  As to the N900 from Nokia, I doubt that
much freeing can be done with its BB5 modem: I don't know of any
leaked hw docs (let alone fw sources) for that modem, and I've heard
something about it having a crypto-signature-checking bootloader - we
are VERY fortunately to NOT have one of the latter in the Calypso!

(Calypso's on-die ROM bootloader is actually awesome - not only is it
 completely non-"secure", but it is also completely unbrickable: no
 matter what state you get your flash into, one can *always* 

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

For those following the FreeCalypso project, I have just put out a
packaged release of my GSM flash reading/writing etc tools:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r1.tar.bz2

Of course the source for these tools has been available all along in
my freecalypso-sw Hg repository on bitbucket.org and in my snapshot
tarballs on the FTP site, but the release I've just put out includes a
prebuilt loadagent.srec image as well, so you can now compile and run
my fc-loadtool utility without having to build an ARM7 cross-compiler
toolchain first (to compile loadagent for the Calypso target).

My fc-loadtool is a free (source-enabled) replacement for TI's
proprietary FLUID tool documented on the now-classic Wiki page:

http://wiki.openmoko.org/wiki/GSM/Flashing

The *.m0 byte-reversed S-record format for GSM firmware images appears
to have been used in all of TI's builds, both Calypso and the later
LoCosto etc (see the http://scottn.us/downloads/peek/ find, for example),
so it is no surprise that the "official" mokoN images linked to from
the above wiki page use this format.  My leo2moko port, which builds
with TI's original toolchain under Wine, produces an image in the same
format as well.

My fc-loadtool can flash these *.m0 images as well as the more standard
S-record and binary formats; I don't know too much about the exact
capabilities of TI's FLUID as I never found a source for that one.

You can thus use either fc-loadtool or the original fluid.exe to flash
either an official mokoN image or an image you built yourself from my
leo2moko port, i.e., the compatibility matrix is complete.

Enjoy!

Viva la Revolucion,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Jose Luis Perez Diez  wrote:

> The procces to flash GSM firmware used linux, the serial port,
> and the fluid binary see 
>
> http://wiki.openmoko.org/wiki/GSM/Flashing#Manual_Update_.28GTA01.2C_GTA02.29_.2F_geek_way

Yes, and that exact same procedure should work just as well if you
substitute your own *.m0 image built from my leo2moko-r1.tar.xz source
in the place of calypso-moko11.m0.  I say "should" because I haven't
tried it myself - like Richard Stallman, I avoid proprietary software,
so I use my own fc-loadtool instead of that fluid.exe for which I have
no corresponding source.

Just give it a try - if you don't like my illegally-free GSM fw, you
can always reflash back to the official calypso-moko11.m0.

Patryk Benderz  wrote:

> Can't we just use dfu-util?

The GSM modem has its own processor, its own independent address space,
its own address and data buses, and its own independent flash memory
(NOR in a Multi-Chip Package combined with SRAM).  Neither dfu-util
nor the AP (application processor) bootloader it is talking to knows
anything about that separate hardware block.

In order to reflash the GSM modem, one needs to establish communication
with Calypso's own boot ROM.  That can be done either from a running
Linux system on the phone's AP (i.e., from inside the phone) or
externally via a classic "T191 unlock" cable plugged into the headset
jack.  (The latter approach makes more sense for FreeCalypso
developers.)  Either way, one needs Linux software running on the
phone's AP in order to control the power to the modem and to enable
the headset jack serial channel if you wish to use the latter.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> Why not add information about free fw and loader to the mentioned wiki page?
> So that people who are not in this mailing list, may know about this fw
> and a free fc-load tool.

Adding the info to the wiki would be a good idea indeed, but there
would be several difficulties with that:

* Editing the wiki requires a login account; I don't have one and
  don't feel comfortable asking for one.

* Most of the Openmoko community sees my FreeCalypso work as being
  illegal, because they have voluntarily chosen to live and/or accept
  citizenship in repressive countries which deem it to be so.  I
  suspect that the power-keepers of the Om Wiki would not want to have
  anything to do with my illegal project and its equally illegal
  fruits.

> Also, it would be good to have step by step instructions like get this
> source here,

These 3 tarballs contain everything one would need:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1.tar.xz  -- the source
ftp://ftp.ifctf.org/pub/GSM/TI_src/wine/installed-env.tar.xz-- build tools
ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r1.tar.bz2-- free flasher

> compile it like that,

The leo2moko and loadtools tarballs contain README files with
compilation instructions.

> get another source there, compile it,

See above.

> and run this command with these arguments.

The README file in the loadtools package tells you how to run
fc-loadtool as well.

I will grant though, that my current instructions are written assuming
a highly technical user, and it would indeed be beneficial to have
another, more hand-holding version for more novice users.  What we
need for that is a community volunteer who would be both able and
willing to produce one.  I.e., we need a community volunteer who can
work with someone like me on one end (understand my instructions etc),
and also be in touch with more novice users on the other end.

Anyone wants to volunteer?  All you would need to do is to go through
the process of compiling and flashing my GSM firmware into your GTA02,
become comfortable with the process, and then document it for others
who would need more novice-friendly hand-holding.

If you or anyone else would like to give it a try, you can start by
downloading the 3 tarballs listed above and then attempting to follow
the steps in the README files inside.  Tell me where you get stuck,
and I'll help you navigate that step.  If you can go through the
process once, even if it requires a lot of hand-holding from me,
chances are good that you would then be able to document the process
for others at the less technical level.

VLR,
SF

P.S. If anyone manages to get as far as the loadtool> prompt, please
give me a shout before you type any flash erase or flash program
commands - I would not want you to ruin your device by wiping out its
very hard-to-recover RF calibration data.  If you succeed in reaching
the loadtool> prompt, stop there and ask for further assistance - I
will then tell you how to save those precious RF calibration values.

There is no possibility of damage until you reach that loadtool>
prompt and type a flash erase or flash program command though, so
prior to reaching that point, there is nothing to worry about - please
play freely!

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Ian Stirling  wrote:

> However, once anyone has used your work to change the IMSI of their 
> phone

I assume you meant IMEI.  Phones don't have IMSIs, those are numbers
stored in SIM cards.

> and you are aware of this,

Yes, I will most likely be aware of it, as I will gladly hand-hold any
criminal or want-to-be-criminal through the process of changing their
IMEI.

Just as an FYI - if you use the competing OsmocomBB software (which is
much more readily accepted by this community), transmitting whatever
IMEI you like toward the GSM network is even easier: because OsmocomBB
doesn't know how to parse TI's FFS (flash file system) format and to
extract the IMEI (or the RF calibration values) from it, there is no
IMEI "changing" with OsmocomBB per se.  With OsmocomBB you *always*
have to enter your own IMEI manually in their CLI, and the software
has no psychic powers to tell whether or not the number you've entered
matches what's printed on the sticker inside the battery compartment.

So if all you are after is transmitting a "false" IMEI toward GSM
networks, a very easy way to do so has been available through
OsmocomBB for many years before my recent work.  Changing the IMEI in
FFS (where either the phone's original firmware or my illegally-free
replacement will read and use it) is necessary only if you want to not
only transmit a "false" IMEI, but also retain the full functionality
of the phone - OsmocomBB lacks the latter.

> if you do not stop distribution,

Of course I won't stop distribution, I don't bow down to any f***ing
governments.

> you are liable to conviction
> and a term of imprisonment not to exceed 5 years.
> http://www.legislation.gov.uk/ukpga/2002/31/section/2

UK laws don't apply to me as I have no plans of ever setting foot on
UK soil.

> This is a poorly drawn bit of legislation, and in principle could also 
> cover the operator of any
> website hosting such code, once the operator becomes aware that they are 
> facilitating this.

Yet another reason why I don't use any servers other than my very own:
I would not want to entrust the distribution of my software to some
cowardly "law-abiding" webhost who would take my ware down out of fear
of being sued or prosecuted or whatever.

> In principle, this could lead to an EU arrest warrant,

I have no plans of setting foot on EU soil either.

> or even a request for extradition.

This one is truly laughable - I am the sovereign of my own micronation.
What are they gonna do, send a diplomat to the Micronation of Falconia
asking me to extradite myself?

Paul Wise  wrote:

> > There are separate issues around the IP that you do not have permission to
> > use.
>
> This is the illegality that he is referring to, not any potential
> spectrum/GSM/IMEI issues.

Correct.

> I guess he would ignore the latter as well as the former though.

Also correct.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

"dmatthews.org"  wrote:

> This is something I've quietly had an interest in for a year plus.

Yup, I remember you from 2011. :-)

> I'd like to suggest that it would be beneficial not only to have some hand
> holding for people that want to compile, but also sample binary for those of
> us that may not have easy access to necessary hardware and software.

Compiling the leo2moko version of the GSM fw from the semi-src does
not require any special software, let alone hardware: the hardware is
any regular PC, the software is your favourite GNU/Linux distribution
with working Wine.  Nothing more is needed: if you have a system with
working Wine, just unpack my tarballs and run the winebuild.sh script.

However, having a prebuilt binary of the leo2moko GSM fw (to encourage
prospective testers from the shy-land) does sound like a good idea, so
I have just put one out:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1-bin.tar.bz2

Or was your reference to "necessary hardware and software" regarding
the flashing process, rather than compiling the gsm-fw.m0 image
itself?

Regarding the flashing process, I do agree that the current barrier to
entry is still a little too high and could use some lowering.  As
things stand right now, if you want to do your own flashing operations
on the GSM modem in your GTA02, the following skills/tools are
required:

1. Whatever distro you are running on your FR, you need to know it
   inside out: you need to know how to ssh into your phone, how to
   kill gsmd or whatever process talks to the modem (and to ensure
   that it doesn't get restarted until you are done flashing your new
   fw and wish to test it live), and how to twiddle the power_on and
   download controls for the modem under /sys, as appropriate for
   whichever GTA02 kernel version you are running.

2a. You need to be able to cross-compile my fc-loadtool utility to run
on the application (Linux) processor of your GTA02, and do it in a
way that will be compatible with your distro from the previous
paragraph.  (I could send you my binary, built with some
CodeSourcery toolchain for my Buildroot AP environment, but I
doubt that one would be able to just plop it into SHR or QtMoko or
whatever, and have it "just work".)

-or-

2b. You need to buy a "T191 unlock" cable that would plug into your
Neo's headset jack - in that case you would be able to run
fc-loadtool from your GNU/Linux PC, removing the need to build it
for running from inside the Neo.  But even with this magic cable,
you would still need to satisfy requirement 1 above: you still
need to ensure that there is no gsmd etc running, and you'll need
to twiddle the download and power_on modem sysfs nodes by sshing
into the phone.

I'm thinking that one possible way to lower this entry barrier would
be to produce and publish a bootable SD card image with the following
features:

* A known environment, eliminating the "whatever FR distro you happen
  to be running" factor;

* Specifically designed for manual poking at the GSM modem - no gsmd
  and no "normal" functionality;

* Have the special Linux image come up with the headset jack serial
  channel enabled and with the device screen showing pressable buttons
  for "Modem ON" and "Modem OFF" - thus anyone using the headset jack
  serial cable method would have no remaining barriers;

* Have the image also come up with ssh access via USB enabled, and
  have fc-loadtool and some other tools already available inside -
  thus anyone using the sans-special-cable method would be able to ssh
  into the phone in a known way and run commands which can be given
  verbatim with no sophisticated preparations needed.

Producing a Linux image like the above won't be an overnight deal, but
it is something that I can work toward.

> I might have had some qualms about repercussions of using this software
> in Europe,

Why?  The radio transmissions from the illegally-free fw are strictly
identical to those produced by the original (presumably legal) mokoN
firmware, so how would anyone ever detect that you are using my
illegally-free fw?  The physical appearance of the device (as would be
seen by a cop pulling you over on a highway for driving too fast or
whatever) also does not change with illegal fw flashing, so if the
device looked like a legal cellphone originally, it will still look
the same...

> I'd be able and would love to test once this effort approaches some level
> of maturity.

Ahmm, asking for "some level of maturity" before one is willing to
even *test* a piece of software is rather dysfunctional.  How would
the sw *ever* reach any level of maturity without some people testing
it early on, reporting their experiences, sending bug reports etc?
Therefore, *someone* needs to be willing to act as an adventurous
alpha tester, trying out what exists currently.

I do concede though that the barrier to entry for prospective testers
needs to be lowered, so I won't be holdin

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> Okay, so first thing I did is I have compiled loadtools, as planned
> right on freerunner.
> [...]
> After short build I have three binaries installed
> fc-iram fc-loadtool fc-xram
>
> I believe they will run.

Congrats, you have successfully navigated one part which I thought
would be very hard for most users.

Using the loadtools you've got installed on your FR now, you can do
another important step: make a backup copy of your modem FFS.

Step 1: run fc-loadtool like this (from inside the FR):

fc-loadtool -h gta02 /dev/ttySAC0

You should see a bunch of messages followed by a loadtool> prompt.

Step 2: when you reach that prompt, enter this command:

flash dump2bin my-flashdump.bin

You should get a dump of your modem flash content in a file whose name
will be whatever you've entered as the last argument.  The file should
be 4 MiB long.  Transfer it from your FR to your PC and examine it
with your favourite hex viewer.  You should see the original fw image
(moko10 or moko11 or whatever you are running) in the first 2.25 MiB
or so, then blank flash (all FF bytes) until offset 0x38, then 7
sectors of 64 KiB each (0x7 bytes total) of FFS (flash file system),
then blank flash again for the last 64 KiB.

Verify that the content of the flash dump is as expected, and save it
securely - having this backup copy will keep your FR from becoming a
brick in the case that some subsequent operation will destroy the RF
calibration values in FFS.

> Then, I have tried to compile the firmware with supplied wine environment.
> [...]
> Inspite of using nowhine, I saw a lot of fontconfig warnings .

I never got those on my system; the whines I get from my wine are the
ones you can see in my cheesy nowhine.c source.  You are more than
welcome to edit nowhine.c and make it suppress whatever whines _you_
get. :-)))

> Build fails, failed a couple of times, both by using nowhine or wine
> without wrappers.
>
> Because one windows utility, probably linker, fails
> http://norayr.arnet.am/tmp/2013-11-09/openmoko/wine_error.png

Yes, it is the linker indeed, which is bad news because one can't
build a firmware image without passing the linker step. :-(

> Error details
> http://norayr.arnet.am/tmp/2013-11-09/openmoko/wine_error_details.png
> Backtrace: http://norayr.arnet.am/tmp/2013-11-09/openmoko/backtrace.txt

Not much I can do with these: I don't have source for TI's compiler
toolchain any more than you do, and I'm not a wine expert either.
See below regarding what system I use.

> Report: http://norayr.arnet.am/tmp/2013-11-09/openmoko/report.txt

Looks as it should, except for the wine page fault error when running
vlnk470.

> I wonder, if the problem is in my wine version or system setup.
> I have 32 bit wine running on x86_64 GNU/Linux, use it sometimes, and it
> worked fine before.

I use Slackware (a GNU/Linux distro for Luddites like me), all 32-bit
only, nothing x86_64 at all:

hec@darkstar:~$ uname -a
Linux darkstar 2.6.37.6-smp #1 SMP Sun Jan 27 05:32:33 GMT 2013 i686 Intel(R) 
Core(TM)2 Duo CPU P8600  @ 2.40GHz GenuineIntel GNU/Linux
hec@darkstar:~$ cat /etc/slackware-version
Slackware 13.37.0
hec@darkstar:~$ wine --version
wine-1.5.23

> I am sure, it would be much easier to debug and understand the problem
> in case of using native Unix build environment.

Yeah, no kidding!  Firmware that can only be built with a proprietary
compiler which exists only as Weendoze binaries for which none of us
has any source is not really free - hence my chosen subject for this
whole thread: "First small steps toward free GSM firmware", not "Free
GSM fw is finally here".  What we have so far is indeed only the first
small steps, not a complete victory yet.

I am working on it, albeit at a snail's pace.  I've got an ex-TI person
helping me with my FreeCalypso project (when TI shut their Wireless
Terminal Business Unit down, a lot of people were out of a job - wasn't
fun for those people, but guess why my FTP site now sports 4 different
TI source leaks :), and with that person's help I was able to
understand the overall architecture of how the major pieces fit
together.  Now I have an arduous task in front of me: in order to
rebuild the firmware in a sane environment (using gcc and all that
good stuff), I have to reintegrate the fw architecture piece to piece.

The dependency graph isn't cleanly-vertical, so it is not a simple
matter of the higher layers sitting atop the lower ones - almost every
piece depends on almost every other in some way.  So I have to take
one low-level piece, temporarily remove whatever dependencies it likely
has on other pieces which I haven't got to yet, and get that piece
integrated in my gcc-built fw tree.  Then add the next piece in the
same manner, and at some point I'll get to re-enabling the things I
had to temporarily stub out to get the first pieces to compile and
link...  Not fun at all, but I don't see any other way.

You are more than welcome to see my pro

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> Hehe, flashed your image!
> http://norayr.arnet.am/tmp/2013-11-09/Screenshot-2_patched.png

Nice!

> Thanks a lot.

You're welcome. :)

> I don't use gsm usually, I'll check how gprs works over gsm.
> It did not work before, usually SHR did not want to connect.
> [...] But I would
> like to learn to establish gprs connection from console.

Right now all my knowledge of GPRS consists of just this one paragraph
from Harald Welte's paper:

http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf

(Paragraph 6.1 on page 8 in the PDF.)

Given this highly limited amount of GPRS knowledge on my part, I'm
afraid that I won't be of much help with GPRS until *much* later down
the road, when I'm ready to try integrating (and learning) GPRS, well
after I get all basic GSM functionality (voice, SMS and CSD) fully
working in the gcc-built FC GSM fw.

> P. S. one day I'll play with IMEI too.

Have fun!  Here are some tools to get you started:

ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/mpffs-tools-r1.tar.bz2

In another msg:

> I can already tell that I could not use sms's previously, they did not
> work. I just received many sms's after reboot, and I was able to remove
> them.
> It did not work before.

Now this is truly interesting - are you saying that you are seeing
differences in SMS handling behaviour between moko11 and my leo2moko,
and that leo2moko works better for you in this regard?

Details, please!  I find it rather improbable that moko11 would have a
fatal defect in something as basic as handling incoming SMS, hence me
trying to understand exactly what it was that didn't work for you with
moko11 and got fixed with leo2moko.

Don't get me wrong, I would *love* to find out that my fw has some
actual functional improvement over moko11, beyond the "feel good" of
having a viewable source, but let's first confirm that it's real and
not imaginary...

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: First small steps toward free GSM firmware

[Michael Spacefalcon]

Wow, I went to bed after my last post, and when I got up this morning,
there had been a lively discussion between Norayr, Joerg and Nick!

As much as I would love to be proven wrong on this, I consider it
*very* unlikely that there is any functional defect in moko11 which
somehow gets magically fixed with my current leo2moko transitional
step.  There probably *are* bugs galore in TI's binary object libs
which contain the bulk of the GSM protocol stack, likely even buffer
overflow etc bugs which could be exploited by someone setting up a
rogue BTS and feeding control packets over the air containing things
which "shouldn't happen" - but if such bugs are present in moko11,
they are probably present in all versions of TI's TCS211 binary libs,
including the versions used in my current leo2moko port, hence we
don't have a fix for that malady yet.

The LoCosto source at http://scottn.us/downloads/peek/ does have the
GSM/GPRS protocol stack in full source form (aside from GPF, which
appears to have been distributed as binary libs even inside TI!), and
I do seek to replace our current blobs with this LoCosto version, but
before we can do that, I first need to go through the hellish process
of reintegrating all of the lower-level pieces (basically everything
under chipsetsw in the leo2moko source tree) into my Unix/gcc build
environment - and I'm just starting on that one, currently trying to
figure out why the RVT task is not emitting "system time" trace
messages every 20 s like it should...

In the meantime, the only gain which the community can get from my
leo2moko transitional step is the change from a black box to a glass
box: you can see all of the sources and binary objects from which I
have built my fw, the binary objects contain a good amount of symbolic
information making disassembly quite practical, and there is a map
file from the linker which shows what every byte in the final
flashable binary is for and what it corresponds to in the source.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

/gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band

[Michael Spacefalcon]

Hello Om community,

In the course of hacking TI GSM firmwares, I have come across something
that some of you may find interesting, or might even have some insight
into.

We all know that our good familiar Neo Freerunner (GTA02) was made in
two versions: one with 900/1800/1900 MHz bands, the other with
850/1800/1900 MHz instead.  The hardware difference is one RF SAW
filter part populated differently on the same PCB; see this picture:

http://wiki.openmoko.org/wiki/File:Gta02a6_comms_chips_under_shield.JPG

The SAW filters for the GSM downlink Rx path are the 3 little buggers
near the upper right corner, immediately adjacent to the shiny metallic
component which is the antenna switch.  There is one Rx SAW filter for
each of the 3 supported bands: one for 1800 MHz (both GTA02 versions),
one for 1900 MHz (ditto), and one populated for either 850 or 900 MHz.
(*I think* the topmost one out of the 3 in that picture is the one
responsible for the 850 vs. 900 MHz difference, but please double-check
that before attempting any surgery on your Neo!)

Well, here is the part which will surely surprise at least some of you:
the standard firmware for the GTA01/02 modem (which is the same for
all versions, both GTA01 and GTA02) does not actually know which 3
frequency bands are supported by the device it runs on!  And no, it
does not auto-detect either: there is no way (short of ESP) for any
firmware running on the Calypso/Iota/Rita chipset to divine what kind
of SAW filter sits between that chipset and the antenna.

Instead, as strange as it may sound, the modem (at least when running
the standard mokoN firmware, see below) believes itself to be quad-
band!

In TI's universe, the "standard" way to "teach" a GSM device (phone or
modem) which GSM frequency bands it supports is *not* to hard-code
that knowledge in the firmware at compile time; instead this property
is stored in a configuration file named /gsm/com/rfcap in the GSM
device file system.  Yes, TI-based GSM devices all use a flash file
system with a very UNIX-like "look and feel", including UNIX-style
pathnames; see my write-up:

https://bitbucket.org/falconian/freecalypso-sw/src/1852900ce9ea4ac52d4648f7d9ca46897eb3640b/doc/TIFFS?at=default

Like most files in TI's GSM FFS, /gsm/com/rfcap is a binary file, not
ASCII.  It is a file of exactly 16 bytes, and although I haven't found
a formal document describing its format in plain English, we can study
the code that reads this file and acts upon its content:

http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m-gsm/rr/rr_csf.c

The 16-byte file is being read into a variable of type EF_RFCAP, which
is defined here:

http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m/condat/com/include/pcm.h

Lines 442 through 460 (inclusive) give the structure definition, which
is followed by the definitions for the bit fields in each byte.

And here is what this /gsm/com/rfcap file contains on a standard GTA02
modem, as revealed by a TIFFS parsing tool such as the mpffs-tools-r1
package I released last summer:

00 1F 41 14 00 00 00 00  50 00 00 A5 05 00 C0 00

Decoding the meaning of the rest of the bytes is left as an exercise
for the reader, but I draw your attention to the 2nd byte, which is 1F.
This byte indicates which RF bands are physically supported by the MS
(mobile station) hardware, and 1F means quad-band, i.e., all 4 of 850,
900, 1800 and 1900 MHz.  Thus even though my trusty GTA02 is only
900/1800/1900 MHz tri-band in reality, it believes itself to be
quad-band!

Digging some more, one finds that the 16 bytes quoted above appear in
the moko10 and moko11 fw images (convert them from *.m0 to plain binary
with the mokosrec2bin.c utility I wrote almost a year ago, then do the
"binary grep" with the memmem() C library function), and further
analysis reveals that these "standard" firmwares unconditionally
overwrite the /gsm/com/rfcap file in FFS with the hard-coded "string"
of bytes on every boot.  To convince yourself of the latter fact, take
a GTA02 modem with moko11 in it, change the rfcap file in FFS to
something else, reboot the modem normally, and observe that the rfcap
file will be reverted back to the 16 bytes shown above, claiming to be
a quad-band GSM device.

My leo2moko firmware does not contain this rfcap-resetting "feature":
it does not automatically overwrite the rfcap file with anything, and
uses whatever settings happen to be written in the FFS (the modem's
flash file system).  At the present, there is no practical difference:
if your modem ever ran moko10 or moko11 prior to being flashed with
leo2moko, the content of the /gsm/com/rfcap file in FFS will be what
moko10/11 wrote into it the last time it booted, which is the hard-
coded "I am quad-band" value.

But I wonder - and this is really the main reason for this lengthy
post of mine - is it really a good idea for a tri-band GSM modem to
believe itself to be quad-band?  There are two potential problems I
can

Re: /gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> Bottom line: even 850MHz FR can do 900MHz but the reception is pretty poor=
> though just sufficient in usual urban environment.

Hmm, interesting!  Of course given the geographical theater I operate
in, my interest would be in going the other way around.  The funny/sad
thing is, I do not currently have *any* GSM (or GSM+newstuff) device
which has "proper" support for the 850 MHz band (the secondary GSM
band in the lands I operate in) and which I can hack in any way at all:
sure, there are 3G+ smartphones all around me, and they all claim to be
quad-band when they go into GSM fallback mode, but of course they are
the typical Android etc crap, and I don't know how to hack them (if
that can be done at all), so I don't even know whether that SGS2 (as
an example) is connected to an 850 MHz network or a 1900 MHz one!

As to the hackable Calypso devices I have (one FR and a few Pirelli
DP-L10s), they are all 900/1800/1900 MHz, so to this day I don't even
know what GSM services might exist in the 850 MHz band around me...
I do use one of these devices as my everyday phone though (and the
non-Calypso Mot V66 I used previously was/is 900/1800/1900 MHz as
well), so basically all my cellphone-using life I've been using what
is effectively a 1900 MHz only device.  I roam over a pretty wide area
and have yet to encounter a spot without good coverage - and it is
kinda neat when I realize that I get all this great coverage despite
my phone supporting just GSM1900 and absolutely nothing else!
(Meaning nothing else relevant to my geographical area.)

But given what you just said, I am now tempted to try running cell_log
(from OsmocomBB) set to the [128,251] ARFCN range (corresponding to
the 850 MHz band), and see if it can pick anything up.  I'll try it
when I get some time to play.

> I don't think network/BTS can "direct" the mobile to another channel, it can
> only adveritse other channels but it's up to mobile to determine if that=20
> channel actually works in the particular situation

Indeed I think that the scenario I hypothesized in my original post is
very unlikely in reality, but as far as the network directing a mobile
to a channel, I was thinking along the lines of what happens in call
establishment, channel hopping etc - granted, I still have a lot of GSM
learning ahead of me as I set out to reintegrated that code from
 in the place of the binary libs in
leo2moko, but I was under the impression that whenever the BTS basically
tells a mobile "let's continue this conversion on channel so-and-so",
that direction contains not only the new timeslot number, but also the
new ARFCN, and at least in theory the network is free to pick any ARFCN
which it serves and believes the mobile to support as well.

But of course I could be entirely off-base here, as I haven't really
learned that part of GSM yet.

> there may be other=20
> problems to receive 900MHz band than just a SAW filter, like local interfer=
> ence=20
> or whatever.

I see what you are saying: the scenario of a tri-band mobile device
advertising and believing itself to be quad-band (what Om modems do)
is indistinguishable from that of a genuinely quad-band device having
the 4th band rendered unusable by some unpredictable external factors
like local interference.  A valid point indeed.

The fact that, as you say, an FR made for 850 MHz could receive 900 MHz
and work so-so (limp along) does make for an argument in favor of
keeping the "I am QB" setting in that /gsm/com/rfcap file - if that
file were changed to reflect just the bands "officially" supported by
a given FR unit, it would not even attempt tuning its radio to the 4th
band.

Has anyone else in the community ever used an FR successfully in the
"wrong" band?

> When the mobile can't use a certain frequency, the BTS will not
> "force" the mobile to that frequency.

OK, I need to learn some more about what happens in "channel hopping"
scenarios, and how (and by whom) the frequency channel is selected in
those cases.

Oh, and while we are on the subject of GSM frequency bands, I guess I
need to give everyone an update on my efforts to build my own quad-band
Calypso phone.  Right now that project is bogged down in mechanical
design issues which have nothing to do with the number of GSM bands or
even with the Calypso chipset.  What I really want is something as
nearly-identical as possible to the Pirelli DP-L10, and I won't feel
satisfied with anything less than that.

Back in 2013-11 I was in communication with some seller (German
apparently, but advertised on a Chinese site) who claimed to have
around 700 of those Pirellis for sale.  I wanted 100, and the price
would have been some 3-4 months worth of my spare budget.  But just as
I raised the money for the first partial order, the guy told me that
someone else bought all of those phones, they had no more left, and
whoever bought all 700 or however many they had, was not willing to
resell any

Re: [Community] GTA04A5 / Letux 2804

[Michael Spacefalcon]

Dr. H. Nikolaus Schaller  wrote:

> So please think again if you want to upgrade your GTA02 with a GTA04A5 board.

Upgrade?  Surely you must have meant downgrade - why would anyone in
his or her right mind voluntarily give up a device that is 100%
freeable down to the modem (GTA02) for a Qualcomm-based closed
proprietary product like yours?

Sorry, couldn't resist.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Community] GTA04A5 / Letux 2804

[Michael Spacefalcon]

Dr. H. Nikolaus Schaller  wrote:

> Why do you assume that your (IMHO unlawful) procedure done to "free" the
> Calypso is not possible for a Qualcomm modem?

Because all "modern" baseband processors (MTK, Qualcomm etc) have ROM
bootloaders which perform cryptographic verification of downloaded fw
images, and will not boot any image that has not been signed by the
secret key corresponding to the public key whose hash is burned into
OTP (one-time programmable) fuses right in the modem chip silicon!
The FSF term for this freedom-robbing feature is tivoization.

Even the later chips from TI (Calypso+ and LoCosto) have this "feature",
but the classic Calypso used in Openmoko GTA0x and Pirelli DP-L10
phones does not - that is the critical distinction.

Of course the classic Calypso chips are no longer made, but I have a
stash of 100 of them sitting right here in a desk drawer - should be
enough to make illegally-free phones for the true freedom lovers among
us.  And if I'm not mistaken, some Chinese sellers still have quite a
bit more available.

> So I think your conclusion is just based on your pure incapability to do the
> same.

s/incapability/disinterest/

If I wanted to obtain a bootleg copy of Qualcomm's modem source code,
I could probably do it.  Don't forget that I operate in the very same
geographical area where Qualcomm has its HQ, Qualcomm has a habit of
employing "desperate for a job" programmers for stupid grunt work at
offensively low pay rates (with high turnover as a result), and people
in USA are not as obsessed with being "law-abiding citizens" like
Europeans.

But life is short, I have plenty of other things I wish to accomplish
before I kick the bucket (building a new quad-band GSM-only "dumbphone"
based on the Calypso being just one of them), so I leave the task of
freeing Qualcomm/MTK/etc modems to someone else who, for whatever
reason beyond my comprehension, finds the good old GSM and the good
old Calypso to be "not good enough" for him or her.

If and when someone posts sources and instructions on this list that
do for the GTA04 modem what my hack does for the Calypso, only then
will GTA02 and GTA04 become equally free.  Until then, GTA02 is
significantly more free, and GTA04 is a freedom downgrade.

VLR,
SF

P.S. As to your "IMHO unlawful" comment, if some lawmaker decides to
make a law that makes it illegal to breathe, does it mean that we
should all obediently suffocate ourselves?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: USB networking && Win7

[Michael Spacefalcon]

"dmatthews.org"  wrote:

> PuTTY is quite a decent (free as in beer) ssh client for windows

PuTTY is free as in speech too, i.e., it is bona fide free software -
not just free as in beer.  Of course Windows isn't, but we are talking
about PuTTY, right?

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Community] GTA04A5 / Letux 2804

[Michael Spacefalcon]

Dr. H. Nikolaus Schaller  wrote:

> Not everybody is weighting the factor of "freeable down to the modem" equally
> when calculating the relative position of two devices to decide between
> "upgrade" and "downgrade". You have a different weighting than me.

If freedom is not important to you, then you might as well use an
iPhone or the latest Android from Samsung.

As Jim Marrs has said very eloquently in the preface to one of his
books, being free is like being pregnant - either you are, or you
aren't.

> I don't know, but isn't *that* something you should fight against
> instead of modifying
> leaked firmware for a system that never has been locked?

"Modifying leaked firmware" is not an accurate description of what I
am doing.  As you should know full well, I am designing and building
my own Free Plain Phone, and I have chosen to use the same Calypso
chipset as used in the GTA02.  I chose this chipset because it already
exists, because it is known to work exceptionally well, at least in
"dumbphone" applications (I've been using one of my Pirelli phones as
my everyday cellphone since last spring, and I have nothing but praise
for it in terms of battery life, GSM signal strength and call quality),
because all hardware documentation and firmware sources for this
chipset have already been freed, and because I have already amassed a
great deal of experience working with this chipset.

Providing hacking support for Openmoko-made modems is simply a side-
product of my FreeCalypso work: I have chosen to bring my firmware up
on known-working hardware first, so that when I build my own hw and
get to debug it, I will have the benefit of known-working firmware.

Put another way, the free phone community (combination of FreeCalypso
and OsmocomBB projects) has already made great progress with the
Calypso chipset.  Switching to another vendor's chipset on a whim
would be an enormous setback for the project and for the community,
and it is not fair for you to ask that of us - here I am referring to
the "you should be working on this instead of that" argument in your
comment.

> So your claim of "GTA02 is 100% freeable and GTA04 is not" is only based on
> your disinterest to work on solutions?

I am working on solutions, but the problem I have chosen to solve is
different from yours.  Some people, such as me, simply want a good
working cellphone, a device for making and receiving phone calls on
the go - and we want this cellphone to be free as in 100% owned and
controlled by the user.  If the objective is to have a plain phone,
rather than a mobile computer, a device consisting of just one baseband
processor, without an extra application processor, is a technically
superior solution for the problem at hand: greater battery life, less
unnecessary complexity, fewer points of failure.  And the existence of
the Calypso chipset makes it possible for such a simple and efficient
"dumbphone" to also be 100% free by virtue of the user owning and
controlling the complete firmware.

Then there are those people who do want their pocket-resident device
to be a computer complete with an OS like GNU/Linux, rather than just
a phone - but some of those people would also want that device to be
100% free including the telephony processor - and not just "half-free"
aka "half-pregnant".  For this class of users, the best currently
extant device is the GTA02, made by Openmoko - not your GTA04, and not
my dumbphone either.

Yes, there is the problem of these devices no longer being made - but
instead of solving this problem by building a new device that would be
as near-identical to the GTA02 as possible, including the Calypso
(just like how I seek to copy the Pirelli DP-L10 as closely to verbatim
as possible), you are making it worse by *actively destroying* the
remaining stock of Openmoko phones!

Hence we will likely always be fighting on opposite sides.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Community] GTA04A5 / Letux 2804

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> Please can you save me from reading those walls of text filled with [...]

Thinking about it more, I realize that my initial post in this thread
was more inflammatory than necessary.  So I do apologize for posting
that on an emotional impulse without thinking some more first.  In
retrospect, perhaps my initial post in this thread would have been
better worded like this:

Dr. H. Nikolaus Schaller  wrote:

> So please think again if you want to upgrade your GTA02 with a GTA04A5 board.

Please understand that some people may find the word "upgrade" in this
context to be objectionable - it is a matter of personal opinion and
different choice of emphasis as to which device (GTA02 or GTA04) is
"better".  Perhaps instead of calling the conversion an "upgrade", it
could be called a "sidegrade", or just simply use the neutral word
"convert"?

And for those who do choose to convert their GTA02s into GTA04s,
please be considerate of others in the community who may see the GTA02
as having more value, and please try to do the following simple
gestures:

* When removing the original GTA02 motherboard, please exercise due
  care and caution to not damage it in the process - please do NOT
  treat it as a throw-away item;

* If you no longer want that original GTA02 board, please do not
  discard it, and do not subject it to any treatment (such as "recycle")
  that would destroy the ability to use it for its original purpose.
  Instead please offer it to others who may have more appreciation for
  its original functionality.

* When storing or shipping that GTA02 board for the benefit of other
  community members who may view it as being better than GTA04, please
  observe the full precautions for handling delicate and sensitive
  electronic components, including ESD protection.

--

Would the above have been better?

Aside from that, there are only two points in Nikolaus' last post
which I feel a need to respond to:

> And if you encrypt the whole communication path yourself, why do you care
> what the modem is doing?

Because there are many kinds of bugs which have nothing to do with
privacy/security issues - plain old bugs which cause the device to
simply not work under certain circumstances.  I have encountered more
than my share of such bugs in products of every kind, cellphones and
modems being no exception (although none in Om's firmware so far), and
I highly value the ability to diagnose and fix such bugs myself when
and if I get bitten by one.

> No. If you fight for freeing the Qualcomm modem you will satisfy both
> sides: Your 100% freedom and a device that can be produced as
> many as you need - and has higher data rates and a better processor.

Of course it would wonderful for all kinds of reasons to have a free
modem that can connect to UMTS networks in addition to GSM, and can
make use of mobile data services at EDGE or even 3G speeds rather than
just plain GPRS.

But given a choice between (a) continuing my current FreeCalypso work
and producing a 100% free GSM-only phone/modem in a foreseeable time
frame with 100% certainty or (b) abandoning this work and venturing
into the completely unknown territory of baseband chipsets from other
vendors, with nowhere near the guarantee of success in the near future
like we have with the Calypso, I feel that (a) is a much more sensible
choice for a developer in my position, and I suspect that at least
some people on this list would agree with me on this question.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

CSD calls from Neo Freerunner

[Michael Spacefalcon]

For those who don't know what CSD is:

http://en.wikipedia.org/wiki/Circuit_Switched_Data

Here is an AT command session log of me making a CSD call from my
GTA02 on T-Mobile USA:

at+cgmm
+CGMM: "Neo1973 GTA02"

OK
at+cgmr
+CGMR: "FreeCalypso leo2moko port"

OK
at+cops?
+COPS: 0,0,"T-Mobile"

OK
atd13034944774
CONNECT

National Institute of Standards and Technology
Telephone Time Service, Generator 1b
Enter the question mark character for HELP
D  L
 MJD  YR MO DA HH MM SS ST S UT1 msADV 

56677 14-01-20 05:30:54 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:30:55 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:30:56 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:30:57 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:30:58 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:30:59 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:00 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:01 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:02 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:03 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:04 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:05 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:06 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:07 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:08 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:09 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:10 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:11 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:12 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:13 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:14 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:15 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:16 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:17 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:18 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:19 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:20 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:21 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:22 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:23 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:24 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:25 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:26 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:27 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:28 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:29 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:30 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:31 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:32 00 0 -.1 045.0 UTC(NIST) *
56677 14-01-20 05:31:33 00 0 -.1 045.0 UTC(NIST) *
NO CARRIER

-- end of log --

The number I dialed in this test is the Automated Computer Time Service
provided by the National Institute of Standards and Technology:

http://www.nist.gov/pml/div688/grp40/acts.cfm

Note how the above web page says, in part: "Digital modems, such as
[...] wireless modems, cannot synchronize using ACTS."  Well, the log
above clearly shows that they are wrong, at least in the case of
high-quality wireless modems like Calypso. :-)

CSD calls may be placed from a GSM mobile either to a land line or to
another mobile.  (I don't know if it's possible to establish a CSD
connection from a land line to a mobile.)  When placing a CSD call to
a land line, one can connect to a traditional dial-up modem on the
receiving end - that's how I connected to ACTS, and if you've got your
own UNIX etc server at home with an old-fashioned modem on a land
line, it is really neat to be able to connect to it from anywhere in
the world via CSD, *bypassing the Internet*!

When you place a CSD call to another mobile, the network tells the
latter that it is a CSD call rather than voice.  If you have a GTA02,
you can have some fun by testing how various other mobile phones react
to incoming CSD calls: just have your FR dial a CSD call to the number
belonging to some "standard" cellphone (dumb or smart), running
"standard" proprietary fw, and see how the latter reacts to receiving
such an unusual call. :-)  To dial a CSD call, just omit the ending
';' from the ATD command you would normally use to dial an ordinary
voice call - see my log above.

But not all modems are created equal.  I've got a Huawei E303 3G modem
in the USB stick form factor to play with, and it appears that this
modem's fw does not support CSD at all.  After doing the usb_modeswitch
voodoo typically needed for these USB 3G modems (usually automated via
udev rules, but I had to install an updated usb_modeswitch package on
my Slackware 13.37 laptop), the modem shows up as a bunch of
/dev/ttyUSBx devices, supported by the "option" kernel module - hence
I wonder if it's anything like the modem in the GTA04.  /dev/ttyUSB0
presents an AT command interface, and the following observations can
be made from the latter:

* One can dial voice calls with ATD; - makes the phone ring on
  the other end; upon answering that call one hears noise - the modem
  must be implementing some way to pass digital audio over USB, which
  is not b

Re: GTA04A5 / Letux 2804

[Michael Spacefalcon]

Stefan Monnier  wrote:

> There are tradeoffs everywhere.  I think that having a 100% free
> firmware for the cell-phone part is really great.  Having an up to date
> "smartphone" that runs Free Software is also great.

Hypothetically speaking, if someone would like to have a device in the
Neo FR form factor that combines a FreeCalypso modem with an "up to
date" AP (application processor) subsystem like that in the GTA04,
there is nothing to stop you (that's an abstract "you", not directed
at anyone in particular) from building such a hybrid device.  Calypso
and its companion chips are still available on the Chinese surplus
market; the 100 chipsets I bought some months ago most certainly
weren't their last.

But I doubt that someone would want such a device badly enough to
invest the massive amount of time, effort and money such a project
would require.  I suspect that I may be the only person crazy enough
to actually (want to) build a new phone (or a mobile device of any
kind) based on the ancient Calypso, but it just so happens that I want
a "dumbphone" rather than a "smartphone" (or "mobile computer" or
whatever you want to call it) in my pocket, and naturally I'll be
building the device which I would want to use myself...

Oh well - when I do build that "dumbphone" for my own personal use and
enjoyment, it will also have a side effect of a known-working Calypso
reference design (quad-band!) becoming available for anyone to reuse,
so at that time (probably in a few years) we can look into combining
this FreeCalypso modem with something like Neo900 for the AP subsystem.

> I see no reason why one project should feel like the other is a threat.

It's the destruction of GTA02s entailed in the process of making GTA04s
that sets me off.  Some months ago (or was it a year or two ago?)
someone here posted about how he wanted to use GTA02 motherboards as
wall decorations or somesuch - now THAT kind of waste should be
criminally punishable!  If you feel that your Openmoko-made
case+LCD+misc set would serve you better with a GTA04 mobo inside,
and you don't see value in the GTA02 mobo, then please pass that old
mobo to someone else who would appreciate it enough to 3D-print a new
case for it or whatever, rather than waste it.

> BTW, one issue with Calypso is that as the proportion of non-3G phones in
> use decreases, coverage for non-3G phones is going down.  Maybe it's not
> yet a problem, but it's only a question of time.

Yes, that is a very major threat.  Fortunately it hasn't happened yet,
at least not in my part of the world.  I use a Calypso-based Pirelli
DP-L10 as my daily phone, I roam all over Southern California (from
Los Angeles to the Mexican border), and I have yet to encounter even
one spot with poor or no GSM coverage.  And that's despite this phone
(like all of my other GSM phones) supporting only the primary USA band
at 1900 MHz and not secondary band at 850 MHz!  (The latter is a
relatively new addition, a spectrum reallocation from AMPS which was
still in service as late as 2008, at least according to Wikipedia.)

But when the major commercial operators do shut down their GSM
services, we would have to set up our own, squatting on "unused"
frequencies like pirate radio broadcasters do...

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: testing the free calypso software

[Michael Spacefalcon]

David Matthews  wrote:

> I've done a bit of work, which I hope will encourage other people to give it
> a test. There is a full write up at http://winterveldt.co.za/leo2moko.html,
> with links to a distro I've prepared for the sole purpose of flashing your
> freerunner's calypso - either with leo2moko or moko11 firmware.

Thanks, David!

And just in time, I've got a new release of loadtools out:

ftp://ifctfvax.Harhan.ORG/pub/GSM/FreeCalypso/loadtools-r2.tar.bz2

Changes from loadtools-r1 to loadtools-r2:

* A flash ID check has been implemented in fc-loadtool, invoked automatically
  before doing any erase or program operations, or explicitly at any time with
  the flash info command.  This check ensures that the type of flash chip in
  the target GSM device is the same as what loadtool thinks it is, based on the
  hardware parameters file.

* fc-xram command line syntax changed slightly in order to support immediate
  passing of the serial line to rvinterf/rvtdump.

* Miscellaneous minor polish.

Note that because the uSD card distro which David just put together
does not include loadtools internally (requires the use of the serial
cable instead, with loadtools running on your PC), nothing in that
distro became outdated as a result of this new loadtools release.  Just
download the new loadtools and build them on your GNU/Linux PC.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: testing the free calypso software

[Michael Spacefalcon]

Giacomo 'giotti' Mariani  wrote:

> Hi David, Michael, all,
> thanks a lot for your work, it is very emotional to see this
> "little" piece of freedom rising!

You're welcome. :-)

> I'm still not brave enough to risk my only (I mean in all my life time
> so far) mobile phone, but I will soon ;-)

There is nothing at risk really - if the leo2moko firmware doesn't
work for you for some reason, you can always revert to moko11, using
either our flashing tools or the "official" moko11 flasher.

Even in the case of the FFS with the RF calibration values etc, there
is absolutely no danger of corrupting this FFS if you issue loadtool
commands exactly per the instructions.  Saving a backup copy of the
FFS sectors is a precaution just in case you erase or write to the
wrong part of the flash.  If you have this backup saved, you can
always restore it.

In the absolute worst case scenario imaginable, if someone does lose
their RF calibration values and has no backup copy anywhere, you
should be able to send your FR to some lab to get it recalibrated.  I
don't offer such service currently because I haven't acquired the
necessary RF test equipment and process knowledge yet, but when I
start building my own Calypso phones, I will obviously need to get
them calibrated, and once we have the knowledge and the setup to do
it, Harhan Engineering Co. will also offer recalibration services to
Freerunner users.

> By the way, I think that your work, with the right notes about being
> experimental and so on of course, should also be in the official wiki.

As much as I would love to see it happen, I doubt that the powers
controlling that wiki will ever allow it.

> A small question about the procedure you describe: is the t191 cable
> only needed to backup the "vital parts of the calypso memory" or also to
> write the new firmware?

Both if you use the uSD system which David just released; neither if
you get FreeCalypso loadtools running on the Linux processor of your
FR like Norayr did.

Oh, and just to be clear as to exactly what the "vital parts of the
calypso memory" in question are: the only entity that lives in the GSM
modem's flash memory besides the firmware image (which is exactly the
same in a device as it is on the web at the official download URL) is
the flash file system, or FFS.  The FFS in Openmoko's modems takes up
exactly 448 KiB of flash space (64 KiB x 7); per TI's design it is
structured like a UNIX file system (directory tree, forward-slash-
separated pathnames, case-sensitive etc) and stores a bunch of things:

* The modem's IMEI;
* RF calibration values;
* ID strings which say that your device is a "Neo1973 GTA02" made by
  "FIC/OpenMoko" - Om's late firmwares (moko10/11) appear to not use
  these strings from FFS (fw returns hard-coded strings instead), but
  my leo2moko fw returns the strings from FFS following TI's canon;

* Some dynamic data written into the FFS (the fw always "mounts" the
  FFS with R/W access, TI's fw has no concept of a "read-only mount"
  for the FFS) during the operational lifetime of the modem: history
  of what SIM cards this modem saw, dialed/received/missed calls, and
  probably received SMS as well - I have yet to play with the latter.

Just this weekend I wrote a new utility for examining FFS images read
out of TI-based GSM devices (our beloved FR being one of them); this
new tiffs utility (with mokoffs and pirffs wrappers) supercedes my
earlier mpffs-* tools I wrote and released last summer.  The new
utility allows one to list and extract not only the "current" file
content of the FFS (i.e., what one sees when "mounting" the file
system normally), but also those files which have been logically
deleted or overwritten, but not yet reclaimed, i.e., not truly gone.
Hence the tool can be used to do forensics on Freerunner modems - I
suspect many of you probably never thought about the modem's flash
memory remembering the history of what SIM cards you had in there,
what numbers you called or received calls from, and probably your SMS
exchanges too...

The just-described utility currently lives in the freecalypso-sw tree
on Bitbucket:

http://lists.openmoko.org/pipermail/community/2013-August/068850.html

Look in the ffstools directory.  Now I need to write some more
documentation and make a release tarball for the FTP site.  Stay
tuned; I'll post here when I make that release.

> By the way, yes, a distro able to flash and back-up everything without
> additional cables would be very appreciated.

Of course...  Shortage of qualified volunteer manpower is our only
limit.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: testing the free calypso software

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> That's a bold misconception. OM wiki isn't censored, it just gets cleaned of
> SPAM and obviously incorrect AND hazardous info, like e.g. somebody suggesting
> to run wear tests against NAND to verify its formatting.

But I still think that it would be better for FreeCalypso to have its
own "identity" that is separate and independent from Openmoko, i.e.,
its own mailing list, its own website (wikified or otherwise) etc.

As a result of my involvement on another mailing list (on a topic that
is totally unrelated to mobile phones), I became aware of this document
from the ISO Technical Committee on terminology:

http://www.ucolick.org/~sla/leapsecs/ISOTC37toITURA.pdf

Simply put, the authors of the above statement from ISO TC37 emphasize
the importance of using terms which have a 1:1 mapping to the concepts
they are meant to stand for, i.e., 1 concept = 1 term.

As you and others have made it perfectly clear on numerous occasions,
the term "Openmoko" was never meant to stand for the concept of "free
(or open) GSM modem"; instead this term (according to you and other
high-standing community members, which I obviously am not) stands for
a different concept, namely that of "a free application processor with
a black box modem attached as a peripheral".  And because the name
"Openmoko" rightfully belongs to you and your former boss Sean Moss-
Pultz, it is not my place to try to change its meaning.

(In fact, Dr. HNS is effectively invoking this term=concept equivalence
 of "Openmoko" = "free AP with a black box modem as a peripheral" when
 he asserts the legitimacy of his GTA04 product as a non-downgrade
 successor to Om products.)

But I am working with a completely different concept, namely that of a
free GSM device, be it a modem or a complete "dumbphone".  And because
it is an entirely different concept than that which is mapped by the
term "Openmoko", by the principles of ISO TC37 my new concept calls
for a new term for referring to it.  Hence the name FreeCalypso was
born: I came up with this name about this time last year, following
exactly the line of reasoning I've just outlined, and my first public
announcement of FreeCalypso was this one:

http://lists.openmoko.org/pipermail/community/2013-February/068270.html

The FreeCalypso project is very much in need of its own web/list home
under the ifctf.org domain name, which currently features only an FTP
site.  My desire is to create a lists.ifctf.org host first, hosting
Mailman mailing lists exactly like Openmoko and almost all FOSS
projects and technical communities have nowadays - anything else would
be seen as substandard, and therefore unattractive to me.  A website
for FreeCalypso (wikified or not) can be created later, but my first
focus is on the lists host on which we can create a proper new mailing
list for FreeCalypso.

And because I already have my own physical "datacenter" on my own
physical turf, I *will not* buy hosting from someone else who would
ask me to agree to their TOS or AUP or the like - hence my only option
is to use my own physical hardware.  A SAS JBOD chassis is already on
its way to me from ebay, already paid for; the drives are next - as
soon as I gather the cash to buy 6 SAS drives of some non-laughable
capacity (I refuse to use SATA, and I desire 6 drives to start with
for a raidz2 ZFS configuration - I'll be running OpenSXCE), I will
finally have the necessary hw, and will begin the setup/configuration
work.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: testing the free calypso software

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> If someone has no backup of calibration data, can she use calibration
> data from other phone?
> Then we can send our data to that person. Or it won't work this way?
> I probably don't understand it well.

joerg Reisenweber  followed up:

> Not recommended and not entirely correct procedure but nevertheless should
> sort of work, yes. You might want to edit the IMEI to what yours been, before
> (or after) you flash that alien calib data.

I still have a lot of learning ahead of me in this department, but per
my current understanding, the purpose of RF calibration is to measure
those physical variations which exist from one produced unit to the
next, and to record these measurements (or some values derived from
the measurements) in per-device non-volatile memory, such that the
modem firmware can then take account of and compensate for these per-
device differences.  I'm guessing it has something to do with non-
linearity in the amplifiers, process variations in the ADCs and DACs,
temperature sensitivities etc.  This document from TI attempts to
explain some of it:

ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf

So my current understanding is that at least some of the calibration
values will differ from one unit to the next, and I reason that taking
the values from one unit and using them on a different unit may cause
some poor RF performance, or out-of-spec operation in terms of Tx
power levels perhaps.  I have no way of knowing just how much
difference there is between one GTA02 and the next, and hence what
would the magnitude of ill effects from a calibration transplant be.

A good experiment would be to compare the calibration values (properly
programmed at the factory, presumably) read out of different GTA02
units.  The flash dump from my GTA02 can be found here:

ftp://ftp.ifctf.org/pub/GSM/GTA02/flashdump.bin

I made that dump from my GTA02 back in 2013-04, and put it on the FTP
site in 2013-07, long before the recent project breakthroughs.  The
first 0x225594 bytes of that flash image (just under 2.25 MiB) contain
the moko10 fw image (what my FR came with); the interesting part (the
FFS) starts at offset 0x38.

Using the new tiffs/mokoffs tools I just wrote (get them from the Hg
repository on Bitbucket or wait for my coming-soon tarball release),
we can examine the content in this FFS image.  Let's start with the
basic vital stats:

$ mokoffs -f flashdump.bin blkhdr
Block   0: age , type/status AB
Block   1: age , type/status BD
Block   2: age , type/status BD
Block   3: age , type/status BD
Block   4: age , type/status BD
Block   5: age , type/status BD
Block   6: age , type/status BF
$ mokoffs -f flashdump.bin fsinfo
Active inode block (AB) is block #0
Root inode is #1
Root inode (format) name: /ffs-root

(mokoffs is a trivial wrapper around tiffs that spares the user from
 having to specify the 64x7 FFS organization argument every time, and
 -f means that one is looking at a complete flash dump, rather than
 just the FFS sectors - hence the tool needs to go to offset 0x38.)

Listing the actual content is easy too:

$ mokoffs -f flashdump.bin ls
fr4096 /.journal
d  /gsm
d  /gsm/rf
d  /gsm/rf/tx
f  512 /gsm/rf/tx/ramps.900
f  128 /gsm/rf/tx/levels.900
f  128 /gsm/rf/tx/calchan.900
f  512 /gsm/rf/tx/ramps.1800
f  128 /gsm/rf/tx/levels.1800
f  128 /gsm/rf/tx/calchan.1800
f  512 /gsm/rf/tx/ramps.850
f  128 /gsm/rf/tx/levels.850
f  128 /gsm/rf/tx/calchan.850
f  512 /gsm/rf/tx/ramps.1900
f  128 /gsm/rf/tx/levels.1900
f  128 /gsm/rf/tx/calchan.1900
d  /gsm/rf/rx
f   40 /gsm/rf/rx/calchan.900
f8 /gsm/rf/rx/agcparams.900
f   40 /gsm/rf/rx/calchan.1800
f8 /gsm/rf/rx/agcparams.1800
f   40 /gsm/rf/rx/calchan.850
f8 /gsm/rf/rx/agcparams.850
f   40 /gsm/rf/rx/calchan.1900
f8 /gsm/rf/rx/agcparams.1900
f2 /gsm/rf/afcdac
f2 /gsm/rf/stdmap
f   24 /gsm/rf/afcparams
d  /gsm/com
f   16 /gsm/com/rfcap
d  /gsm/l3
f  144 /gsm/l3/rr_white_list
f  256 /gsm/l3/rr_black_list
f   44 /gsm/l3/eplmn
d  /gsm/cops
f   16 /gsm/cops/operimsi
d  /pcm
f   12 /pcm/CGMI
f   13 /pcm/CGMM
f   14 /pcm/CGMR
f8 /pcm/IMEI
f9 /pcm/IMSI
f   23 /pcm/LRN
f   21 /pcm/LMN
f   22 /pcm/LDN
d  /sys
d  /mmi
d  /vos
d  /vos/vm
d  /vos/vrm
d  /vos/vrp
d  /var
d  /var/log
d  /var/tst
d  /var/dbg
f 3152 /var/dbg/dar
d  /Test
f4 /Test/Teststate.bin
f  196 /Test/Production.bin
d  /aud
f  164 /aud/para0.cfg

Most of the above should be self-explanatory; the numbers shown before
the pathname for files ('f' as opposed to 'd') are the lengths of each
file in bytes.  The files containing the RF calibration values we are
currently discus

TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Hello project followers,

The tool for examining flash file system images read out of TI-based
GSM devices (which include Openmoko GTA0x modems) has just been
released:

ftp://ftp.ifctf.org/pub/FreeCalypso/tiffs-iva-r1.tar.bz2

Aside from the naming and packaging change, the main functional
difference between the current tool and the offering I put out last
summer (mpffs-tools-r1.tar.bz2 in the same directory) is the addition
of the lsino and catino commands, which enable "forensic" examination
of FFS change history and the old content of deleted/overwritten files.

For some examples of what one can do with this tool, see my previous
post:

http://lists.openmoko.org/pipermail/community/2014-January/069265.html

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Giacomo 'giotti' Mariani  wrote:

> Hi Comrade,
> I can't find the FreeCalypso directory at
>
> $ ftp  ifctfvax.Harhan.ORG

For a moment I was wondering "why are people going to that old FTP
site and not the new one at ftp.ifctf.org?", but then I realized that
I posted a bogus URL for loadtools-r2.tar.bz2...  My apologies for
that mistake.

> Well... I found the directory and the two files I was looking for:
>
> wget ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r2.tar.bz2
> wget ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/tiffs-iva-r1.tar.bz2

Yes, these are the correct URLs for the correct FreeCalypso FTP site;
sorry about my earlier mistake.

> Everything looks fine, but it does not work:
>
> # fc-loadtool -h gta02 /dev/ttySAC0
> Sending beacons to /dev/ttySAC0
> Toggling /sys/bus/platform/devices/gta02-pm-gsm.0/power_on
> Got beacon response, attempting download
>  Sending image payload
> Block #0: No response to  #

The above looks like an effect of some other process competing with
fc-loadtool for the /dev/ttySAC0 serial channel to the modem, or maybe
even for the modem power control.  Did you say you are running Qtmoko?
Do you know how to stop whatever processes normally access the modem
in that distro?  (I certainly don't, as I've never used any of the
"normal" distros on my FR, only the minimal Buildroot environment I
hacked together for playing with the modem.)

It looks like you will need to convince the maintainer of Qtmoko to
tell you (and the rest of us) how to get his popular distro working
with FreeCalypso tools.  Or you could try the special distro which
David Matthews put together - the 2nd version which works without the
special cable.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Calypso/audio interaction

[Michael Spacefalcon]

David Matthews  wrote:

> Making a general purpose distro such as Qtmoko loadtools capable is likely to
> be a non starter.

I agree in general, but see below for some finer points.

> it's likely to be advisable to rip out all the audio stuff also. 

That's where I need to provide some clarification.  The issue here is
that (as David discovered experimentally) the combination of
{Neo FR loudspeaker enabled} + {headset jack Calypso access enabled}
is rather unkind on the loudspeaker, and on the operator's ears.
(Look at the audio circuits in the public GTA02 schematics to see why.)
However, the take-away should NOT be "all audio is bad when doing any
Calypso hacking" - instead it can be fine-grained:

1. One needs to ensure that the loudspeaker amplifier is off when
   using loadtools via the external serial cable method.  But the
   state of the audio subsystem absolutely doesn't matter if you are
   running loadtools from the AP and are *not* enabling the "download"
   channel via /sys dingling.

2. In some advanced debug scenarios (and I do mean advanced, as in you
   actually digging in / debugging the guts of the GSM protocol stack,
   and not just flashing prebuilt images from my FTP site) it can
   actually be quite useful to have the headset jack Calypso access
   channel enabled (with the cable going to the FC developer's laptop
   running rvtdump/rvinterf/fc-tmsh etc) while the modem is running
   "normally", even during a phone call.

If you need to debug the Calypso via TI's RVT/ETM interface (presented
on the 2nd UART wired to the headset jack on the Neo) *while the modem
is making a phone call*, it is possible to have this "download" (or
debug) serial channel enabled while audio is also enabled at the same
time.  The trick is that in this scenario, the audio must be routed to
the earpiece speaker, and *not* to the loudspeaker, and most certainly
not in the "analog headset" mode.

This latter scenario is where FreeCalypso tools do need to play nicely
with Qtmoko/SHR/etc - it would be very useful to observe the RVT/L1/G23
debug output from the modem on the external serial port (or to send
active ETM commands to it via the same interface) while it is being
driven "normally" by Qtmoko/SHR/etc.

> Better idea - use the "special distro" (I used Qtmoko as a starting point)
> with or without the cable - or else build your own single purpose
> boot_and_run_from_sdcard system.
>
> http://winterveldt.co.za/leo2moko-p2.html

Yes, for loadtools operations (saving FFS dumps, flashing different
firmwares, coming-soon "in vivo" FFS/IMEI editing kit) David's offering
seems like a better choice.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Fun with IMEI (was testing the free calypso software)

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> Does anyone know what will happen in a cellular network where there is
> more than one device has the same IMEI. In other words, if we all
> could change our IMEI numbers, and use one imaginary number, are there
> technical reasons for network to not work.

joerg Reisenweber  responded:

: no technical but organizational. Usually that IMEI gets an instant ban, and
: a fat bold red alarm logline in carrier's network logs.

Yup, if all of us were to use the same IMEI number, it would be far
too easy for our enemies to ban that one single number.

> I mean, MAC address is used on a physical layer, so if two network
> cards connected to the same switch have same MAC adresses, network
> won't work. I guess switch will down both ports connected to those
> devices.

The analogy between IMEIs and Ethernet MAC addresses is a good one
from a manufacturing/management perspective, but not in terms of
network protocol usage.  Unlike MAC addresses, IMEIs are not used for
any kind of addressing or routing anywhere in the network, only as a
"management" identifier that is unnecessary in the strict technical
sense.

But from the perspective of a device manufacturer (which I will become
soon, hopefully), IMEIs are just like Ethernet MAC addresses: the
nominal requirement is that each be world-unique for all time (a rule
that gets broken in reality with both MAC addresses and IMEIs), a
manufacturer has to buy a range (supposedly "fresh" and unused) from a
central registry, and then number individual produced units out of
that range.

> But I don't know how IMEI's work. Are they technically necessary so
> that 3G/gsm network can be operational, or they are only used to
> identify (and track) customers by devices?

The latter.

Before everyone starts changing their IMEIs just for the heck of it,
let's analyze *rationally* how tracking works - or rather, what is the
total set of data elements available to carriers (and their gov't
partners etc) for tracking users, and how these data elements inter-
relate.

If you like maintaining a long-term-constant phone number at which
your family and friends can reach you (i.e., the whole purpose for
having a cellphone, at least for me), and you have a long-term-stable
SIM card associated with that long-term-constant phone number, then it
doesn't really matter if your IMEI is also constant or if you send the
output of a PRNG (or even a TRNG) to the network as your IMEISV every
time your phone/modem fw does the "register" operation.  The constant
SIM card with its IMSI, as well as the associated MSISDN (phone number
for your family and friends to call you at), is what tells the network
that "you" are still the same "you", no matter what device you use or
what IMEISV it transmits.  Yes, you can deregister from the network,
then re-register with a different IMEI, making it look like you turned
your phone off, moved your SIM card to another phone, then came back
online with the latter - but what would be the point?

Instead, there are only two scenarios I can think of in which it would
make sense to change the IMEI of a GSM device:

1. If you really want to "disappear w/o trace", such that you discard
   your old SIM, get a new SIM (prepaid, presumably) with a different
   phone number (and deliberately make yourself unreachable at your
   old one), and you want to make it look like the user of the new SIM
   is a different person from the user of the old SIM - in this case
   the same IMEI would indeed give you away, so you might want to
   change it in this case.

If the above applies to you (and it does *not* apply to me, as changing
phone numbers constantly would defeat the whole purpose of a cellphone
for me), then you need to be careful to change your IMEI *at exactly
the same time* when you change your SIM - if there is any time skew
between these two changes, such that a network sees {old IMEI, new SIM}
or {new IMEI, old SIM} at any time, even just once, your anonymity
effort will be instantly brought to naught!  If you want to do this, I
would recommend pulling your old SIM out first, throwing it away, then
doing the IMEI changing operation on the SIM-less modem, and then
finally inserting your new SIM.

2. Changing one's IMEI may be necessary if your "legitimate" IMEI from
   the manufacturer of your GSM device has been wrongfully banned or
   blocked by some GSM network you wish to use, and you need to use
   some non-blocked IMEI in order to get on the network.

The wrongful ban scenario is particularly frightening when applied to
whole classes of devices, rather than individual units.  The first 8
digits of the IMEI comprise the Type Allocation Code (TAC), which is
supposed to be allocated per each device type.  Hence if all
manufacturers involved played by the rules (of which I have no
knowledge), then every IMEI beginning with 35278901 is supposed to be
a Pirelli DP-L10, every IMEI beginning with 35465101 is supposed to be
an Openmoko GTA02, and so

Re: TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Giacomo 'giotti' Mariani  wrote:

> It's been easier than expected:
>
> root@neo:~# . /opt/qtmoko/qpe.env
>
> root@neo:/root# /etc/init.d/qtmoko-neo stop
> root@neo:/mnt/nfs/root/ModemFFS/Backup# fc-loadtool -h gta02 /dev/ttySAC0
> [...]
> root@neo:/mnt/nfs/root/ModemFFS/Backup# /etc/init.d/qtmoko-neo start

Nice. :-)

> Now I'm looking at it with mokoffs :-)

Because my sample size so far has been 1, I would like to know how the
FFS content on other FR units differs from mine.  I would appreciate
it if you could do a mokoffs xtr on your FFS image, then do the same
on the image from my FR (from my FTP site, URL posted earlier), and
then let me know what diff -r between the two extracted trees shows.

David Matthews  wrote:

> That's interesting - and it worked without a cacophony as accompaniment?

I repeat: if one does not do
'echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download'
which is not necessary when running loadtools from the AP (but is
necessary for the cable method), then the cacophony cannot occur.

> I just tried to confirm this myself; using the cable method it does not work
> for me on Qtmoko 54. I had the same problem using SHR and following the
> instructions that Norayr posted, but again using a cable rather than running
> loadtools on the phone as he did.

Have you ever tried troubleshooting it like I suggested earlier?  I.e.,
take loadtools out of the equation for a moment, run a standard
terminal emulator program like minicom on the PC end of the cable, then
try echo'ing '1' and '0' into the 'power_on' node in sysfs and see if
the RVT output appears/disappears in response?

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Fun with IMEI (was testing the free calypso software)

[Michael Spacefalcon]

=?UTF-8?B?S2FpIEzDvGtl?=  wrote:

> thanks to the recent activies I also thought about IMEI yesterday
> evening and it was fun that other's also did. Setting IMEI would still
> be a nice feature.

A general purpose FFS editing kit for GTA01/02 modems, which will
include the ability to set the IMEISV to whatever you like, is coming
soon - be patient.  (Or if you are impatient, feel free to follow the
project as it happens in the Mercurial repository on Bitbucket.)

Yes, I said IMEISV, not just IMEI - if you don't know the difference,
read it up on Wikipedia etc.  Even though the file in TI's device file
system is named /pcm/IMEI (at least on older modems like Om's which
don't use the so-called "IMEI protection"), the number it actually
stores is the IMEISV.  The file is (or should be) exactly 8 bytes long,
storing the 16 digits of IMEISV, two digits per byte, and the GSM
protocol stack into which this number is fed (by way of a function
called cl_get_imeisv(), grep for it in the leo2moko source) treats the
last two digits (stored in the last byte) as the SV field, not the
Luhn check digit.

That being said, it looks like both Openmoko/FIC and Pirelli/Foxconn
set the SV field of their factory-programmed IMEISV numbers to x0,
where x is the Luhn check digit for the IMEI part, such that one can
"cheat": take the 16-digit IMEISV, drop the last digit, and treat the
remaining 15 digits as if they were the "classic" IMEI.  (Such
"cheating" is what my current leo2moko implementation of the AT+CGSN
command does - I made it match Om's functionality before I realized
that /pcm/IMEI is really IMEISV.)  A more reliable way to retrieve the
complete IMEI information on any TI-based modem is to issue an ATD*#06#
command: it will return a 17-digit number consisting of the 14 digits
of the IMEI proper, the Luhn check digit, and the 2 SV digits.

> In addition it would be interessting for me (in times of surveillance)
> whether silent sms (stealth ping) could be recognized and a report be
> dropped to the mobile phone. Also the change to non-encrypted transfer
> would be a similar event which might occure due to an IMSI catcher, so
> generating a message (SMS?) warning the user would be helpful.

Before we can implement the alerting functions you are asking for, we
need to liberate the GSM protocol stack first.  The current leo2moko
fw has this protocol stack in a bunch of binary object libraries, as
that's what TI provided in the TCS211 ("Leonardo") deliverable.  Full
source forms of closely related versions are available through the
TSM30 and LoCosto leaks though, the latter being more promising - hence
the current FC project plan is to try lifting the g23m* code layers
from the LoCosto version, and see what we get.  But there is a bunch
of other preparatory work that needs to get done before we get to that
point.

> Also: Could the gsm module be made working without a SIM, i.e. just by
> providing the necessary values like IMSI and Ki?

Sure thing, and OsmocomBB already supports such usage.  But where are
you going to get a Ki that is recognized as valid by the GSM network
you wish to use?  And what would the corresponding phone number
(MSISDN) be?

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Giacomo 'giotti' Mariani  wrote:

> Here we are:
> # diff -r michael-ffs my-ffs

Thank you for these diffs; explanation follows inline.

> Binary files michael-ffs/Test/Production.bin and my-ffs/Test/Production.bin
> differ

Yup, expected - if you hexdump this file, you'll see that it contains,
among other things, the non-IMEI "serial number" which Om/FIC assigned
to each Neo unit.

Incidentally, these files under /Test (Production.bin and Teststate.bin)
are neither written nor read by the modem firmware (any version); they
were written by the factory production line and remain as decorative
relics afterward, not actually used by the fw for anything.  (Kind of
like your belly button - serves no real purpose except to remind you
how you came into being. :-)

> Binary files michael-ffs/gsm/cops/operimsi and my-ffs/gsm/cops/operimsi
> differ

This file gets frequently rewritten during normal operation of the
modem; it contains the IMSI read from your SIM card and some other
info I have yet to understand.

Regarding the flash dump on my FTP site, I read it out of my FR's
modem before I put any SIM into it, so whatever IMSI-related info is
in that image, it must be an artifact of testing or whatever by the
manufacturer/distributor/etc.

> Binary files michael-ffs/gsm/l3/rr_white_list and my-ffs/gsm/l3/rr_white_list
> differ

I have yet to learn what these files under /gsm/l3 are for, so I don't
have much to add currently.  However, I do know that these files get
rewritten by the modem quite frequently in normal operation, so they
are definitely in the "dynamic state" category, not factory-programmed
data.

> diff -r michael-ffs/gsm/rf/afcdac my-ffs/gsm/rf/afcdac
> [...]
> Binary files michael-ffs/gsm/rf/tx/levels.900 and my-ffs/gsm/rf/tx/levels.900
> differ

These are the interesting ones: all files under /gsm/rf are calibration
data recorded at the factory and never changed afterward, so the diffs
we are seeing here are the measured physical variations from one
produced unit to the next.

The next natural question here is how great or small these differences
are, i.e., the magnitude.  To answer that, we need to look at the
actual content of these RF calibration files.  They are all binary,
and are read directly into RAM data structures belonging to the Layer1
code in the firmware.  I will give these structures their deserved
scrutiny when I reach the point of deblobbing the L1 code and
integrating it into my gcc-built FC GSM fw - IOW, not yet.

In the meantime, I think it would be a good idea to collect the content
of this /gsm/rf directory subtree from as many Neo units as possible -
understanding the actual magnitude of per-unit differences in these
calibration values would help us provide the best possible recovery
for anyone unlucky enough to lose their FFS, and may also give us an
idea as to what to expect in this department when the time comes to
build new FreeCalypso phones and modems.

Because all files under /gsm/rf are written only on the factory
production line and not afterward, there is no personal information in
there: nothing read from your SIM(s), no history of network connections
or the like, and no IMEI or other identifying numbers, just measurements
of physical process variations.  Therefore, there should be no privacy
problems in publishing this data.

If you would like to contribute your RF calibration data to public
knowledge, you can make a .tar.gz from your extracted /gsm/rf subtree
(just that subtree, don't include any other directories which may
contain private personal info), send it to me, and I'll put it on
ftp.ifctf.org - I'll make a new directory for this calibration
collection.  Oh, and inside that tarball, add a note indicating
whether the unit in question is a GTA01 or a GTA02, and whether it is
the 900+etc or the 850+etc frequency band version.

To repeat: if you choose to do the above, be sure to extract the
content of your FFS with mokoffs xtr and then make a .tar.gz of just
the /gsm/rf subtree - you probably do NOT want to publish your
complete raw flash dump, as there's a lot of personal info that can be
extracted from a complete FFS image.

> Binary files michael-ffs/pcm/IMEI and my-ffs/pcm/IMEI differ

Obvious.

> Binary files michael-ffs/pcm/IMSI and my-ffs/pcm/IMSI differ

Same deal as with /gsm/cops/operimsi seen earlier.

> Binary files michael-ffs/var/dbg/dar and my-ffs/var/dbg/dar differ

This file appears to be rewritten every time the modem boots up.  But
TI's DAR component (Diagnostics And Recovery) is coming up next to be
integrated into the fledging FC GSM fw source, so we will understand
this file very soon. :-)

> Glad to help. I hope this gives you some information :-)

One part which I have yet to learn is how the SMS receiving path works.
It seems to me that when the network delivers an MT (mobile-terminated)
SMS to the mobile, the modem has to store that SMS on its own and
acknowledge receipt to the GSM network before it can pass that SMS to
the applica

IMEI changing kit for GTA02

[Michael Spacefalcon]

Hello fellow freedom lovers,

I have just released the first version of the kit that allows a Neo
Freerunner user to set his/her IMEISV to any value of his/her choice.
Download it here:

ftp://ftp.ifctf.org/pub/GSM/GTA02/ffs-edit-kit-r1.tar.bz2

Operating instructions are inside the tarball.  The way in which this
kit works is completely independent of what firmware version you have
in flash: it can be moko11, leo2moko, or even blank or corrupt flash.
(Just like with fc-loadtool, the chain starts with Calypso's on-die
boot ROM, i.e., the wonderful hardware unbricking feature TI gave us
in this baseband chip, similar in principle to FR's NOR U-Boot which
is extra hardware just for unbricking.)

Please also note that many vendors' "standard" proprietary firmwares
include undocumented AT commands for setting the IMEI, and as my
experiments indicate, moko11 appears to be one of them:

ftp://ftp.ifctf.org/pub/GSM/hacks/imei-hacks-r1.tar.gz

However, I do not recommend using that AT@SC command, as the half-baked
implementation does not make the proper distinction between IMEI and
IMEISV, and the last 16th digit of the complete IMEISV (which is what
the modem actually uses and sends over the air) ends up being set to a
"random" value that is an artifact of the obfuscation scheme.

As an example, the original factory IMEI of the GTA02 I use for FC
development is 35465101-961584-0; the original factory programming of
the complete IMEISV is 35465101-961584-00.  However, if one uses that
AT@SC hack to change it, it is then impossible to revert the complete
IMEISV back to this original setting using the same AT@SC command!  If
one feeds the correct obfuscated AT@SC string for setting
35465101-961584-0, the full IMEISV gets set to 35465101-961584-01
instead of the original factory 35465101-961584-00.

In contrast, the FFS editing kit linked above allows you to set all 16
digits of the IMEISV to whatever you choose; the kit provides the
mechanism and you decide on the policy for what the SV digits should be.

However, considering that those with a desire to play with their IMEIs
would probably find an AT command much more convenient than the rather
cumbersome (albeit powerful) XRAM-agent-based mechanism presented in
my current kit, I plan on making a new version of leo2moko that will
include a new AT command for setting the IMEISV.

I will not be replicating the obfuscated AT@SC command, instead it
will be a different AT command that sets all 16 digits explicitly and
works without any obfuscation.  The syntax I propose is:

AT+SIMEISV="1234567890123456"

If anyone has an argument for a different syntax, please speak up now.

Viva la Revolucion,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: IMEI changing kit for GTA02

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> you recall that single line I actually censored?

http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt

line 60, I assume.

> (Must have been the only time
> in my life I did this) In the changelogs, around moko5 or something.

Considering the time proximity between this hack and the moko5->moko6
change in which you (not you personally, but the company) went backward
from the sensible approach (used in most other TI-based products too)
of storing configuration items in FFS to the non-sensible approach of
hard-coding them in the fw, let me make a guess: the crappy Weendoze-
only host tools for development and production which TI gave you (for
FFS programming in this case) were unreliable, and you were looking
for a way to avoid needing to do any FFS programming through the RVTMUX
interface (TI's official way) at all.  Of course the IMEI is one item
which can't be hard-coded in the fw, and if you didn't want to (or
couldn't) use the "proper" RVT/ETM-based method of programming, then
you had to hack in some other way, such as a special AT command.

But I assume that the issues with TI's production testing and
programming tools must have been solved in time for GTA02A7 mass
production, as my unit came with a /pcm/IMEI (IMEISV really) setting
which cannot be programmed via that AT@SC hack, only via the proper
RVT/ETM channel.

I also find it cute that all mass-produced GTA02 units (at least the 4
that have been liberated so far: mine, David's, Norayr's and Giacomo's)
came with a few files in FFS (/pcm/CGM[IMR]) which are not used by any
of your fw's from moko6 onward, only by moko5 - surely flashing a GTA02
back to moko5 is NOT recommended (I even remember seeing admonitions
somewhere to never do that), yet those files seem to be there just to
support those people who might do that...  Wasn't it your inability to
write these strings into FFS reliably that made you go back to hard-
coding them?

When I made leo2moko from TI's standard Leonardo baseline, I had to
add a bit of extra code to display these CGMI/CGMM strings with some
extra wrapping around them.  If one were to run TI's totally "vanilla"
code on a GTA0x modem with this "MokoFFS" factory programming,
something in their ATI layer gets confused because apparently it
expects the strings to be wrapped in angle brackets, but the strings
featured in /pcm/CGM[IMR] in factory-programmed MokoFFS don't have
those angle brackets.

Oh well, history is what it is.

> It actually been a weird "secret" AT command to change the IMEI, it claimed
> in changelogs that it had some really weird formula to add birthday^5 to old
> IMEI or sth and append that to the new IMEI, for "authentication" - and it
> never worked afaik.

So I assume we are in agreement then that this "secret" AT@SC command
is NOT recommended for use?

Anyone who needs to change their IMEI for some good reason (because
they need to be ultra-anonymous when going from one disposable prepaid
SIM to another, or because they need to use some GSM network that
wrongfully blocks their FR's factory IMEI) should use the kit I have
just published.  This method does work - I've tested it on
T-Mobile USA :-).

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: IMEI changing kit for GTA02

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> I have no idea, I took care about GSM firmware only much later. But I think
> until the point in time when I was able to contract Dieter Spaar for OM, there
< been significantly less knowhow about all that stuff inside OM than what you
> demonstrate here.

Hehe.  It looks like my effective taking of the stewardship of this
modem firmware is not such a bad thing for the community after all. :)
Or at least for what's left of the FR user community...

I wonder though how Dieter acquired that knowhow back in the day - did
he previously work for some other modem or dumbphone manufacturer that
used TI chipsets?  Or maybe even for TI-Berlin (former Condat GmbH) or
somesuch?

> And the whole stuff been even temporarily considered
> lost forever, thanks to reformatting of a laptop HDD (iirc).

Ouch!

> Also see bug # 666 which got fixed in moko5 but evidently the patched lib
> TI provided for that got dropped for no reason in later fw versions,
> until Dieter noticed that and included it again in Moko9-Beta1

Stories like this make me wonder how many other bugs of similar nature
might still be lurking in those closed binary libs.  That is one of
the reasons why I seek to produce a "hybrid" Calypso fw by combining
the RTOS environment / drivers / BSP pieces from the TCS211 source
(the one leo2moko was built from) with the GSM stack source from the
LoCosto find - it will give us a fully functional modem fw without any
binary blobs!

Whoever originally liberated the TCS3.2 (LoCosto) source which I found
at  in 2013-05 (through a Google
search!) is a real hero.  If it wasn't for this leak, the only C source
we would have had for the core GSM stack would have been the TSM30
version from 2003, i.e., a definite backward step from the TCS211
version given in binary form to FIC, Foxconn (Pirelli DP-L10) and a
bunch of others in the 2007 time frame.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Focus of development [was: IMEI changing kit for GTA02]

[Michael Spacefalcon]

openm...@pulster.de (Christoph Pulster) wrote:

> Besides legal issues, I miss the thanks to Michaels effords.

Thanks, I appreciate the change in attitude from this previous post
of yours:

: From: openm...@pulster.de (Christoph Pulster)
: To: community@lists.openmoko.org
: Subject: Re: Building a new totally free phone
: Date: 23 Aug 2013 11:54:00 +0200
:
: > just because something is illegal does NOT automatically mean that
: > it's bad
:
: Just because something is illegal does not prevent it to be crap.
: You are not interested to built helpful hardware, but enjoy your  
: erection being a self-called outlaw. Have fun with it, but no applaus  
: from my side.

For some reason that 2013-08-23 post is not visible in the web archive
at 
- perhaps your use of the word "erection" triggered some filter?

> but concerning technical effords, he was very  
> insistant and pushed it as far as writing a tool for easy change of IMEI  

Just in case it isn't already clear, that IMEI change kit came about
merely as a *side product* from my main work seeking to produce a
better-than-OsmocomBB totally free GSM phone firmware.  In TI's fw
architecture, the actual GSM code runs more or less as an "application"
on top of a quite rich RTOS environment, and getting this RTOS
environment (by which I mean not just Nucleus, but also RiViera, RVT,
FFS, ETM and other components) fully working and fully under our own
control is a prerequisite for tackling the actual GSM code.  This RTOS
environment just happens to include a full-featured Unix-like file
system (TIFFS), so naturally tools are needed to operate on this file
system.

The IMEISV is just one data item stored in TI's GSM device file system,
and because of its "forbidden fruit" status, a lot of people have been
asking for a way to edit it freely, hence it was quite natural to take
several FreeCalypso tools (written for the primary purpose of free GSM
fw development and debugging) and string them together into a very
hacky kit for editing the FFS on GTA01/02 modems.

> without having full access to NDA-infos.

The 4 TI source leaks on which my work is based are TSM30, LoCosto,
MV100 and Sotovik, in the order of discovery/liberation.  The real
thanks go to those who have brought all of these leaks out into the
public - as Comrade Stalin said, the country needs to know its heroes.

But in the case of TIFFS specifically, I didn't have a source for this
fw component until the MV100-0.1.rar find, and believe it or not, I
actually reverse-engineered that FFS format on my own (by staring at
hex dumps of flash read out of my GTA02 and Pirelli phones and
reasoning how one would implement a writable FFS given the physical
constraints of NOR flash) just a few days before I found that MV100
source leak!

Matthias Apitz  wrote:

> I use my GTA02 FR as my daily phone, running a SHR from 2012. I have no
> other cellphone [...]
> i.e. I _highly_ depend on working phone features (call, SMS).
> And IMHO this should be our primary focus for an OpenSource cellphone,

Just in case I haven't already made it fully clear, that is exactly
the focus of my work.  The IMEI change kit was/is merely a byproduct
made by stringing together the tools which were written and are needed
for main GSM fw development.

> because my FR sometimes fails in accepting calls, often fails in
> receiving SMS, not always works up from suspend, the people I call are
> blaming me for my poor voice, etc.

With the current leo2moko firmware, I am quite confident that the GSM
modem in the FR works the way it should, no major flaws.  The fw in
question does have a bunch of binary blobs in it, making it very hard
to modify some things until we deblob it, but even these blobs are in
the form of COFF objects with full symbolic information, parsable with
the objdump utility from GNU Binutils built with the needed patch, so
while having very limited ability to modify them at the present
moment, we can still examine these blobs with a high level of
transparency.  And as you can probably guess, I have already examined
these blobs quite extensively, and hence have a high level of
confidence in the quality of the fw.

So with the modem no longer being the black box which automatically
takes the blame for any and all problems with phone functionality, the
finger of suspicion now points at the Linux application processor
software on the FR.

In my opinion, the problems which reduce the usability of the FR as an
everyday cellphone stem from the unnecessary complexity of the Linux
AP.  If all I want is a cellphone for making and receiving phone calls
(plus SMS), why in the heck should I have to deal with the enormous
extra complexity of a Linux computer built into that phone?

As some may remember, which I first joined this mailing list in the
fall of 2011, just before I got sidetracked for 2y to deal with the
"Closedmoko" muck, my intent was to write a Linux-from-scr

Re: Focus of development [was: IMEI changing kit for GTA02]

[Michael Spacefalcon]

Nick  wrote:

> Any more hints as to what "additional freedom enhancements" you have 
> planned?

* Pirelli DP-L10 has a bunch of extra chips supporting the WiFi/VoIP
  and camera functions, chips for which there are no docs.  I won't be
  using any chips without docs in my design.  The WiFi/VoIP function
  is something I have no interest in at all (thus no plan of providing
  any hw for that), and the first version won't have a camera either.

* The RF front end in my design will be quad-band; Pirelli is tri-band
  (2EU+1US) just like Om.  More GSM bands = freedom to travel to more
  parts of the world with the device.

* I plan on connecting the USB-serial chip (probably CP2102, same as
  Pirelli) to Calypso's MODEM UART, i.e., the more hw-capable out of
  the two.  In the existing Pirelli hw it is connected to the IrDA
  UART, i.e., the less capable one.  I would like to offer both RVTMUX
  and the traditional AT command interface over this USB-serial port,
  and TI's code wants to use the MODEM UART for CSD, not IrDA.
  (Pirelli's fw does not provide an AT command interface, only some
  proprietary i/f for their Weendoze PC software, built on top of TI's
  RVTMUX.)

HTH,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Openmoko's downfall (was changing IMEI)

[Michael Spacefalcon]

openm...@pulster.de (Christoph Pulster) wrote:

> I remember adverts of Openmoko in capitals "100% FREE mobile".
> that this was a false promise comes evident afterwards.

I wonder how many people forked over their $$$ for those expensive
Openmoko phones primarily in the hope that the bloody NDA would get
broken by someone in a year or two, and were utterly disappointed when
that didn't happen.  I am convinced that the number is quite large,
and the only thing that made me stand out is that I *voiced* this
sentiment openly, without beating around the bush.

I am also convinced that the *real* reason why "Openmoko = failure" in
the general public's perception is precisely because of that NDA and
no one having broken it during the years when it mattered the most.

The Freerunner became truly free only on 2013-10-13, some 5y (or is it
6y?) after its introduction and 4y after cessation of production, at
exactly 04:08:54 CEST, the date of this announcement:

http://lists.openmoko.org/pipermail/community/2013-October/069010.html

Prior to that announcement, i.e., at 04:08:53 CEST and for the 6y of
Om community history prior to that, the Unfree-runner was a proprietary
phone no different from anything out of Motorola, Samsung or Apple.

But I'm afraid that the liberation came a little too late: I keep
hearing the number "15k units made and sold" being tossed around, but
of those 15k units, after we subtract those which were cannibalized
for plastic parts to stuff nasty Qualcomm modems into and those which
got repurposed for some non-telephony uses, I suspect that the
remaining ones are probably buried some place deep, forgotten by their
owners who gave up on them when a few years passed after Om's
disbanding, and yet no free GSM firmware emerged.

Oh, and to add a little feminine perspective on the matter, when I
told the Openmoko story ("100% FREE mobile phone! - oh, oops, no, not
the cellphone part") to my lady, her reaction was "it would be like me
saying I am only half-pregnant!"

I would argue that Om's biggest mistake, the one that led to their
downfall, was the silly "half-pregnant" attempt to do it legally.  It
should have been done as a 100% explicitly-illegal black market
operation instead.  Hiring law-abiding Germans to run the show was the
#1 mistake - the operation should have been run by the Chinese/Taiwanese
instead.  Contrary to what has been said, they did NOT "have" to sign
the NDAs as they did - surely if the show were run by Chinese/Taiwanese
without a single German on staff, they could have simply used the warez
floating around that giant country.  (As just one data point, the
TSM30 source - *full source* - was published in 2004, at least 2y
before Om came onto the scene.)  The Calypso etc chips are easily
sourceable on the grey market: some "legit" company buys 100k chipsets
from TI, makes 90k phones, the remaining 10k chipsets sell on the grey
market w/o unnecessary questions.  The physical production of phones
should have been done in some unmarked basement without any "legit"
company attached, so there would be no one to sue, and the distribution
(sales) should have been done through the same channels used to market
and sell alternative medicine products like cocaine and heroin.

But oh well, history is what it is.

> the knowledge about NDA restrictions of GSM components is still today  
> only in some geek's mind.

Huh?  I'm afraid I don't follow what you are saying here.  The GSM
mini-Wikileaks collection at  now has
*everything* related to Calypso and other related chipsets from TI,
probably more than Om ever had.  The documentation for the actual
hardware components has been on my FTP site since the fall of 2011
(downloaded from 52rd.com where it had been available to those who can
navigate in Chinese for much longer), and we now have TI's TCS211 fw
deliverable semi-src no different from the one Om had, if we make the
reasonable assumption that all of TI's chipset customers got identical
or near-identical fw starting point deliverables.

We even have an equivalent TI deliverable (hw docs + fw semi-src) for
their LoCosto chipset (one of Calypso's successors), and while I have
no desire to use LoCosto instead of Calypso (LoCosto has some freedom-
reducing "improvements"), the LoCosto semi-src is something like 95%
real C source (unlike the TCS211/Calypso/Leonardo one on which the
current leo2moko port is based), hence I plan on using chunks of code
from the LoCosto source to replace some of the binary-only libs in the
TCS211 version.

So the liberation part of the FreeCalypso project is now 100% done;
what remains now is the (quite hard) purely technical work of
reintegrating all of the pieces back together to build the fw using
gcc without any Weendoze tools or blobs.

> As long as there are big players like government and companys, a 100%  
> open mobile will never happen. Never.

Of course it will never happen legally, but so what?  We can build it
ille

Re: Openmoko's downfall (was changing IMEI)

[Michael Spacefalcon]

Dr. H. Nikolaus Schaller  wrote:

> You are a Pied Piper of Hamelin.

I don't mind the role.  Check out The Stolen Child, poem/song by
William Butler Yeats - I particularly like this rendition:

http://www.elvendrums.com/cddragon.php

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko's downfall (was changing IMEI)

[Michael Spacefalcon]

Radek Polak  wrote:

> But there are other points of view. E.g. some people expect the phone ring 
> when friends/wife/customer calls.

Yes, that's exactly what I seek out of my cellphone too.  And that is
why I require having the source for all sw/fw involved in this telephony
function, so when it breaks, I can debug and fix it myself, long after
the original manuf has gone bye-bye.

> I had many phones before and 2 phones after 
> (N900 and now Jolla). None of them had any problems with SMS and telephony. 

My experience is different.  Until about a year ago, my true & trusted
phone was Mot V66 (a flip phone which I first got in 2003 if my memory
serves me right).  It mostly worked, but every now and then I would
notice the coverage status LED flashing red instead of green - I would
then open the flip to see what's going on, and the display would read
"Unregistered SIM".  The only way to get it out of that wedged state
was to cycle the power; doing the latter would immediately show
perfectly good coverage with high signal strength - so it is obviously
a case of the fw getting stuck in some wedged state, rather than the
GSM network, although I reason that the triggering cause is likely
some network transient event.  This is on T-Mobile USA, Southern
California, 1900 MHz GSM band.

About a year ago I switched from this Mot V66 to the Calypso-based
Pirelli as my everyday personal phone.  Still running Pirelli's original
proprietary fw for now - getting FreeCalypso into a state where it can
drive a complete "dumbphone" rather than a mere modem is a big project
still in its infancy.  But it is still a freedom increment over the
Mot V66, as now I have a full understanding of the GSM chipset I am
using (the one in the V66 is something unknown to me), and because the
original proprietary fw is TI-based, there are plenty of things I can
poke at with my FC tools.

And guess what, Pirelli's proprietary fw exhibits the same strange
behavior with the phone inexplicably going out of service until
rebooted - but instead of "Unregistered SIM", the LCD simply reads
"GSM no service", just as if I went into a Faraday cage - except that
the GSM signal is perfectly fine, as the phone itself indicates when I
reboot it.  So it is the same case of the fw stuck in some wedged
state.  I don't know if the GTA02 modem running moko11 or leo2moko
suffers from the same bug or not - it manifests rarely enough that one
needs to be using the phone on an everyday basis to catch it.

> Openmoko is different - they never provided SW for reliable phone.
> [...]
> And even 5 years after there is no good kernel for Freerunner.

And why has no one in the community produced such a good kernel in all
these 5 years?  One probable reason is because the brightest and most
talented kernel hackers, those most qualified to produce such a kernel,
have left this "community" in frustration (moved on to other life
interests and pursuits) when no liberated/NDA-broken GSM fw appeared.

2013-10-13 04:08:54 CEST came a little too late, I'm afraid - by that
point all those "best and brightest" have already departed this
"community" for good, doing something else for fun in their lives.

> 2.6.29-rc seems 
> quite stable but the patch against mainline is horrible, besides it's power 
> management is worse then it could be. 2.6.39 has hardly nearly unreproducible 
> problem with resume.
>
> Now we have free firmware which is cool, but the usablity of the phone hasnt 
> changed much.

Hearing stories like this (both now and during the 2y I spent looking
for the TI fw deliverables) helped convince me that I would be better
off spending my time building a free "dumbphone" with no Linux at all,
rather than whipping GTA02 Linux AP software into shape so it could
function as a poor man's imitation of a dumbphone.

Dr. H. Nikolaus Schaller  wrote:

> I invite every =
> remaining Openmoko GTA01/02 owner to cannibalize their device for a =
> GTA04A5 motherboard.

There is a special place in Hell reserved for murderers of good free
hardware like you.

joerg Reisenweber  wrote:

> A question to Michael S.: the heck which dang NDA are you talking about?

Whichever NDA it was/is that is cited by a bunch of Om wiki pages as
the reason for GSM modem fw not being free like the rest of the device.

> OM allowed all reasonable individuals access to all the docs and specs and
> schematics we ever had, on request

Many were probably too timid to ask, or saw no point in getting such
privileged access, reasoning "what good would it do for me to have
access to that shit under NDA if I can't freely share it with the
world and hire any programmer of my choice to troubleshoot odd issues
which I lack the skills to figure out myself"...

In any case, it's a solved problem now; the total collection of docs
plus 4 different source versions in my GSM mini-Wikileaks is probably
greater than what you ever had, so no more demands or threats from me. :)
But it's hard to refrain from stating my con

Re: GSM frequency bands in the USA

[Michael Spacefalcon]

Nick  wrote:

> I'm going to the USA soon,

Do you know which part of USA?

> and would ideally like to use my GTA02
> there. It is a European 900/1800/1900MHz version (I presume - I
> bought it 2nd hand - is there an easy way to check?).

As others have said, look at the sticker inside the battery
compartment.  It's the only way to tell, there is no software-based
way: as discussed on this list earlier, with the standard
/gsm/com/rfcap setting from Om the modem has no knowledge of which
version it is, believing itself to be quad-band instead.

> Can I just use any network in the USA,

In the part of USA where I operate (Southern CA) there are only two
GSM networks: 310260 (current marketing name "T-Mobile USA", used to
be VoiceStream) and 310410 (current marketing name "AT&T", used to be
Cingular - the decoding table in our GSM firmwares still calls it
"Cingular", BTW).  All of my current/recent experience is with
T-Mobile; the last time I used the other network was some 11-12 y ago,
back when they were Cingular.

If you come to Southern California, I can confirm that you can go to
any T-Mobile retail store, buy a SIM card, plug it into your GTA02
(mine is exactly like yours), and it will work.  (For me it works with
*both* the original factory IMEI and the one I made up for testing. :)

If you decide to try the other network (AT&T), you'll be venturing
into so-far-untested territory, and contributing new knowledge. :)

> and it will just register with the 1900MHz band

Yup, that's the band I've been using here for all my cellphone-using
life.  I have yet to use a phone with 850 MHz capability - this
"secondary" USA band is a relatively recent addition (a spectrum
reallocation from AMPS, it seems), and back in 2003 when I got my
first Mot V66 (the subsequent ones have been from ebay), all phones
officially sold in USA with carrier branding were 1900 MHz only or
900/1800/1900 MHz "world phones" like that Mot V66!

Again, this is with a T-Mobile SIM card, connecting to T-Mobile base
stations in the 1900 MHz band - no idea what the picture looks like
for AT&T.

HTH,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GSM frequency bands in the USA

[Michael Spacefalcon]

Nick  wrote:

> It's interesting to hear that 850MHz is a quite recent addition, 

Just keep in mind that my idea of recent is "within the last 10 y",
at least in this case; most other people's definition of this word
probably means a shorter time span. :-(

All I know is that back in 2003 phones sold in USA with carrier
branding were typically 1900 MHz only; I don't know when 850 MHz
support began to be considered as a "requirement".

Of course all those proprietary 3G+ smartphones (Apple/Samsung/GTA04/etc)
which we are all surrounded with typically act as quadband when they
go into 2G compatibility mode, but because they are proprietary black
boxes, only Cthulhu knows which band they are using and what is the
total set of signals they "hear" across their supported bands.  So I
still don't know for certain to this day what GSM services, if any,
exist in the 850 MHz band in my area.

> thanks, that makes me feel even more confident about my GTA02's 
> chances.

I wrote earlier that I only use T-Mobile USA.  That status still holds,
but earlier today I did an experiment: I walked into an AT&T retail
store with one of my Pirellis (900/1800/1900 MHz only, no 850, just
like EU-Freerunner), got a test SIM from the guy in the store (he
pulled it out of one of their demo phones), and inserted that "random"
AT&T SIM into the Pirelli.  After displaying "Searching..." for a
little while, it worked!  The display read "Cingular" - so now we know
that the operator name decoding table in Pirelli's fw is the same as
the one we've got in our sources. :)  Going into the "Engineering mode"
menu confirmed that the actual network in this case (AT&T in Southern
CA) is 310410.  A test voice call worked fine too.

So now we know that *both* GSM networks in USA (or at least in SoCal)
work OK with FreeCalypso GSM phones - although I would still recommend
T-Mobile to non-adventurous users, simply because it's been tested a
lot more extensively, including fun things like CSD.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko GTA06

[Michael Spacefalcon]

"Dr. H. Nikolaus Schaller"  wrote:

> I have received a rumor that somebody is working on a
> truly free and open phone

This part is in fact true.

> with the following specs:

But the specs you have in mind are wrong.

> * Quad-Core Intel Z3770D (1.5 - 2.5 GHz) 

Nope, it's an ARM7TDMI @ 52 MHz, chip made by TI, codename "Calypso",
from TI's Greek mythology series.

> * 4GB RAM

Don't need that much; 8 MiB of pSRAM (combined with NOR flash as part
of the S71PL129NC0 MCP by Spansion) is way more than enough for a good
phone.  (For comparison, the Motorola C139 I'm currently playing with
makes do just fine with only 512 KiB.)

> * 128 GB eMMC

Again, unnecessary complexity and bloat.  Mine will have 16 MiB of NOR
flash instead: S71PL129NC0 provides two flash banks of 8 MiB each; one
will be for the firmware (execute in place), the other for user data
storage.  (For comparison, the user data flash partition on the C139
is only 320 KiB.)

> * LTE with free and open baseband

GSM, not LTE - much better for plain old voice phone calls, which is
what a *phone* is for.  But the free and open part is absolutely
correct!

> * 5 inch full HD display

Unnecessary for a phone.  I plan on using a 128x160 pixel 1.77" color
LCD (TFT), which is quite luxurious compared to Mot C139/V66/etc.

> * <100g

That sounds about right.

> * 4000 mAh battery

Not sure if I can get a battery with such capacity, but because I'm
using TI's source code with proper power management (unlike OsmocomBB),
even a 1000 mAh battery can last a good while.

> * runs any x86 OS (i.e. Linux, Windows, Hackintosh, ...)

It is beyond me why would anyone in his or her right mind want to run
such complex, bloated and unreliable software on a *phone*, a device
whose primary purpose is to provide ultra-reliable voice communication
when all else fails, including emergency communication for potentially
life-threatening situations.

> * shall cost less than Nexus 5

The very limited number of units I will physically produce myself will
probably have a very steep price tag, but unlike you I'm going to put
the gerber files, BOM and everything else on ftp.ifctf.org, so any
community member will be able to produce it herself at whatever price
her chosen PCB fab + parts suppliers + assembly house + RF calibration
lab charge.

> Looks like some "dream machine" :)

You and I have different dreams.

Oh, and if someone were to build your April Fool's device for real, it
should NOT be called GTA-anything, because it is not GSM-TI-AGPS.  I
am not calling my Free Dumb Phone GTAxx either - while the 'G' and 'T'
parts are true for my design, the 'A' part is not.  I do like the
3 letters + 2 digits model naming scheme, but my letters won't be GTA.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko GTA06

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> just would like to mention my needs, and unfortunately I cannot satisfy 
> them with your project. [...]
> So I don't need a "phone", but a mobile computer [...]

Then my project is not for you.  It is for those who specifically want
a plain old cellphone (dumbphone) and not a mobile computer.

I already have a mobile computer which I'm reasonably happy with -
it's a Lenovo X200 ultraportable laptop, running Slackware.  But when
it comes to my cellphone, whether I use my old Mot V66 (unknown chipset)
or the Calypso-based C139 or Pirelli DP-L10, I am currently limited to
running Mot's or Pirelli's original proprietary firmware sans source,
with no ability to fix bugs or to tweak the UI design to my taste.  I
am very unhappy with this status quo, hence I am working to fix it in
a way that is within my ability: by reconstructing TI's standard fw
for modems and dumbphones from pieces (Leonardo+LoCosto+misc) and
making it run on the Calypso-based GSM devices I have available.

The related project of building a new Calypso-based dumbphone is
primarily in response to the exhaustion of the surplus supply of
ready-made devices.  If there were an infinite supply of Pirelli
DP-L10s with full schematics and with docs for that darned SPCA552E
chip, or of Mot C139s with unlocked bootloaders, there would be little
need to build new hw.  But the Pirellis are no longer available, and
even the stash I already have is of limited usefulness because this hw
is cripped by the lack of schematics and by those extra chips w/o docs.
Mot C139s are still somewhat readily available, but they are crippled
by the boot ROM being disabled at the board level, so we have to rely
on the original fw's bootloader instead.  If you buy a C139 on ebay,
it will be a gamble whether it arrives with a firmware version that
features an unlocked bootloader, or one which allows no known way of
loading our own code into the device.

Hence I plan on getting FreeCalypso fw running on a C139 and/or a
Pirelli as a proof of concept, then switching my attention to the
design of a new Calypso dumbphone free of Mot/Pirelli's design flaws.

Current status of the project: I've got the tool I wrote that parses
TI's COFF objects and produces disassembly listings which take
advantage of the symbolic information present in these objects (like
objdump from binutils, but more specifically taylored to TI's COFF
objects made by the TMS470 toolchain), and I am now working on
integrating GPF into my gcc-built FreeCalypso fw.  After GPF we'll
have L1, and then the bulk of the GSM protocol stack, yay!

> Also, routing voice traffic through the Intrenet is a way to not be 
> obliged to pay to carrier per minute or per text message.

So you would rather pay those same carriers per kilobyte instead?

I don't know how things stand in your part of the world, but here in
USA the carriers only want to sell mobile data services while giving
voice and SMS away for free - so it is the direct opposite of what you
are picturing: old-fashioned voice calls and SMS are free here,
whereas "Internet" packet data costs $$$.

> I think that carriers earn too much money just because not all the
> people still used to Internet.

But it's the other way around - those mobile Internet users are the
ones feeding the carriers' revenue stream, while outlaws like me who
eschew all that packet data crap and use old-fashioned circuit-switched
GSM services (yay CSD!) essentially get a free ride on that carrier!

> I believe, if we get Internet, then we can manage the 
> rest without carriers.

But why??  I *like* getting a free ride on my GSM carrier at the
expense of all those fools whose sky-high mobile Internet bills pay
for the upkeep of the infrastructure.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko GTA06

[Michael Spacefalcon]

Norayr Chilingarian  wrote:

> Yes, probably because they have this "call" and "sms" possibility.

Of course they (the carriers) provide call and SMS capabilities,
because I, their customer, want these capabilities, and would not be
their customer if they didn't provide such!

> But I 
> am quite sure, in your part of the world they must have possibility to 
> get a plan, where "calls" and "texts" are prohibited,

Of course you can block whatever you don't like.  But giving up these
services would not save you any money, because they are already
*given away for free*, for zero extra cost.

> but Internet is 
> unlimited, and just pay for it monthly fee.

Yes, the carrier I use (310260) offers unlimited Internet too.  But
unlimited voice & SMS is cheaper, and far more useful to me.

> Then, if their friends know how to use Internet for "calls" and "texts" 

No thanks, I want no part of that.  The quality of a voice "connection"
over bufferbloated mobile data networks is shit (latency in seconds) -
I am much, much happier with traditional circuit-switched phone calls.

> they can refuse from using "phones"  as devices,

I don't have much more to say to you except that we shall fight on
opposite sides.  I *like* using a traditional phone for traditional
phone calls, and I will never give it up.

> like washing machines, 

You refuse to use a washing machine?  Do you wash your clothes by hand
in a pond or a river?  Where I live, none of the nearby natural bodies
of water is clean enough for me to consider washing my clothes there,
so I like using a washing machine.

> designed for specific tasks, in this case - calls via carriers,

Yes, and I take great pride in my work to design and build a device
that does just one thing: make voice phone calls via those carriers,
exactly the thing you are against.

> and I 
> see carriers gradually would become just an ISP's, not less and not more.

Yes, but they still provide the old-fashioned circuit-switched services
as well, and if/when they cease to provide these services, I will cease
being their customer, and will instead become my own carrier - set up
my own GSM network that provides only old-fashioned phone calls and
nothing else, *no* data services whatsoever, except for CSD.

> need to add that the other thing we need, apart from encrypted calls, 
> via gsm, as in your case, or over tcp/ip, as in my case, we need, yes, 
> possibility to change IMEI's

Joerg R. and others on this list have already explained quite well the
pointlessness of those IMEI changes when it comes to privacy.  There
is only one good reason to change one's IMEI: if some operator X blocks
your legitimate IMEI (or an entire range, like all known freeable
phones), and you really need to connect to that network, you can set
your IMEI to something that network will accept.

> and use anonymous SIM cards,

The anonymity or non-anonymity of a SIM card (i.e., whether or not you
have to show a govt-issued ID when buying or activating your SIM) is a
social problem, not one that can be solved by technical means.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

FreeCalypso progress update

[Michael Spacefalcon]

Hello project followers,

Just a quick update on where the FreeCalypso project stands.  I am
still reconstructing the full-source form of TI's Calypso reference
firmware, the one which we currently have only in semi-src form,
running on TI's Leonardo board and on the GTA02 modem.  How can one
reconstruct a full source from a semi-src (half src, half objects) in
which half of the original source is missing?  By finding matching
source pieces in other TI source leaks (the "Peek" LoCosto one mostly)
and reintegrating them one by one onto the reconstructed FreeCalypso
firmware skeleton.

There are a few binary objects in the Leonardo semi-src for which no
matching source could be found in any of the available leaks.  I am
currently working on one of these hard pieces: the OS Adaptation Layer
part of the GPF, the thin layer that sits between the Nucleus RTOS
microkernel and the higher sublayers of GPF.  GPF stands for Generic
Protocol stack Framework, and it is the foundation on which Condat's
GSM/GPRS radio protocol stack is built.  Back in the days when TI
actively maintained their firmware for Calypso, LoCosto and other
offerings in this family, the GPF code was already so stable and
independent of the rest of the firmware that it was distributed and
used mostly as binary libraries even inside TI, it seems.  Take the
LoCosto source for example: all of L1, L2 and L3 code is compiled from
source, but GPF comes from *.lib files that are pulled into the build
as blobs.

But fortunately we've been able to find the real C source for most of
GPF.  The Leonardo semi-src includes a few pieces of GPF C source
despite not actually using them in the build (which uses *.lib blobs
instead); the LoCosto find includes the source for some *other* parts
of GPF - once again, not actually used in the build which uses *.lib
blobs.  By putting together the GPF source bits from the Leonardo and
LoCosto finds, we now have the original C source for *most* of GPF -
and this source has already been integrated into the gcc-built
FreeCalypso GSM firmware tree.

The thin OS Adaptation Layer between Nucleus and the rest of GPF, and
the equally thin OSX layer between GPF and L1, are the only two parts
of GPF for which the original C source could not be found.  The first
out of these two (OSL) is needed in order build a test fw image with
GPF included, hence it is the part I'm working on now; the other (OSX)
should not be needed until it is time to integrate L1, so I plan on
tackling it at that time.

I am reconstructing the missing/lost source for the OSL part of GPF
from the binary object form, by a process of disassembly followed by
decompilation.  The disassembly step is automated with a special tool
I wrote for this purpose.  See the leo-obj subtree in this Hg tree:

https://bitbucket.org/falconian/freecalypso-reveng

Anyone who wonders just how much info can be extracted from these COFF
binary objects is invited to see for herself:

hg clone https://bitbucket.org/falconian/freecalypso-reveng
cd freecalypso-reveng/leo-obj
make

Look at the *.disasm and *.ctypes files that will be produced, and
revel at all of the juicy C-level symbolic info contained therein.
All that stuff has been extracted out of the object blobs; the only
inputs to the tiobjd tool are the *.obj artifacts and some really
minimal hints in the *.hints files (see for yourselves how minimal
they are).  Who was it who said (some 2.5 y ago on this list) that the
ware in question is nothing more than useless blobs?

The next step is decompilation, and it's being done in the gsm-fw/gpf
subtree of the other Hg tree:

https://bitbucket.org/falconian/freecalypso-sw

The gsm-fw/gpf/osl directory contains the C modules which I am
reconstructing from the above *.disasm through manual decompilation;
the other subdirectories of gsm-fw/gpf contain the rest of GPF, the
source for which has been found in the Leonardo and/or LoCosto semi-src.
The inc subdirectory contains all of the original GPF header files,
used by both the original sources and the ones I am reconstructing.

Peruse the two source repositories above to see where the project
stands; look at the commit history to judge the pace at which it is
going.

Viva la Revolucion,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick  wrote:

> I haven't been using my phone much recently, but it's always been 
> reasonably reliable when I have. Today I turned it on, and all day 
> it has just said "searching for network".
> [...]
> I'm not sure where to go or what to look for to debug this. I've 
> restarted the phone multiple times without success.

What modem firmware version is this?

> Any advice?

Since the GSM modem is no longer an impenetrable black box, you could
try debugging the apparently misbehaving modem using standard Free
Software debugging methods: study the source and the documentation,
and make use of the modem debug interface accessible via the headset
jack.

Start by taking QtMoko high-level software out of the equation and
talking AT commands directly to the modem:

http://wiki.openmoko.org/wiki/Manually_using_GSM

Try the AT commands shown on that wiki page, and tell us the results.
That right there might spot an issue.

If the modem behavior at the AT command level is that of failing to
register for no good reason, the next debugging step would be to look
at the debug trace output.  Get a debug cable, if you haven't already:

http://bb.osmocom.org/trac/wiki/Hardware/SerialCable

Put the debug serial channel on the headset jack with this command:

echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download

Make sure the audio is routed to your Neo's earpiece speaker and not
the loudspeaker, to avoid damaging the latter or your ears.  Plug the
debug serial cable into the headset jack, and plug the other end into
your PC or other host computer running GNU/Linux or some other Unix.
Run the rvtdump utility from the FreeCalypso suite, e.g.,

rvtdump -l logfile /dev/ttyUSB0

With the serial cable connected, rvtdump running on the other end, and
1 written into that /sys/.../download node, power up the modem.  You
should get a bunch of debug output; tell us what you see.  (The -l
option will save this output into a log file, with a timestamp prepended
to each line.)  You should get more interested debug output when you
issue AT+CFUN=1 and AT+COPS commands which start the actual GSM
operation; tell us what you see at those steps as well.

If the above steps don't reveal anything amiss, next debugging steps
would be to examine firmware state variables in memory with fc-tmsh
and/or send special commands (called "system primitives", enabling more
verbose traces and other debug functions) to the running fw with g23sh,
both of which are FreeCalypso tools operating via the debug interface
(called RVTMUX) presented on that headset jack.  If you are running a
firmware version such as leo2moko for which we have a linker map file,
we can examine every single variable that fw maintains, and the
"system primitives" provided by the GPF component (Condat's Generic
Protocol stack Framework) allows us to capture and examine every
primitive exchanged between GSM protocol stack layers: e.g., we could
see the exchange between L1 and L2, or between RR and MM, etc.

But let's see if you can manage the simpler steps above before I go
into details of what you should peek and poke with fc-tmsh and g23sh
tools - getting the simpler rvtdump working would be a prerequisite
for the more advanced tools anyway.

HTH,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick  wrote:

> I tried the SIM in another phone and it does work, and another SIM 
> in this one does not (both the same network).

OK, good observation.  The problem is now narrowed down to the FR,
rather than network coverage in your area, your service subscription
or the SIM issued for it.

There is one more thing we need to check before proceeding further,
though.  That other phone you used to confirm your SIMs as good, what
kind of phone is it?  Is it 2G or 3G?  If the latter, please look
through its menus and see if there is an option to force 2G mode.
The reason for this exploration is to eliminate the possibility that
GSM (aka 2G) service in your geographical area stopped working,
knocking out Free Firmware phones while closed proprietary Apple/
Samsung/GTA04/etc still work on UMTS..

(In the event that some part of the world with a nonzero population of
 Free Firmware phone users does kill its GSM service, there are two
 possible ways for us to react to that development: either try to
 liberate one of the newer 3G+ phones/modems, or build our own GSM 2G
 network for our own use.  If/when this situation ever occurs in my
 part of the world, I will do the latter, as I consider GSM/2G to be
 superior to 3G crap both technically and morally.)

Assuming that your email TLD matches your location, you are doing this
in the UK, right?  Do you know if your service provider operates a
900 MHz GSM network, a 1800 MHz one, or both?

> Revision is:
> GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11
> So Moko11, I guess ;)

Any particular reason you have not yet upgraded to leo2moko-r1 aka
moko12?  While it is very unlikely that performing this fw update will
fix the problem, running fw with a published Corresponding Source and
a linker map listing will likely be a prerequisite for some of the
more advanced troubleshooting steps, so you might as well do it now..

> > http://wiki.openmoko.org/wiki/Manually_using_GSM
> [...]
> That's a good idea. I'm hitting a snag before I get very far, 
> though. Namely that I don't know which process is in charge of the 
> GSM, so which one to kill to stop the phone accessing.

According to this web page:

http://winterveldt.co.za/leo2moko-p3.html

the command you need is:

/etc/init.d/qtmoko-neo stop

(Whether the intent is to talk manual AT commands to the modem or to
 reflash it, the step of stopping QtMoko should be the same.)

> lsof would probably tell me, but I can't install it because it's 
> tough to get the wifi to work (which I generally don't care about).  

Huh?  WiFi?  While you do need an ssh connection into the Neo, why
does it have to be WiFi?  Doesn't QtMoko support eth-over-usb
networking like the others?

HTH,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick  wrote:

> The phone that works is 3G, and it doesn't seem to have a 'force 2G' 
> option anywhere.

The option in question often goes by different names: it may also be
named "network type" or "network selection" etc, with the choices
being GSM or WCDMA or both.  Try selecting GSM if you can find the
elusive option.

> I'm in the Greater Boston area,

Ahh - I didn't realize you were still here in the States - I remember
you asking on this list a few months ago about GSM frequency bands in
USA, with the intention of traveling to Boston area, but it was back
in February, so I thought the trip was over and you were back home in
the UK.

How long ago have you arrived in Boston?  Is the FR-not-working
problem something that happened upon arrival in USA, or has it been
working for you for a while in this part of the world?

> so I can't imagine 
> the phone company could just have turned off 2G here yet; there are 
> too many subscribers around.
> [...]
> As I said, I'm in the USA now, and I'm on ATT, FWIW.

Ahh, so you decided to be adventurous and use AT&T instead of the more
tried & tested T-Mobile.  Before we spend an inordinate amount of
effort figuring out why your FR doesn't work on AT&T in Boston,
perhaps you could try a T-Mobile SIM card just as a quick test?  If
you don't have one, just go into any T-Mobile store and ask them to
borrow a SIM for a few minutes to test in your phone while inside
their store.

Also if there is any chance you might visit California before you go
back to the UK, we could meet up and do some GSM hacking together. :)

> Basically because I just want a dumbphone that works, really, so 
> tend towards laziness regarding my phone nowadays.

If you are using your FR as an oversized dumbphone, have you considered
using a real dumbphone instead?  You might want to grab a Mot C139 on
ebay while they are still available - it is one of the models which I
am using for FreeCalypso firmware bring-up (along with the Neo FR and
Pirelli DP-L10) before building my own dumbphone hardware, and it has
the advantage of being a very simple dumbphone with full schematics
available (unlike the Pirelli).

That Linux application processor on the Neo really adds a lot of extra
complexity into the mix, and I find true dumbphones to be much easier
to work with, as in hack, troubleshoot and actually use on an everyday
basis.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

joerg Reisenweber  wrote:

> Please consider that - it seems / I heard - several 850/900 and 1800/1900
> cells are getting reassigned in USA from GSM to UMTS or even LTE during last
> year. Ongoing.

Yes, I heard that too.  Dunno about Boston area, as I'm nowhere near
there, but at least in my roaming area in SoCal I have not lost any
T-Mobile GSM1900 coverage yet.  Yet..

I do have to agree that the problem Nick is having (FR working like a
charm for 2 months, then all of a sudden, bam, getting no coverage)
sounds very suspiciously like the result of GSM cell shutdown, rather
than anything being wrong with the FR.  That is the reason I keep asking
Nick to try a T-Mobile SIM in his area - while both carriers have the
same GSM killing agenda in the long run, it is rather unlikely that
both of them would kill GSM in one specific spot at *exactly* the same
time...

Open letter to FBI/NSA/etc: you guys might want to consider paying
T-Mobile to retain some minimal GSM coverage in Southern California,
just enough for one (1) user, so you can continue tracking my
approximate location.  For as long as I have working GSM (and you know
I almost never turn my phone off, so my sweetie can call me any time),
you can easily track my location with cell-site granularity, and if
you care to do some actual work (call me to cause my phone to transmit
continuously, then bring out your DF gear), you can pin-point where I
am even more precisely than that.  But I will never, ever, ever use a
3G phone, as a firm matter of principle, so if usable GSM service goes
away in my neck of the woods, then I won't have a cellphone at all: of
any kind, period, and then you will have no idea where I am at any
given moment.  Just some food for thought.

Nick  wrote:

> Yeah, I'm here for 6 months. It's a good place :)

6 months from now, or from your arrival however many months ago?  Just
trying to figure out what the time window is for possibly catching you
in Boston area. :)

> No, it has worked fine (well, in fact) for the past couple of 
> months, so it definitely *can* work here.

Hence my worry about you possibly being the first victim of GSM
shutdown by evil greedy carriers who only care about selling data,
rather than traditional call minutes.

> I may end up doing that, but there isn't a T-Mobile store very 
> conveniently located for me,

I've heard that MetroPCS and Simple Mobile are T-Mobile resellers.
If you spot either of these two in your area, try going in there and
asking for a test SIM.

> so I'll at least try some fun logging of AT commands first.

When the modem is working normally, the AT+COPS=? command gives a
listing of all available carriers, so one can see what's available
beyond the specific SIM you've got.  But for some reason that command
only works after I issue a plain AT+COPS first, which is the command
to register to the default operator.  I don't know what will happen if
one issues AT+COPS and that operation fails: will AT+COPS=? work or
not?  I also have not yet studied the relevant part of the firmware
source, so I don't know whether the behaviour I see in this area is a
bug in need of fixing, or if there is some good reason it works this
way.

One can also use the cell_log utility from OsmocomBB to list all
available GSM cells and their owners without having any SIM at all
(and without registering to any of these detected networks), but
because OsmocomBB is dominated by EUnians (not one soul from North
America in that gang), getting cell_log to work in the PCS band was an
incredible pita.  At least I did it on a dumbphone (Pirelli DP-L10);
trying to do it on a Neo would be even more pain..

> Similarly, let me know if you come to Boston. :)

See my question above as to the time window of your presence there.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

There is one more way to test/observe what 2G and 3G services and
carriers are available at a given location: by giving that AT+COPS=?
query command to a 3G USB modem stick that speaks AT commands.  I've
got a Huawei E303 (South American Claro branding), it is supported by
recent versions of the usb_modeswitch package, which puts it into AT
command speaking mode, and one can then run a terminal program on the
/dev/gsmmodem symlink it generates.  Giving this modem an AT+COPS=?
query returns the list of carriers that looks like this:

at+cops=?
+COPS: 
(2,"T-Mobile","TMO","310260",0),(1,"AT&T","AT&T","310410",2),(1,"AT&T","AT&T","310410",0),,(0,1,2,3,4),(0,1,2)

OK

The 5 fields in each parenthesized entry mean:

- state: 2 means currently selected, 1 not selected;
- full name in quotes
- short name in quotes
- the true numeric ID sent by the cell network (the decoded names in
  the previous two fields come from a look-up table in the modem fw);
- 3G-added field not in the GSM 07.07 spec: 2 means 3G, 0 means 2G.

The example output above is from a location that has both T-Mobile and
AT&T service, both 2G and 3G, but T-Mobile 3G in this location is on a
frequency this modem doesn't support, hence it doesn't show up in the
list.  The modem has a T-Mobile SIM in it, hence in the shown example
it is registered on T-Mobile 2G instead of AT&T 3G.

To Nick - if you happen to have one of these 3G USB modem sticks or
are able to borrow one, you should try it at the location where you
are having FR woes and see what it shows.

Andrew Schenck  wrote:

> I can verify that SimpleMobile is a T-Mobile MVNO, but I thought 
> MetroPCS was Sprint.

Perhaps it differs by region.  Recently a new MetroPCS retail outlet
opened in a strip mall near me, I went in there to mess with their
minds a little (I was bored), and they told me they were a T-Mobile
MVNO.

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick  wrote:

> In the meantime, I tried running the AT commands with socat, but 
> didn't get very far.

I've never used socat (I use my own tool, see below), so I don't have
much to comment on that part, but the transcript you've posted shows
that you managed to catch some of the modem's output while it was being
driven by QtMoko (perhaps stopping QtMoko doesn't power the modem off),
and this output contains a smoking gun:

> +CREG: 3

The +CREG unsolicited response from the modem indicates its registration
status, and looking up the meaning of status code 3 in GSM spec 07.07
tells us that it means "registration denied" - aha!  So the GSM radio
signal *is* present, but when your FR tries to register to the network
it hears, the network actively denies that registration!  Two
possibilities come to mind:

Possibility 1: AT&T GSM service went away (either a deliberate service
shutdown, or the tower simply went down for some random reason or
another, and they are in no hurry to fix it because it's 2G which is
only used by outlaws and freedom lovers like us), but T-Mobile GSM is
still present; your FR tries to register with the T-Mobile network,
but the latter rejects the AT&T SIM.

Possibility 2: AT&T GSM service is still there, and your FR is trying
to register to it because it's got an AT&T SIM, but AT&T has decided
to reject your FR for some truly nefarious reason, such as an IMEI ban
against an entire range of devices they don't like - I've read stories
on the web about AT&T specifically pulling such BS.

See below on my proposed method for distinguishing between these two
possibilities.

> %CSQ:  18, 99, 2

%CSQ is TI's non-standard extended version of the standard +CSQ command
and unsolicited response; the standard +CSQ response gives two numbers,
while %CSQ adds a third.  I don't fully understand the meaning of the
3rd number yet, but we can ignore it for now.  99 in the 2nd number
position is a placeholder meaning that the modem has no BER information,
but the 1st number is the RSSI: received signal strength indicator.
Numbers like 18 or 15 seen further in your transcript look good to me.

> +CIEV: 1, 3

Yet another way by which TI's modem implementation returns the RSSI,
apparently.

> The commands 'AT+COPS=?', 'ATE1', 'AT+CFUN=1', 'AT+CGMI' were 
> entered by me. I'm guessing I should have seen at least a 'OK' or 
> 'ERROR' message, so maybe I'm using socat incorrectly?

Because I am the kind of guy who finds it easier to write his own
program than to learn how to use one that already exists, I've been
using my own ad hack tool called engcons to talk AT commands to the
modem in my Neo FR.  The engcons.c source is appended at the end of
this post; you'll need to compile and run it on your FR.  Use it like
this:

# stop QtMoko
/etc/init.d/qtmoko-neo stop
# power-cycle the modem
echo 0 > /sys/bus/platform/devices/gta02-pm-gsm.0/power_on
echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/power_on
# run engcons to talk AT commands
engcons /dev/ttySAC0 r115200

Once you do the above, you should be in a state where you can type AT
commands and see the expected responses.  Try AT+CGMI, AT+CGMM, AT+CGMR,
AT+CFUN=1, AT+COPS and AT+COPS=?, and post the results you get.

VLR,
SF

engcons.c source follows; this ad hack program was originally written
for some completely different purposes and thus contains a bunch of
crud that will make no sense, but I just reused what I already had
working.

/*
 * This utility is used at Harhan Engineering Co. to connect to
 * the console ports of various targets in the lab.  Most of the latter
 * are either MicroVAXen or our own designs inspired by the VAX/MicroVAX
 * console, and this program has a few nifty features specifically
 * intended for those consoles.
 *
 * Beyond simple pass-thru of bytes in both directions, the following
 * features are provided:
 *
 *   - logging
 *   - ^P sends a break
 *   - binary upload via X command
 *   - changing console baud rate on HEC MC68302 targets (not in this version)
 *
 * This is the POSIX termios version of the program; the original version
 * was for 4.3BSD UNIX.
 *
 * Author: Michael Sokolov, Harhan Engineering Co.
 * msoko...@ivan.harhan.org
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

extern int errno;

int mypid;
int tfd;
FILE *tfdF;

struct termios saved_termios, my_termios, target_termios;

int kbd_eol_state = 1;
FILE *logF;

static struct speedtab {
int num;
speed_t code;
} speed_table[] = {
{300, B300},
{1200, B1200},
{2400, B2400},
{4800, B4800},
{9600, B9600},
{19200, B19200},
{38400, B38400},
{57600, B57600},
{115200, B115200},
{0, 0}};

main(argc, argv)
char **argv;
{
int zero = 0;
struct speedtab *spd;
int speed, rtscts = 0;
char *cp;

if (argc < 2 || argc > 3) {
fprintf(stderr, "usage: %s tty [baud]\n", a

Re: [QtMoko] GSM not turning on / registering

[Michael Spacefalcon]

Nick  wrote:

> Interesting results:
> [...]
> AT+COPS=?
> +COPS: (1,"T-Mobile ","T-Mobile","310260")
> OK
> [...]
> If I'm not mistaken the above means that only T-Mobile is found.  

Yes, it does.  310260 aka T-Mobile USA is the only thing your FR can
hear in the PCS1900 band.  Because your FR is the 900/1800/1900 MHz
version (like mine), there is no reliable way to tell if any GSM
services exist in the USA-secondary band at 850 MHz.

If you feel adventurous, you can go to ebay and get one of those Mot
C139 phones I mentioned earlier - it's an ultra-basic candybar
dumbphone that was made either EU-only or US-only, each version
supporting the low and high bands for its region, so the US version
supports both 1900 and 850 MHz.

> Which I'm guessing implies that AT&T have decided to turn off GSM 
> here. Which would be ... annoying.

Given that T-Mobile still provides GSM1900 coverage in your area (and
with good signal strength too, as far as I could tell from your
previous captured modem output), it seems to me that the proper thing
for you to do would be to close the feedback loop by promptly canceling
your AT&T service subscription, and making sure to tell their customer
service exactly why you are no longer interested in their 3G-only
services which do no good for freedom lovers like us.

I've been a T-Mobile customer since 2003, and I've been quite happy
with their service and plans.  The latter have been greatly simplified
when, because they only care about selling data and give voice calls
away for free, they eliminated all counting of minutes and SMS texts,
and set their lowest-end, most basic plan at $50/month for unlimited
calls, unlimited SMS and unlimited 2G data as in GPRS - i.e., their
lowest-end plan gives us unlimited, all-you-can-eat use of everything
that our FreeCalypso phones/modems are capable of using.  (CSD calls,
which work very nicely, at least in SoCal, are part of the unlimited
calls deal too!)

More recently I have heard that some T-Mobile MVNOs apparently offer
the exact same thing for less per month: that MetroPCS I mentioned
earlier say they only charge $30/month, and their description sounds
like the exact same thing that costs $50/month directly from T-Mobile.
In my own case I'm not interested in switching because my plan is not
just for me, but covers all of my family members too, and I'm a
strong follower of "if it ain't broke, don't fix it" - but for someone
new who does not already have service with T-Mobile, looking into
these MVNOs would probably be a good idea.

After I send off this post, I'll make a quick trip to that MetroPCS
store I mentioned earlier, I'll bring my FR with me for testing, and
I'll ask them about Boston area.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Indiephone.eu

[Michael Spacefalcon]

There is one more free phone project still kickin':

https://bitbucket.org/falconian/freecalypso-sw

I somehow doubt that these new folks on the scene (indiephone.eu) will
produce a phone with a baseband processor whose firmware is delivered
to end users in full source form.  At best they might match the level
of freedom one can get today with GTA04 (free AP + closed black box
modem), but more likely they will probably end up like blackphone.  I
looked on blackphone.ch, and nowhere do I see any software source
download links, let alone hardware schematics - WTF?!  Do they
seriously expect people to fork over $$$ for a closed plastic box that
is just as proprietary as the standard run-of-the-mill Androids and
iPhones to which they supposedly offer an "alternative"?

Meanwhile, FreeCalypso is steadily progressing toward its goal of
running 100% free software on all 3 hardware targets: Mot C1xx,
Openmoko GTA02 and Pirelli DP-L10.  Just yesterday I finished
reconstructing the source for the required subset of TI's GPF OS
Adaptation Layer (i.e., writing new C code to replace the bits which
were available only in binary object form, replicating the original
logic flow extracted from disassembly), and today I've got GPF
integrated onto the fledging gcc-built firmware skeleton.  It's
running on my GTA02 as I type this.

I am not aware of any projects other than OsmocomBB and my own
FreeCalypso that have ever promised or done any work toward a phone of
any kind, dumb or smart, that can make or receive phone calls using
only Free Software, i.e., software that provides its users with the
essential Four Freedoms as defined by the FSF.  Yes, if one excludes
the baseband from the freedom requirement, then anything from a Samsung
device running Replicant to GolDeliCo's GTA04 will "pass".  But for
some people that is not good enough, and if there exists a choice
between a more-free solution and a less-free one, why would you choose
the latter?

The OsmocomBB community seems to be interested only in security
research, aka hacking, whereas the goal of producing a usable phone,
if they ever had such a goal at all, appears to have been completely
abandoned.  Consider this one little factoid: OsmocomBB was first
presented at 27C3 in the last days of 2010; a video recording of that
presentation (by Harald Welte) is online.  If you watch that video,
you can see what the state of functionality was as of that date.
Well, here is a bit of breaking news: the level of functionality that
OsmocomBB offers for normal phone usage (as opposed to hacking) is
*exactly the same* today, in mid-2014, as it was at the end of 2010:
the phone can kinda-sorta connect to cell networks (not very reliably)
and can do calls and SMS for as long as it remains tethered to a PC,
with the GSM protocol stack running on the PC instead of the Calypso.
As evidenced by the video of Harald's talk, it did exactly the same in
December of 2010.  So what the heck have these people been doing for
the past 3.5 years??

In comparison, FreeCalypso got a much later start: I only succeeded in
obtaining the key starting-point materials when they were published in
the fall of 2013, less than a year ago, whereas Harald Welte and his
gang have undoubtedly had them many years earlier, probably before they
even started OsmocomBB.

If life circumstances (finances etc) permit me to continue working on
FreeCalypso without slowing down, then by the end of 2014 we shall
have fully free firmware with basic GSM functionality running on the
GTA02 GSM modem, and by "fully free" I mean full C source compiled
with gcc, no blobs or proprietary compilers.  The same fw will run on
"dumbphone" hw targets too, but will still be controlled by external
AT commands, no UI, hence only a toy like OsmocomBB.  Adding UI would
be the next step.

Because I would rather give an overly pessimistic time estimate than
give an overly optimistic one and then fail to deliver, I'll estimate
the time to fruition as follows:

* 2014-12-31: GSM fw fully running on the Calypso baseband, controlled
  by AT commands, which would be good enough for practical use on the
  GTA02, but a toy on the other targets.  Voice + SMS only; adding CSD
  and GPRS would be subsequent extra work.

* 2015-06-30: the above plus the UI layers to make a Calypso dumbphone
  with available schematics and no undocumented chips (e.g., Mot C139)
  work as a practically usable cellphone running 100% free software
  which any user can recompile from source and reflash at will.

(The above are estimates, not a binding contract; anyone interested in
 a firmer commitment in exchange for pay is welcome to contact me
 off-list.)

So as you all can see, the goal of a phone that runs 100% free software
with *no* closed baseband is quite within reach.  Now back to your
regularly scheduled programming.

Viva la Revolucion,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openm

Re: Indiephone.eu

[Michael Spacefalcon]

David wrote:

> Is a GTA02 debug board any use to you? I'd be happy to mail it to you if so.

I already have one. :)

> Excellent - I'm glad you decided to continue.

Yes, I am continuing for the time being, finances etc permitting.

> From what I've seen and heard of the UK supplier 3 (the only 3G only network
> here AFAIK), it's reasonable to think 2G is going to still be around for a
> good long while, at least in some parts of the world.

The 2G service provided by Operator 310260 in my part of the world is
still working OK for now too.

It is really a race: we need to get our Free Dumb Phone working in an
end-user-usable state a year or two before 2G services shut down.  If
Operator 310260 starts shutting down its 2G services when we have a
few hundred (or maybe even a thousand) users with our totally free
phones, they might think twice about losing that many customers, and
could perhaps be convinced to keep a tiny sliver of 2G capacity around
for this segment of their customer base - and if not, if they do shut
their 2G down despite all of our pleas, if we have a thousand users in
our camp, we may be able to pull enough of our own resources together
to set up our own operational 2G network to replace the ones taken
away from us by the mega-carriers.

> In the hope of the project advancing to this stage, I'm interested in picking
> up a dumbphone before I return to SA. Is the C139 the best bet?

It appears to be, as of this moment, subject to change as the project
advances.

> I notice that osmocomBB says the C140 is virtually identical to this model.

Yes, C139 and C140 appear to be exactly the same - I have yet to figure
out what the difference is, if any.  I usually say C139 because to the
best of my knowledge, all units with NA bands are C139s, whereas EMEA
band units have been observed with both C139 and C140 branding.

Please note that all C1xx phones are single-region, i.e., either EMEA
only (900+1800 MHz) or NA only (1900+850 MHz).  That's the downside of
these models compared to the triband GTA02 and Pirelli phones.

> What about the other phones oBB list as targets - is it reasonable to hope
> they will usably run freecalypso?

All other targets listed by OsmocomBB are Compal family members.  FC
already runs on the C139/140 and C155/156 subfamilies - these two and
not others because these two are the ones of potential use to me and
my family operating in the USA-occupied territories.  Getting it to
run on other Compal variants goes along the lines of "we'll add support
for model X as soon as at least one user actually needs it".

> I'm guessing though that the gui code might be substantially model specific?

Yes, the UI hardware in general (not just the LCD as implied by your
reference to "gui", but also parts like the ringtone generator) is the
stuff that varies more widely from model to model.  In particular, FC
support for C155/156 may remain a toy, rather than practically usable,
because these models have a ringtone generator chip for which we have
no docs.  OTOH, C139/140 use a piezo buzzer driven directly by the
Calypso, no extra chip.

My advice here is simple: for as long as C139/140 (which variant is
right for your part of the world, in terms of freq bands) are still
available, just grab one to make things easier.  If you can't get this
model, but some other is still available, then let's revisit the issue
at that time.

Of course the ultimate solution is for us to build our own FC phones,
and I already made a start down that path - but my current game plan
is to finish the software part, and then resume the hardware project.

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

GTA02 2450 mAh Smart Battery

[Michael Spacefalcon]

Yury S  wrote:

> how to restore the battery for neo (pictures without any description, 
> sorry)
> https://www.flickr.com/photos/zyth_2011/sets/72157646722873307/

I vaguely recall one of the experts on this list (or maybe it was some
other related list or forum) saying that a 2450 mAh battery in the
size of BL-6C (let alone BL-4C as in those pictures) is a physical
impossibility, hence anyone marketing one must be lying through their
teeth.

Can someone knowledgeable please comment on this issue?

SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: FreeCalypso status

[Michael Spacefalcon]

Nick  wrote:

> And am I correct in thinking that the latest revision of FreeCalypso 
> is this: 
> ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1-bin.tar.bz2

It's the latest (and only so far) *practically usable* version.  The
full-source, gcc-built FreeCalypso firmware effort is trudging along
and got interesting progress (I got the TCS3.2 version of L1 running
on the Calypso), but it is still pretty far from usable: I'm just
beginning to integrate L23.

> Am I correct in thinking that once flashed, the phone should work 
> indistinguishably to the official firmware? SMS & voice both fully 
> work?

That has been David's experience indeed - unlike me, he uses his FR
running leo2moko with the end user hat on. :)  David, thanks for
testing and confirming the functionality of this fw.

> Do you still want calibration data? I can send it along if you like.

No real need, but you can send it along if you like.

> Finally, is there some way I can donate to you for this stuff?

Bitcoin donations are always welcome:

https://blockchain.info/address/159Yx6JRJ4oMLPTYrh1jW7fQ5D5tPHdnoM

Non-Bitcoiners can donate by snail-mailing a check or money order to
the address on my domain name registration (Michael Sokolov, PO Box
488, Oceanside, CA 92049-0488, USA), but please be aware that with
this method, a portion of the check/MO amount would have to be wasted
on check cashing fees, between 3% and 10% depending on what kind of
check it is - because of my illegal living status, I cannot have a
bank account in my own name, hence I can only cash checks by utilizing
the sleazy check cashing outfits.  (No bank account in my own name
also rules out Paypal.)

VLR,
SF

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community