hi,
Harald Welte wrote:
Hi all!
I've mentioned this before, and I keep getting back to it: With all the
great work that has been put into OsmocomBB, we are "at an arms lengh"
away from being able to create a true Free Software mobile phone.
We already have the hardware drivers, protocol stack and even the
'mobile' program which can be used for making and receiving voice calls
and sending/receiving SMS text messages on real GSM networks!
While the journey has been a lot of fun and everyone involved has
learned a lot, we have so far been catering mstly about "scratching our
own itch", i.e. implementing what we needed in order to satisfy our ego
and/or to implement the ideas we had regarding cellular security.
indeed it is allot of phun. the implementation of security features
(like imsi catcher detection) is not really a problem, but therefore we
must define them first.
I believe we cannot miss the bigger opportunity here
to put our code
into bigger use: To create something like a very simple GSM feature
phone.
we should not only try to implement a 10 euro phone. this is what we
already had before the osmocombb project. osmocombb should focus on
things that normal phones doesn't have. but yes, it must first do the
basic stuff correctly, like being stable and usable like a GSM phone.
otherwise it is a pain using it. i think of two issues still left for
the stack: reliable syncing and handover.
When we look at various areas of computing like
Operating Systems or Web
browsers, Free Software is not just "the hobby project catching up" with
the vendors of proprietary software. Free Software can compete.
In the cellular area, we have still not managed to even implement the
most basic GSM feature phone that existed 15 years ago using proprietary
software. We need to work on closing that gap. We need to show that a
small community of Free Software developers can actually implement what
teams of hundreds of engineers did in a proprietary software setting 15
years ago - despite all the lack of hardware documentation or any kind
of positive feedback from the cellular chipset, handset or operator
industry.
If we don't at least get a 2G GSM cellphone implemented now, it will
probably not happen before 2G networks become insignificant in large
parts of the world.
This is a call to all hands, please support this project!
Regards,
Harald
== Technical aspects ==
I believe the first major decision is whether we focus on
1) the Openmoko FreeRunner / Neo1973 phones
Advantages:
* large screen for UI with bells and whistles
* lots of RAM and Flash, even script languages or compilation on the
device itself possible
* second processor doesn't require us to run stack + UI on once CPU
* easier debugging of UI
* various existing telephony middleware and phone dialer UI projects
of which hopefully one could be recycled
or
2) the Motorola/Compal C1xx phones
Advantags:
* many more phones available, even after our software is released
* lower cost of the individual phone
* less power consumption due to only one small ARM7 core
* smaller screen also means less fancy UI requirements
Problems:
* full stack + UI needs to run on calypso (L2/L3) and we'd probably
some kind of RTOS like NuttX instead of our 'bare iron' code.
i prefer this one, because it will have (and already has) a much larger
audience. if we would have the RTOS working and finished the UI (as well
as defining an MMI interface for communication with the stack), we
should have almost made it.
==== What we need in any case ====
* power management on the baseband processor through all of the stack
(though it's mostly a driver/L1 kind of thing)
== Summary / Opinion ==
It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
Openmoko baseband + application processor might be the quicker road to
progress. Sure, the power consumption will be horrible as the AP will
have to be woken up for each and every SI message, neighbor cell
measurment or paging request that ew see comining in in our paging group
(even in idle mode). But then, there is always the negative impact of
using a relatively complex system, with two processors, a complex
software stack (Linux, X11, toolkit, etc.) on one of them, etc.
On the other hand, using the C1xx phones will result in a much more
widely available result. The phones can still be bought in batches of
1,000 units, and they are small enough for lots of people to carry
around. Furthermore, the battery lifetime is far beyond anything you
would ever be able to achieve on a power-hungry smartphone platform. I
believe it would be the "smart' solution, as it means we need to get
everything integrated, etc.
What does the community on this list think? Which way shoul we go?
But maybe the best thing is to actually stat working on the power
management aspects, as we will need them in both cases.
Happy hacking,
Harald
we should define all that at 28c3, so we can start to complete it.
regards,
andreas