Creating a real usable phone using OsmocomBB

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Michael Sokolov msokolov at ivan.Harhan.ORG
Mon Dec 12 18:43:13 UTC 2011


Denis 'GNUtoo' Carikli <GNUtoo at no-log.org> wrote:

> That's exactly what I was thinking about, since running the layer23 on the 
> Application CPU is not a so good idea, it renders the phone usable only for a 
> small period of time(since,in that configuration, you cannot suspend the AP 
> CPU because it has to run the telephony code).

It's obvious that running layer23 on the AP is a *terrible* idea.  It
needs to move into the Calypso (or other BP) before there can be any
serious thought of OsmocomBB truly replacing the existing proprietary
BP code.  However, my own skill & knowledge level is nowhere close to
what would be needed for that job.

But I was thinking of taking the current sorry state of things
(layer23 external to the BP) and making it run on a self-contained
GTA02: have the Samsung AP run layer23 instead of acting as a pass-
through to a PC, then add some UI to it: the very same UI I wanted to
implement in the first place before I got sidetracked to the baseband
issues.  The result of that would be having the GTA02 act as a
"normal" feature phone in every way except for draining the battery in
a couple of hours while doing nothing.  The last aspect would make it
rather unusable practically (unless perhaps one replaces the standard
Li-ion battery with an automotive-sized lead-acid one), but it would
be a tangible hands-on "teaser" of what would be possible if someone
with the necessary knowledge and skills took the bother to redesign
the code (move layer23 into the Calypso) such that proper PM could be
implemented.

> Why is AT bad? what other protocol do you propose?

What Peter said:

: Um, no, it's the other way around. AT is 30 years of horrible.

If I were able to lay my hands on some source for an *existing*
implementation of the AT command interface on the BP side, I would
have no problem with implementing it on the AP side in my UI.  But if
I have to write the code from scratch on both sides of the interface,
I'll probably implement some ad hoc protocol of my own rather than
attempt to implement the "standard" one and get it wrong.

MS




More information about the baseband-devel mailing list