Creating a real usable phone using OsmocomBB

Andreas Eversberg andreas at eversberg.eu
Sun Dec 11 17:18:45 UTC 2011


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




More information about the baseband-devel mailing list