Creating a real usable phone using OsmocomBB
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. 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. 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. ==== 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 -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
What does the community on this list think? Which way shoul we go?
I think that C1xx is the only worthwhile road. Both phones need more work to get something useful, and I think that making it as widely available and usable as possible is highest priority, to boost the project by also getting users involved. Currently the threshold is high to run osmocomBB. If there is a phone which can dial out and receive incoming calls then the threshold is very low. Almost no UI and no features needed. Only start with the most basic functionality: calling, and then go from there. //Peter
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
I also vote for the C1xx phones. I didn't realize they were still available in such large quantities, which itself is a huge advantage IMHO. But the simpler development model and needed software stack, along with major power advantages seems too good to ignore. I don't know if the previous discussion/decision regarding NuttX stands. This (limited) RTOS benchmark looked interesting to me: http://www.yagarto.de/projects/rtoscomp/index.html I am very interested in contributing what I can to such a project. Scott
Hi Scott, On Mon, Dec 12, 2011 at 12:17:35PM +0200, Scott Weisman wrote:
I don't know if the previous discussion/decision regarding NuttX stands. This (limited) RTOS benchmark looked interesting to me:
I am not overly worried by that. From my point of view, aspects like the POSIX-style API and the general structure of the code have much more significance than absolute scheduler latency. It would be great to see some work on getting more of our existing drivers for the calypso ported into NuttX. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Scott, On 12/12/11, Scott Weisman <sweisman@pobox.com> wrote:
I also vote for the C1xx phones. I didn't realize they were still available in such large quantities, which itself is a huge advantage IMHO. But the simpler development model and needed software stack, along with major power advantages seems too good to ignore.
I don't know if the previous discussion/decision regarding NuttX stands. This (limited) RTOS benchmark looked interesting to me:
Please don't confuse Nut/OS with NuttX, they are different RTOS. NuttX is a kind of POSIX/"Unix-like" for micro-controller.
I am very interested in contributing what I can to such a project.
You can start looking the NuttX port for Calypso micro-controller which Stefan (ichgeh@l--putt.de) developed. Best Regards, Alan
Hi Harald, 2011/12/11 Harald Welte <laforge@gnumonks.org>
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.
what do you expect to happen from a legal standpoint? My guess would be that the providers will fight an opensource firmware with every firebreathing lawyer in der reach, and if they won't do that, RegTP (or whatever they are call themself this week ;)) for sure will, a firmware that would reject some evil RRLP queries can't be tolerated :-S
Jay R. Worthington wrote:
what do you expect to happen from a legal standpoint? My guess would be that the providers will fight an opensource firmware with every firebreathing lawyer in der reach,
Translate your question to wifi. Operators can of course try even harder to control in agreements what device you are allowed to use their SIM in, but I don't think that will hold for very long. //Peter
On Tue, Dec 13, 2011 at 12:59:08AM +0100, Jay R. Worthington wrote:
what do you expect to happen from a legal standpoint? My guess would be that the providers will fight an opensource firmware with every firebreathing lawyer in der reach, and if they won't do that, RegTP (or whatever they are call themself this week ;)) for sure will, a firmware that would reject some evil RRLP queries can't be tolerated :-S
Hi Jay, in fact, my legal analysis had been quite optimistic, at least for Europe. the RT&TTE directive largely regulates the sale and distribution of "devices" that transmit on radio frequencies. Devices need to have CE markings and a declaration of conformity. As GSM terminals are part of harmonized standards, the vendor can either certify himself that the devices are CE compliant, or he can use a 'notified body' (a certification lab) to do that externally. The Procedure is described in Annex III of the directive. The testing that needs to be done is in EN 301 511, and EN 301 489-7 However, this all only applies if you distribute the devices with modified firmware. The device with original firmware of course is compliant to the directive and has a Motorola declaration of conformity. Distributing the OsmocomBB firmware itself is certainly not a "device" under the current legislation. Installing + Using it as a user [on a public network] might pose a legal risk, but to be honest I wouldn't know what kind of regulation that would be. There might be a breach of contract of your operator terms of services. And of course, if the firmware misbehaves and causes RF interference, that would be transmission without a radio license, or in the worst case interference with public communications networks. But then, at the same time, lots of people already use Free Software based firmware in their WiFi chips, and I think we've had a lot of discussion in that area. Nonetheless, many people do it... An no, there is no real difference here due to the fact that 2.4 GHz ist unregulated spectrum. You also have to make sure that the frequency, transmission power, harmonics, etc. fall within the rules set forth in the harmonized standards. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
can anybody point out an "open" project offering RF schemes and models plus baseband and mac implementation of Wifi ? any HDL or embedded stack is acceptable . i think the answer to this says a lot about other projects claiming open approach toward any widespread commercial radio system On Tue, Dec 13, 2011 at 11:22 AM, Harald Welte <laforge@gnumonks.org> wrote:
On Tue, Dec 13, 2011 at 12:59:08AM +0100, Jay R. Worthington wrote:
what do you expect to happen from a legal standpoint? My guess would be that the providers will fight an opensource firmware with every firebreathing lawyer in der reach, and if they won't do that, RegTP (or whatever they are call themself this week ;)) for sure will, a firmware that would reject some evil RRLP queries can't be tolerated :-S
Hi Jay,
in fact, my legal analysis had been quite optimistic, at least for Europe. the RT&TTE directive largely regulates the sale and distribution of "devices" that transmit on radio frequencies. Devices need to have CE markings and a declaration of conformity. As GSM terminals are part of harmonized standards, the vendor can either certify himself that the devices are CE compliant, or he can use a 'notified body' (a certification lab) to do that externally. The Procedure is described in Annex III of the directive.
The testing that needs to be done is in EN 301 511, and EN 301 489-7
However, this all only applies if you distribute the devices with modified firmware. The device with original firmware of course is compliant to the directive and has a Motorola declaration of conformity.
Distributing the OsmocomBB firmware itself is certainly not a "device" under the current legislation.
Installing + Using it as a user [on a public network] might pose a legal risk, but to be honest I wouldn't know what kind of regulation that would be. There might be a breach of contract of your operator terms of services. And of course, if the firmware misbehaves and causes RF interference, that would be transmission without a radio license, or in the worst case interference with public communications networks.
But then, at the same time, lots of people already use Free Software based firmware in their WiFi chips, and I think we've had a lot of discussion in that area. Nonetheless, many people do it...
An no, there is no real difference here due to the fact that 2.4 GHz ist unregulated spectrum. You also have to make sure that the frequency, transmission power, harmonics, etc. fall within the rules set forth in the harmonized standards.
Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Mohammad, On Tue, Dec 13, 2011 at 08:45:20PM +0330, Mohammad Hosein wrote:
can anybody point out an "open" project offering RF schemes and models plus baseband and mac implementation of Wifi ? any HDL or embedded stack is acceptable . i think the answer to this says a lot about other projects claiming open approach toward any widespread commercial radio system
This is really OT here and should go to a more general SDR mailinglist like the gnuradio list, but for your reference: https://www.cgran.org/wiki/BBN80211 -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
As a gta02 owner, I am biased towards that. As a lurker and osmocom supporter, the C1xx phones seem to have more of a future. I also wonder which work will also help for future ports such as MTK. The main issue with creating a usable phone though is getting people to use it. For gta02 you can simply get osmocombb included in SHR, QtMoko, Debian etc and voilà, instant users who care about software freedom. For C1xx you would need to create a user community from scratch and do a lot of work to reach the people who might be interested. In both cases there is the whole legality/certification hurdle though. -- bye, pabs http://bonedaddy.net/pabs3/
Hi, my 2 cents to the topic: I think the discussed situation (or target audience) will change rapidly if there is open-source "mobile phone", easy-to-configure, but for modern "low-cost" chipsets. Chinese manufacturers will then very likely use the code for mass-production. With CE certification/etc. I think that most of low-cost phones that come from China use Infineon ULC eGOLDvoice or MTK. I know one importer of Chinese phones who was complaining about problems during development (mainly user interface stuff). Having possibility to use open-source and change it the way they like would definitely be interesting for them. And regarding argument about legality of modifying firmware in WiFi devices, there is a huge difference. Re-flashing AP with Linux (openwrt/etc) does not change anything in RF layer. osmocomBB is now mostly about playing with RF :-). Martin PS: Has anyone access to Infineon ULC (C166) reference design kit code (or some source code or more detailed datasheets) ?
Hi Martin, On Tue, Dec 13, 2011 at 06:01:44PM +0100, Martin Hinner wrote:
my 2 cents to the topic: I think the discussed situation (or target audience) will change rapidly if there is open-source "mobile phone", easy-to-configure, but for modern "low-cost" chipsets. Chinese manufacturers will then very likely use the code for mass-production. With CE certification/etc. I think that most of low-cost phones that come from China use Infineon ULC eGOLDvoice or MTK.
Why do you think so? The chipset vendors provide their GSM stack together with the chips anyway. I would argue that it is even difficult to get components (in quantity) + data sheets etc. from them _without_ also getting the baseband stack from them. So why would any vendor be interested in switching to another stack? Also, always remember, we have no GPRS/EDGE support, and we won't have it any time soon due to the size of the task at hand.
I know one importer of Chinese phones who was complaining about problems during development (mainly user interface stuff). Having possibility to use open-source and change it the way they like would definitely be interesting for them.
Without wanting to insult anyone here, my experience in the industry shows that no importer, not even the chinese phone manufacturers typically have any where near the skills required to do meaningful modifications to the GSM stack of a mobile phone. The typical situation is to the opposite: They run to MTK with all of their issues, because they cannot even resolve the most simple one. After all, they are hardware mass-manufacturing companies, and not die-hard communications protocols and/or OS developers.
And regarding argument about legality of modifying firmware in WiFi devices, there is a huge difference. Re-flashing AP with Linux (openwrt/etc) does not change anything in RF layer. osmocomBB is now mostly about playing with RF :-).
I think you may be mistaken about a lot of the 'softmac', see http://linuxwireless.org/en/developers/Documentation/Glossary#SoftMAC In fact, a lot of wifi chips don't have any baseband firmware, but simply let the driver/stack take care of that. Also see http://www.softwarefreedom.org/resources/2007/fcc-sdr-whitepaper.html on that subject. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
Without wanting to insult anyone here, my experience in the industry shows that no importer, not even the chinese phone manufacturers typically have any where near the skills required to do meaningful modifications to the GSM stack of a mobile phone.
The typical situation is to the opposite: They run to MTK with all of their issues, because they cannot even resolve the most simple one. After all, they are hardware mass-manufacturing companies, and not die-hard communications protocols and/or OS developers.
I think the point with an open source software based phone for businesses is that it creates a new market for development service and solution providers, meaning more products to choose from, and products that can fill existing gaps. You of course know this too since it's exactly the kind of services sysmocom provides. :) //Peter
Harald, On Tue, Dec 13, 2011 at 6:09 PM, Harald Welte <laforge@gnumonks.org> wrote:
my 2 cents to the topic: I think the discussed situation (or target audience) will change rapidly if there is open-source "mobile phone", easy-to-configure, but for modern "low-cost" chipsets. Chinese manufacturers will then very likely use the code for mass-production. With CE certification/etc. I think that most of low-cost phones that come from China use Infineon ULC eGOLDvoice or MTK.
Why do you think so? The chipset vendors provide their GSM stack together with the chips anyway. I would argue that it is even difficult to get components (in quantity) + data sheets etc. from them _without_ also getting the baseband stack from them. So why would any vendor be interested in switching to another stack?
The reason is simple, if the code (not just the GSM stack) provides something more that MTK/Infineon RDK, they would be more than happy to! My company is dealing with China. We are using them to purchase low-cost parts, but they are also our competitors (they even copied our products: have a look at our http://www.obdtester.com/focom vs. http://sinosells.com/goods-7453-Ford+VCM+OBD.html - and thousands of other Chinese webshops!). You would not believe how they are hungry for even small improvements. They are VERY GOOD at copying (in terms of both legal and illegal copies), but if it comes to some improvements ... If OSS comes with anything better than Infineon/MTK, they will surely use it. And I do not think it's difficult to improve for example user interface (which is horrible, btw).
Without wanting to insult anyone here, my experience in the industry shows that no importer, not even the chinese phone manufacturers typically have any where near the skills required to do meaningful modifications to the GSM stack of a mobile phone.
Not all of them :-). This one I was talking about is capable of doing many things. One of company shareholders (by the way, he is not even programmer!) would be able to modify the user interface code himself... but the point is not that some importer would play with the code himself - Chinese manufacturer would do it for them. It's about giving wider range of options to the customer. Martin
(Sorry Martin that was for the list) Le 13/12/2011 18:01, Martin Hinner a écrit :
Chinese manufacturers will then very likely use the code for mass-production. With CE certification/etc.
Yeah... Do you mean... "China Export" certification? No problem to get this one :-) Regards Sebastien
Hello, last days I read about sourcecode release of Tizen. Here the project page: https://www.tizen.org/ (german news about: http://www.golem.de/1201/88938.html ) Could Tizen be a way to a free mobile phone? -- Regards, Benny gpg 0xFC505AB0 jabber benny@benny.de sip benny@benny.de
Hi Benjamin, No, it is not. Tizen is just a Linux running in the Application Processor (AP), just like Android. OsmocomBB is a GSM stack which should run in the Baseband Processor (BP). Best Regards, Alan On 1/11/12, Benjamin Hagemann <benny@benny.de> wrote:
Hello,
last days I read about sourcecode release of Tizen. Here the project page: https://www.tizen.org/
(german news about: http://www.golem.de/1201/88938.html )
Could Tizen be a way to a free mobile phone?
-- Regards,
Benny
gpg 0xFC505AB0 jabber benny@benny.de sip benny@benny.de
Hello Alan, * Alan Carvalho de Assis <acassis@gmail.com> [2012-01-11 22:00]:
No, it is not.
Tizen is just a Linux running in the Application Processor (AP), just like Android.
OsmocomBB is a GSM stack which should run in the Baseband Processor (BP).
yes, right I know. OsmocomBB is today ready to initiate/receive a phone call and send/receive SMS. That the low level function in baseband. So I think the question was to combinate this baseband function with free software in the AP, which handle the "userland", GUI, contactlist and so on. I though is there a OsmocomBB compatible "userland" /AP-OS or should this software be developed completly new? -- Regards, Benny gpg 0xFC505AB0 jabber benny@benny.de sip benny@benny.de
Benjamin Hagemann wrote:
I think the question was to combinate this baseband function with free software in the AP, which handle the "userland", GUI, contactlist and so on. I though is there a OsmocomBB compatible "userland" /AP-OS or should this software be developed completly new?
Since no other open source AP projects run on the Calypso and fit the Motorola phones this is the exact discussion that has already happened in this thread. Check out the archives. //Peter
Since no other open source AP projects run on the Calypso and fit the Motorola phones this is the exact discussion that has already happened in this thread. Check out the archives. Please, would it be possible to include here a link for the other thread discussing that matter? The main question posted by Harald Welte, ("whether we focus on the Openmoko FreeRunner / Neo1973 phones, or the Motorola/Compal C1xx phones") remais open, or that other thread Benjamin mentioned have some detail that resolves Harald's first post? The previous message somehow halted the discussion...
So far, it seems that Motorola/Compal C1xx have more adepts: - Peter Stuge - Dec 11, 2011; 12:11pm - Andreas Eversberg - Dec 11, 2011; 3:18pm - Scott Weisman - Dec 12, 2011; 8:17am Did I missed someone?
But maybe the best thing is to actually stat working on the power management aspects, as we will need them in both cases. That would add even more momentum to the project. And perhaps bring up other details to help choosing between Motorola/OpenMoko.
Best regards, Fábio -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Creating-a-real-usable-phone-usin... Sent from the baseband-devel mailing list archive at Nabble.com.
Hi, (sorry for not participating earlier) On 27/01/2012 14:14, Fabio Pasini wrote:
[...] So far, it seems that Motorola/Compal C1xx have more adepts: - Peter Stuge - Dec 11, 2011; 12:11pm - Andreas Eversberg - Dec 11, 2011; 3:18pm - Scott Weisman - Dec 12, 2011; 8:17am Did I missed someone?
my impression would be that the truly embedded solution is the most sustainable approach, or certainly the one with fewer uncertainties with regard to hardware quality and availability. I feel comforted in this direction when I see the current progress, as blogged by Harald recently: http://laforge.gnumonks.org/weblog/2012/01/28/#20120128-osmocombb_rssi On the other hand, I am very interested by supporting the Openmoko Freerunner, having already written a complete embedded telephony environment for this platform (with interchangeable telephony backend). See https://trac.hackable1.org/trac/wiki/DeforaOSSmartphone for more details. Considering this, I would say that what matters most would be an easy-to-(re)use API to interact with the telephony subsystem, regardless of its presence on a separate chip or not. Then both approaches would be likely, and it should even be easier to hunt and catch bugs. Easier said than done, but HTH nonetheless. Cheers, -- khorben
On the other hand, I am very interested by supporting the Openmoko Freerunner, having already written a complete embedded telephony environment for this platform (with interchangeable telephony backend). See https://trac.hackable1.org/trac/wiki/DeforaOSSmartphone for more details. The big problem is getting nuttx-bb to run on it. I've tried hard, but I didn't succeed at printing a thing on the serial console or on sercomm console.
The sercomm console means the MODEM<->AP serial, using the sercomm API. The serial console means the IRDA<->audio jack<->computer serial console. with osmocombb things are printed on both consoles... I'll try to give more details when I get back from FOSDEM(I've no serial cable for the IRDA with me). and nuttx.bin is less than 64k: -rwxr-xr-x 1 root root 36.2K Jan 7 22:18 nuttx.bin Denis.
Hi Denis, On 2/2/12, Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> wrote:
The big problem is getting nuttx-bb to run on it. I've tried hard, but I didn't succeed at printing a thing on the serial console or on sercomm console.
Did you get help from Stefan (aka l--putt) ? I'll try to run NuttX on Motorola W220, then we can work together on this uart issue. Best Regards, Alan
Hi Benny, On Wed, Jan 11, 2012 at 09:24:42PM +0100, Benjamin Hagemann wrote:
last days I read about sourcecode release of Tizen. Here the project page: https://www.tizen.org/
(german news about: http://www.golem.de/1201/88938.html )
Could Tizen be a way to a free mobile phone?
All that _all_ such projects (Android, Maemo, Mobiln, Greenphone/QTE, evne Openmoko) were about is the PDA side of the feature phone. None of them ever touched the baseband processor in any way -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (14)
-
Alan Carvalho de Assis -
Andreas Eversberg -
Benjamin Hagemann -
Denis 'GNUtoo' Carikli -
Fabio Pasini -
Harald Welte -
Jay R. Worthington -
Martin Hinner -
Mohammad Hosein -
Paul Wise -
Peter Stuge -
Pierre Pronchery -
Scott Weisman -
Sebastien Lorquet