From tmbinc at elitedvb.net Mon Apr 1 15:29:58 2019 From: tmbinc at elitedvb.net (Felix Domke) Date: Mon, 1 Apr 2019 17:29:58 +0200 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: Message-ID: Hi, > radio transmissions into compliance. The offer is: if there is anyone > in this so-called "community" who (a) has a CMU200 instrument or is > willing to invest into buying one and getting it properly calibrated, > and (b) is willing to do the major work of bringing OBB's radio > transmissions into compliance as verified with that CMU200 instrument, > then I am willing to send that person a fully tested, fully working > and properly calibrated FCDEV3B GSM MS board free of cost. Let me augment/complement this offer (independently): I will borrow out - free of charge - a R+S CRTU-RU to anyone(*) who is willing to use this to improve OsmocomBB, _and has shown_ the ability to do so (for example with a non-trivial commit to OsmocomBB). I'll handle+pay EU-wide shipping (for anything else you would have to handle shipping yourself). The CRTU-RU is a specialized variant of the CMU200 that uses the same RF architecture as the CMU200, has the same non-signalling baseband hardware, but uses different "Signalling Units". This means you can still use all the GSM non-signalling tests as the CMU200, for example you can modulate the GSM training sequences and various test sequences, and validate that the received spectrum is within-limits etc. You cannot use the ordinary CMU200 signalling test (where the CRTU-RU/CMU generates valid BCCH/TCH); instead the CRTU-RU offers a _large_ selection of (an implementation of the) official (3GPP) GSM protocol test cases, which are executed in a Windows 2000-based environment. The CRTU-RUs have been pulled out of Nokia's development labs back in 2014/2015 (when they were auctioned off), and I carefully scraped the software packages of the various CRTU-RUs in my possession. (I have the original hardlock dongles, and I was assured by R+S that by the possession of the Dongle the license was properly transferred.) These tests implement the 3GPP required tests, and are typically used for conformance testing. If we'd survive these tests without failures, there's a good chance we wouldn't disturb public networks, and there's the remote chance we'd survive proper conformance testing. OsmocomBB fails almost any of these tests for various - sometimes simple, sometimes more complicated - reasons. I've started with a few low hanging fruits (for example: 25.2.1.1.2.1 requires handling T200 correctly, which we don't - this causes us to send the SABM retry too late, so we fail the test), but quickly gave up because - honestly - I'm not capable enough to do this as a side project. The tests all come with source code. If someone is interested in this, please contact me off-list. Bonus points if you're interested in setting this up in an automated fashion that lets us test OsmocomBB builds automatically and generate a report for each commit. Thanks, Felix The full list of test packs I have is this: AP2PWS-3.61, AP2PWS-3.80, CRTKEGS-900-2.00, CRTKEGS-900-3.10, CRTKEGS-900-3.20, CRTKLU1-3.00, CRTKLU1-3.10, CRTKSS1-2.30, CRTKSS1-2.40, CRTKSS2-1.90, CRTKSS2-2.00, CRTKSS3-1.80, CRTKSS3-1.90, CRTKSS5-2.00, CRTKSS5-2.10, CRTKSS6-1.80, CRTKSS6-1.90, CRTKSS6-1.91, CRTPK1-3.20, CRTPK1-3.30, CRTPK1-3.40, CRTPK2-3.20, CRTPK2-3.30, CRTPK3-3.40, CRTPK3-3.41, CRTPK3-3.42, CRTPK4-3.50, CRTPK4-3.51, CRTPK4-3.60, CRTPK51-900-2.20, CRTPK51-900-2.21, CRTPK6-3.10, CRTPK6-3.20, CRTPK61-1800-2.21, CRTPK71-1900-2.21, CRTPK71-850-2.21, CRTPK8-3.30, CRTPK9-3.30, CRTPK9-3.40, CRTUGC02-2.30, CRTUGC02-2.40, CRTUGC02-2.50, CRTUGC03-2.00, CRTUGC03-2.10, CRTUGC04-1.80, CRTUGC04-1.81, CRTUGC05-1.90, CRTUGC05-2.00, CRTUGC05-2.10, CRTUGC06-1.80, CRTUGC06-1.90, CRTUGC07-1.90, CRTUGC07-2.00, CRTUGC08-1.60, CRTUGC08-1.90, CRTUGC08-1.91, CRTUGC09-4.30, CRTUGC09-4.40, CRTUGC18-4.70, CRTUGC18-4.80, CRTUGC19-2.10, CRTUGC20-1.90, CRTUGC23-1.40, CRTUGC23-1.71, CRTUGC23-1.80, CRTUGC23-1.90, CRTUGC28-1.40, CRTUGC29-1.53, CRTUGC29-1.60, CRTUGC31-4.50, CRTUGC31-4.60, CRTUGC32-4.40, CRTUGC32-4.50, CRTUGC33-4.60, CRTUGC33-4.61, CRTUGC34-4.80, CRTUGC34-4.90, CRTUGC35-4.70, CRTUGC35-4.71, CRTUGC36-4.50, CRTUGC36-4.60, CRTUGC37-4.50, CRTUGC37-4.60, CRTUGC38-4.40, CRTUGC38-4.50, CRTUGC41-4.70, CRTUGC41-4.80, CRTUGC61-4.50, CRTUGC61-4.60, CRTUGC62-4.40, CRTUGC62-4.50, CRTUGC63-4.40, CRTUGC63-4.50, CRTUGC64-4.10, CRTUGC64-4.60, CRTUGC64-4.70, CRTUGC65-4.50, CRTUGC65-4.60, CRTUGC68-4.50, CRTUGC68-4.60, CRTUGC69-4.70, CRTUGC69-4.80, CRTUGC69-4.90, CRTUGC70-4.60, CRTUGC70-4.61, CRTUGC71-4.40, CRTUGC71-4.50, CRTUGC72-4.60, CRTUGC72-4.70, CRTUGC72-4.71, CRTUGC73-4.10, CRTUGC73-4.60, CRTUGC73-4.61, CRTUGC74-4.40, CRTUGC74-4.50, CRTUGC75-4.60, CRTUGC75-4.70, CRTUGC76-4.50, CRTUGC76-4.60, CRTUGC77-4.61, CRTUGC77-4.70, CRTUGC77-4.80, CRTUGC78-4.60, CRTUGC78-4.61, CRTUGC78-4.70, CRTUGC79-4.50, CRTUGC79-4.60, CRTUGC80-4.40, CRTUGC80-4.50, CRTUGC81-4.51, CRTUGC81-4.60, CRTUGC82-4.30, CRTUGC82-4.40, CRTUGC84-4.70, CRTUGC84-4.71, CRTUGC85-4.60, CRTUGC85-4.70, CRTUGC86-4.50, CRTUGC86-4.60, CRTUGC87-4.50, CRTUGC87-4.60, CRTUGC88-4.60, CRTUGC88-4.70, CRTUGC89-4.60, CRTUGC90-4.70, CRTUGC90-4.71, CRTUGC90-4.72, CRTUGC91-4.40, CRTUGC91-4.50, CUGC01-2.02, CUGC01-2.10, CUGC01-2.11, CUGC01-2.20, nmp51.010_07wk49, nmp_rel4.07wk49 (*) No guarantees. I'll reserve the right to say "no" for random reasons. From laforge at gnumonks.org Sat Apr 6 10:12:54 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Apr 2019 12:12:54 +0200 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: Message-ID: <20190406101254.GD25552@nataraja> Hi Felix, thanks a lot for your generous offer. I'm very happy to see this, but I have very limited hope that at this point somebody would still show such substantial interest in testing compliance of OsmocomBB :/ But for sure, let's hope my pessimism is overrated and someody would invest time into this. On Mon, Apr 01, 2019 at 05:29:58PM +0200, Felix Domke wrote: > If someone is interested in this, please contact me off-list. Bonus > points if you're interested in setting this up in an automated fashion > that lets us test OsmocomBB builds automatically and generate a report > for each commit. I'd be happy to put some sysmocom resources behind this, if it helps. I'm assuming that if somebody creates the "manual" test setup and works on fixing some of the fall-out, we'd contribute some development time on automatizing this setup, and also hosting/maintaining it, doing jenkins integration, ... In addition, irrespective of the above, sysmocom is happy to provide whatever calypso phones, cables, adapters, attenuators, duplexers, USB-UART-Cables, etc. for completing the physical setup. This offer is valid for anyone who'd receive Felix' equipment. Let me know what you'd need/want and I'll try to make sure you get it. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From craig at unreasonablefarm.org Sat Apr 6 13:47:24 2019 From: craig at unreasonablefarm.org (Craig Comstock) Date: Sat, 6 Apr 2019 15:47:24 +0200 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: <20190406101254.GD25552@nataraja> References: <20190406101254.GD25552@nataraja> Message-ID: <20190406134724.GA1819@localhost.localdomain> Hi all, On Sat, Apr 06, 2019 at 12:12:54PM +0200, Harald Welte wrote: > thanks a lot for your generous offer. I'm very happy to see this, but > I have very limited hope that at this point somebody would still show > such substantial interest in testing compliance of OsmocomBB :/ I am determined to make a compliant phone of my own design which includes osmocom-bb. I must work slowly but will continue to work. Currently I have acquired the needed cables to test osmocom-bb with my Racal 6103E which sounds like it may not be sufficient for this level of testing. I have looked at purchasing an R+S CMU200 eventually after I make more progress on porting layer1 to mediatek chips. I am also very interested in an automated setup. Towards that goal I already have some PCBs that were designed for the calypso phones. (can't remember the project URL right now) Cheers, Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From mychaela.falconia at gmail.com Sat Apr 6 21:14:55 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 6 Apr 2019 13:14:55 -0800 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: <20190406134724.GA1819@localhost.localdomain> References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> Message-ID: Craig wrote: > I am determined to make a compliant phone of my own design which includes > osmocom-bb. > I must work slowly but will continue to work. It sounds like your desire to produce a practically usable phone with OBB and MTK chips is as strong as my desire to produce a practically usable phone with TI chips and TI-based firmware. I have been working toward my goal since the fall of 2013 (when the liberation of the world's last surviving copy of TI's TCS211 abandonware from the "we won't share" gang made it possible); what I have to show so far is that I got a commercial-quality modem (with full source code freely published) that would most certainly pass the full type approval test if someone paid for it, but no phone UI yet. In order to turn this FreeCalypso modem of mine into a practically usable phone which I could carry in my purse (pocket replacement for us ladies) instead of the proprietary Pirelli DP-L10, I just need to do one more board design, adding LCD, keypad, battery charging and other handset peripherals to my proven-good modem board design. But because of cost issues (this handset board design will cost me a lot of money), I need to postpone it until after my big surgery, not before, hence it will be another few years. In the meantime, the modem (phone sans UI, control via AT commands) is already 100% working and is available today. Now please present your story (meaning Craig) - how long have you been actively working toward your respective goal? What do you have to show so far? > progress on porting layer1 to mediatek chips. Would you mind clarifying exactly what your OBB-on-MTK layer1 can do today? Can it do a power scan across the band to find the ARFCNs of likely GSM cells? Can it sync to the frequency burst of a cell? Can it receive the synchronization burst and sync to the multiframe structure? Can it receive a cell's broadcast info on BCCH and CCCH? These are the things which OBB on Calypso could do back in 2010. Or zooming out more generally, do you have *any* control of the radio hardware (say, frequency synthesizer or other components of the Rx chain) in your OBB-MTK-L1? Do you have *any* understanding of MTK's DSP and how to talk to it? I hope you realize that every commercial GSM baseband processor, be it from TI or MTK or any other vendor, includes a DSP for signal processing functions, and that one *cannot* meaningfully receive or transmit any GSM signals without having a thorough understanding of that DSP and working with it... The people who created OBB on Calypso back in 2010 used two key sources of knowledge in order to learn how to work with Calypso's DSP: one source of knowledge was the well-publicized TSM30 source, but the other, much less well-known one was the TCS211 semi-src. Both TSM30 and TCS211 versions were absolutely critical to their success; the TSM30 version by itself would NOT have been sufficient for figuring out how to drive the Calypso+Iota+Rita chipset in Mot C1xx phones, which is quite different from the much older TI baseband + non-TI RF in the TSM30 phone. Instead the TCS211 semi-src was *the most critical* piece for working with the Calypso+Iota+Rita chipset, but being a semi-src rather than full source, it had to be supplemented by some other TI source: either TSM30 (what OBB founders used) or LoCosto (what I used instead), still in conjunction with TCS211. Do you have an equivalent source of knowledge for MTK's DSP? Just trying to see if you have anything real and tangible to show for your idea of OBB on MTK, that's all... M~ From craig at unreasonablefarm.org Sun Apr 7 02:18:57 2019 From: craig at unreasonablefarm.org (Craig Comstock) Date: Sun, 7 Apr 2019 04:18:57 +0200 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> Message-ID: <20190407021857.GA2361@localhost.localdomain> Mychaela wrote: > Now please present your story (meaning Craig) - how long have you been > actively working toward your respective goal? What do you have to > show so far? I have been working with osmocom-bb since around 2010, dabbling in porting layer1 to nutt-xand starting 2-3 years ago working more earnestly on understanding layer1 and porting it to fernvale. I have also worked on getting fernly (a small system for experimenting with similar commands like osmoload has) working on other mediatek chips like mtk6261, 6735 and 6737. I have osmocom-bb firmware loading via fernly which has a working serial driver (fromfernly project) so I can get debugging out of devices like fernvale. I have more recently started to port the txburst command from uboot for the sciphone dream g2 (mtk6235) back to osmocom-bb. I have been studying the sources I have for mediatek devices and see many similarities and patterns that should work for fernvale(6260), sciphone (6235) and newer chips such as 6735 and 6739. So at this point I have some work that others did to transmit a burst on a specific ARFCN. This works on uboot for sciphone dream g2 and for some reason doesn't work when I port it back to osmocom-bb to start as a basis for layer1. > Do you have an equivalent source of knowledge for MTK's DSP? As far as I know there is no direct knowledge/sources for MTK's DSP but I haven't quite gotten to the point where I needed to know just yet. This is a very part-time endeavor for me so I do what I can. There are some other people working on various aspects of mediatek devices including trying to get into the DSP. We generally chat/share things on matrix at #postmarketos-lowlevel:disroot.org Cheers, Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From mychaela.falconia at gmail.com Sun Apr 7 05:39:25 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 6 Apr 2019 21:39:25 -0800 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: <20190407021857.GA2361@localhost.localdomain> References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> <20190407021857.GA2361@localhost.localdomain> Message-ID: Craig wrote: > I have been working with osmocom-bb since around 2010, So you have been at it for at least 3 y longer than I have, and you still haven't offered much to show for it.. > dabbling in porting layer1 to nutt-x What is the deal with that NuttX thing? What makes all of you think that it is such a good idea? Just because someone said so? None of the mainstream, commercially successful GSM modem firmwares from any reputable vendor use NuttX, they all use Nucleus, ThreadX or L4 instead. (Both MTK and the stuff I inherited from TI use Nucleus, and I seem to recall hearing of some other vendors using ThreadX and L4.) So I would be extremely wary of that NuttX stuff. > and starting 2-3 years ago working more earnestly on > understanding layer1 and porting it to fernvale. 2-3 y ago is the same time when I went from running FreeCalypso purely as a software project to producing my current FCDEV3B hardware. So far my approach has worked out a lot better: FCDEV3B is now a practically usable commercial-quality GSM+GPRS modem that is fully fit for operation on live GSM networks, which cannot be said for Fernvale. > I have also worked on getting > fernly (a small system for experimenting with similar commands like osmoload > has) working on other mediatek chips like mtk6261, 6735 and 6737. In other words, operating those MTK chips as general-purpose microprocessors without any cellular radio functionality, right? What you are doing here would indeed be a necessary foundational step *if* you had some *realistic* plan for how you are going to bring up cellular radio functionality, but it does not sound like you have any such realistic plan. > So at this point I have some work that others did to transmit a burst on a > specific ARFCN. What you are describing sounds like a low-level RF test mode, transmitting a burst by itself, without any synchronization with a BTS, a test mode provided in most GSM modem implementations (FreeCalypso has it too) for exercising the RF Tx hardware by itself, without a GSM network connection - this test mode is typically used in factory production line processes when doing Tx calibration. > As far as I know there is no direct knowledge/sources for MTK's DSP but I > haven't quite gotten to the point where I needed to know just yet. This is the part that shows most clearly how out of touch you are with reality when it comes to your idea of OBB on MTK. The DSP is the most essential part, and if you don't have that, then everything else is useless, plain and simple - so if you are investing work in other parts of the system without having the DSP firmly under control first, then you are simply spinning your wheels and doing completely wasted work. > This is a very part-time endeavor for me so I do what I can. I am part-time too, I am NOT independently wealthy to where I could work on FreeCalypso full-time. Yet having a limited time budget is not an excuse for making poor judgments as to what is realistically doable and what isn't, deluding yourself and misleading others into a land of false hopes. If you really wish to have a shot at working GSM functionality on an MTK platform, the only way you might be able to achieve something functional would be if you start with MTK's official firmware: ftp://ftp.freecalypso.org/pub/GSM/MTK/ Please note that I am acting only as an archivist and nothing more by hosting that ware on my FTP site. The contributor who sent it to me back in 2015 said that it was supposedly MTK's reference fw for the MT6260 chip, but that is all I know - I don't even know if the contributor's impression was correct or not - but it is the *only* available starting point for those chips, to the best of my knowledge. You would have to spend oodles of time understanding the architecture of that firmware, how to compile it in different configurations (for example, how to select whether you need an AT-command-controlled modem or a self-contained phone handset), how to customize it for different board-level hardware (board-specific GPIO and multifunction pin assignments, and if you are doing a handset fw build, how do you select the screen size and keypad layout and all those details), and then you would need to try getting it to run on your hardware of interest, i.e., SIM800 modules or Fernvale or whatever. You won't have any realistic chance of bringing up any GSM functionality on any MTK platform until you get MTK's official fw running on that platform in a configuration which you compile yourself from semi-src and thoroughly study that MTK official fw and its architecture, just like how the people who did OBB on Calypso in 2010 made critical use of Openmoko's semi-src as a working reference for the Calypso+Iota+Rita chipset. Meanwhile, for anyone who needs a working GSM+GPRS modem with full source code *right now*, my FreeCalypso offering is the only working solution that is available *today*. In another few years I will hopefully also have a self-contained "dumbphone" handset product to complement the already-available modem offering, whereas with the approach taken by Craig, it is highly unlikely that his approach will result in any kind of usable product (be it a phone or a modem) any sooner than 2035 at the earliest, and would probably be more like year 2050. M~ From laforge at gnumonks.org Sun Apr 7 18:25:04 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 7 Apr 2019 20:25:04 +0200 Subject: Tone on this mailing list (Re: Free board offer to OBB developer with a CMU200) In-Reply-To: References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> Message-ID: <20190407182503.GM25552@nataraja> Dear Mychaela, I'm a bit upset by the tone of your message. This mailing list is for discussing open source mobile communications (specifically, in this case, on the phone/UE side). Anyone is welcome to share their views, but there is no competition here. I'm very impressed by your achievements with FreeCalypso, and I'm happy you are participating our discussions here and staying in touch with Osmocom, as well as helping it along [despite of what I feel is a somewhat difficult relationship for you]. However, having achieved a lot in this field yourself doesn't give you the right to intimidate or bully other members on this mailing list. So I would kindly request you to show respect to every hacker who is working in this field, no matter where they are with their project, and no matter what their "track record of achievements" may look like so far. Particularly we, the people with lots of experience and achievement in this field, need to nurture and encourage others, rather than intimidate them. I see the following part of your message as problematic: On Sat, Apr 06, 2019 at 01:14:55PM -0800, Mychaela Falconia wrote: > Now please present your story (meaning Craig) - how long have you been > actively working toward your respective goal? What do you have to > show so far? > [...] > Just trying to see if you have anything real and tangible to show for > your idea of OBB on MTK, that's all... Nobody is accountable to you and has to provide you with a record of how long they have worked on something or what they have achieved. Everyone is welcome and encouraged to share what they're doing, but that's completely voluntary and up to them to disclose. No volunteer working on a FOSS project in their spare time is required to achieve anything [beyond what they have as goals themselves]. Craig has been determined for many years and has been working on this on and off, as I understand. The mere fact that given such a huge and difficult task he hasn't given up yet is a very positive surprise :) So please let's try to be more positive and encouraging, and help others trying to venture into the area of reverse engineering cellular baseband processors. We need more of them, not less :) Thanks for your kind understanding. I hope we can avoid any further discussion on this topic and return to investing all our time into improving open/free cellular technology. Best Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Apr 7 18:39:09 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 7 Apr 2019 20:39:09 +0200 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> <20190407021857.GA2361@localhost.localdomain> Message-ID: <20190407183909.GN25552@nataraja> Hi Mychaela, On Sat, Apr 06, 2019 at 09:39:25PM -0800, Mychaela Falconia wrote: > Craig wrote: > > I have been working with osmocom-bb since around 2010, > > So you have been at it for at least 3 y longer than I have, and you > still haven't offered much to show for it.. Once again, there is no competition here. Not everybody has the same time and resources, level of technicality, etc.. Not everyone has the same goal. Maybe some people just want to have a fun hobby learning a bit more about GSM, reverse engineering, etc. ? > > dabbling in porting layer1 to nutt-x > > What is the deal with that NuttX thing? What makes all of you think > that it is such a good idea? Just because someone said so? That Someone would likely have been me. > None of the mainstream, commercially successful GSM modem firmwares from any > reputable vendor use NuttX, they all use Nucleus, ThreadX or L4 > instead. So what? None of the mainstream operators are using network-side Osmocom components, but still they generally work, and some smaller operators have been running them very successfully so ;) None of the mainstream IT companies were using Linux in the mid-1990ies, still it was quite capable back then. > > and starting 2-3 years ago working more earnestly on > > understanding layer1 and porting it to fernvale. > > 2-3 y ago is the same time when I went from running FreeCalypso purely > as a software project to producing my current FCDEV3B hardware. So far > my approach has worked out a lot better: FCDEV3B is now a practically > usable commercial-quality GSM+GPRS modem that is fully fit for > operation on live GSM networks, which cannot be said for Fernvale. Did it occur to you that Fernvale had completely different goals? Also, how long do you think that your "commercial quality" modem will continue to be available, given the ancient, end-of-life components it requires? MTK still produces newer baseband chips with GSM/GPRS support, and from all we know they didn't significantly change that 2G part in ages. Why would they? It just lives next to their 3G/4G modem parts, probably copy+pasted from the older designs. > In other words, operating those MTK chips as general-purpose > microprocessors without any cellular radio functionality, right? What > you are doing here would indeed be a necessary foundational step *if* > you had some *realistic* plan for how you are going to bring up > cellular radio functionality, but it does not sound like you have any > such realistic plan. Please stop that negative attitude. Nobody needs any realistic plan if they want to play/hack around. > This is the part that shows most clearly how out of touch you are with > reality when it comes to your idea of OBB on MTK. Maybe it's you who is out of touch with Craigs reality? I think Craig is quite realistic when it comes to his ability to create a "production ready GSM/GPRS modem". But did he state anywhere that this is what he's aiming for? > I am part-time too, I am NOT independently wealthy to where I could > work on FreeCalypso full-time. Yet having a limited time budget is > not an excuse for making poor judgments as to what is realistically > doable and what isn't, deluding yourself and misleading others into a > land of false hopes. Please respectfully leave it up to others to make whatever judgements they want on how they spend their spare time. We're not telling you how to spend yours either. Having said this, please feel free to share your points of view in a neutral way - but don't be judgemental and/or attack other people just because they are doing something that's not according to your taste, or which you think is inferior. To put it in the words of Rosa Luxemburg[1]: "Freedom is always the freedom of dissenters." Regards, Harald [1] https://en.wikiquote.org/wiki/Rosa_Luxemburg -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From craig at unreasonablefarm.org Tue Apr 9 03:51:29 2019 From: craig at unreasonablefarm.org (Craig Comstock) Date: Mon, 8 Apr 2019 22:51:29 -0500 Subject: Free board offer to OBB developer with a CMU200 In-Reply-To: References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> <20190407021857.GA2361@localhost.localdomain> Message-ID: <20190409035129.GA14168@localhost.localdomain> On Sat, Apr 06, 2019 at 09:39:25PM -0800, Mychaela Falconia wrote: > > So at this point I have some work that others did to transmit a burst on a > > specific ARFCN. > > What you are describing sounds like a low-level RF test mode, > transmitting a burst by itself, without any synchronization with a BTS, > a test mode provided in most GSM modem implementations (FreeCalypso > has it too) for exercising the RF Tx hardware by itself, without a GSM > network connection - this test mode is typically used in factory > production line processes when doing Tx calibration. It is code which someone else wrote based on I think the available data sheet and possibly the sources that you reference (and other versions of similar). I have been digging through several of these sources for about a year or so and have been working through the existing txburst code. It involves manipulating the baseband interfaces that the MCU (mtk6235) provides. There is an immediate mode which is used in this case where in a typical case a buffered/programmed mode would be used. I don't think it's that far from dealing with the DSP and likely is the level needed in order to do a significant part of the work needed for layer1. > > This is a very part-time endeavor for me so I do what I can. > > I am part-time too, I am NOT independently wealthy to where I could > work on FreeCalypso full-time. Yet having a limited time budget is > not an excuse for making poor judgments as to what is realistically > doable and what isn't, deluding yourself and misleading others into a > land of false hopes. I have enjoyed all of the time I have spent on this project and am excited to learn as I go. It doesn't feel like wasted time at all. :) I hope I am clear to those on this list and elsewhere: I'm just working on this. I have no idea if or when I will ever complete my goal. You can call it slow-ware or something if you like but it isn't exactly vaporware because I am making real things work. > If you really wish to have a shot at working GSM functionality on an > MTK platform, the only way you might be able to achieve something > functional would be if you start with MTK's official firmware: > > ftp://ftp.freecalypso.org/pub/GSM/MTK/ Yes. I downloaded that source now just in case it has some missing pieces. I already have say 2-5 other source trees available for mostly 62xx chips but also 67xx and 68xx chips. Much of the 2G layer1 code is very similar in all these source trees. > You won't have any realistic chance of bringing up any GSM functionality > on any MTK platform until you get MTK's official fw running on that > platform in a configuration which you compile yourself from semi-src > and thoroughly study that MTK official fw and its architecture, just > like how the people who did OBB on Calypso in 2010 made critical use of > Openmoko's semi-src as a working reference for the Calypso+Iota+Rita > chipset. I may end up doing that if it seems like the right choice. For now I have been happy and have made progress without using any semi-src. I have focused on gathering "facts" from the source code, data sheets and existing open source software. > Meanwhile, for anyone who needs a working GSM+GPRS modem with full > source code *right now*, my FreeCalypso offering is the only working > solution that is available *today*. In another few years I will > hopefully also have a self-contained "dumbphone" handset product to > complement the already-available modem offering, whereas with the > approach taken by Craig, it is highly unlikely that his approach will > result in any kind of usable product (be it a phone or a modem) any > sooner than 2035 at the earliest, and would probably be more like > year 2050. Agreed. I can't predict when any stage of my desired end-goal of a usable device will occur. I am quite certain I have never mentioned any timeframes other than what I would ~like~ to achieve. > M~ As always I am very grateful for your attention, knowledge and detailed responses. They help me immensely in my endeavors. Be well, Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From holger at freyther.de Tue Apr 9 10:35:17 2019 From: holger at freyther.de (Holger Freyther) Date: Tue, 9 Apr 2019 11:35:17 +0100 Subject: Tone on this mailing list (Re: Free board offer to OBB developer with a CMU200) In-Reply-To: <20190407182503.GM25552@nataraja> References: <20190406101254.GD25552@nataraja> <20190406134724.GA1819@localhost.localdomain> <20190407182503.GM25552@nataraja> Message-ID: > On 7. Apr 2019, at 19:25, Harald Welte wrote: LaF0rge! thank you for standing up and writing your mail. holger > Dear Mychaela, > > I'm a bit upset by the tone of your message. This mailing list is for > discussing open source mobile communications (specifically, in this case, > on the phone/UE side). Anyone is welcome to share their views, but there > is no competition here. > > I'm very impressed by your achievements with FreeCalypso, and I'm happy > you are participating our discussions here and staying in touch with > Osmocom, as well as helping it along [despite of what I feel is a > somewhat difficult relationship for you]. However, having achieved a lot in > this field yourself doesn't give you the right to intimidate or bully > other members on this mailing list. > > So I would kindly request you to show respect to every hacker who is > working in this field, no matter where they are with their project, > and no matter what their "track record of achievements" may look like > so far. > > Particularly we, the people with lots of experience and achievement in this > field, need to nurture and encourage others, rather than intimidate them. > > I see the following part of your message as problematic: > > On Sat, Apr 06, 2019 at 01:14:55PM -0800, Mychaela Falconia wrote: >> Now please present your story (meaning Craig) - how long have you been >> actively working toward your respective goal? What do you have to >> show so far? >> [...] >> Just trying to see if you have anything real and tangible to show for >> your idea of OBB on MTK, that's all... > > Nobody is accountable to you and has to provide you with a record of > how long they have worked on something or what they have achieved. > > Everyone is welcome and encouraged to share what they're doing, but > that's completely voluntary and up to them to disclose. > > No volunteer working on a FOSS project in their spare time is required > to achieve anything [beyond what they have as goals themselves]. > > Craig has been determined for many years and has been working on this on > and off, as I understand. The mere fact that given such a huge and > difficult task he hasn't given up yet is a very positive surprise :) > > So please let's try to be more positive and encouraging, and help others > trying to venture into the area of reverse engineering cellular baseband > processors. We need more of them, not less :) > > Thanks for your kind understanding. I hope we can avoid any further > discussion on this topic and return to investing all our time into > improving open/free cellular technology. > > Best Regards, > Harald > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Fri Apr 26 22:42:37 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 26 Apr 2019 14:42:37 -0800 Subject: Silabs Aero II transceiver datasheet? Message-ID: Hello OBB gang, The Potential Calypso Targets page in your wiki lists a whole bunch of phones with Silabs Aero II (Si4210) RF transceivers: http://projects.osmocom.org/projects/baseband/wiki/PotentialCalypsoTargets I wonder, has anyone ever succeeded in finding a datasheet for this transceiver? I found the datasheet for the older Aero+ transceiver (a 3-chip solution), but not for the single-chip Aero II aka Si4210. Here are the Silabs Aero materials I have found so far: ftp://ftp.freecalypso.org/pub/GSM/Silabs/ I got the marketing briefs for Aero+ and for Aero II, and the full technical datasheet for the former of the two. If anyone has a datasheet for Si4210 and would be willing to share it, I will gladly add it to the above collection. In the interest of full disclosure, if I get a hold of this datasheet, adding it to the above FTP archive may be all that I will ever do with it: even if I had the datasheet, I do not currently have any realistic plans of adding Silabs Aero RF support to FreeCalypso, let alone to OBB. I do have a couple of Motorola W220 phones on their way to me from ebay, and hopefully at least one of them will actually make it to me, unlike the first one that appears to have fallen into a black hole somewhere, but even with ideal documentation (full schematics and chip datasheets), adding support for a very different RF subsystem (in particular, Silabs' way of doing AGC is entirely different from TI's way) would require more systems engineering work than I can do at the moment. It also doesn't help that the only tpudrv12.c reference TPU driver we have is a reconstructed source made from the disassembly of tpudrv12.obj, not TI's original source - thus all quarter-bit timing numbers (there are lots of them, and they are very critical) are just "magic" numbers, and their original derivation has been lost - does not bode well for the task of figuring out what the corresponding timings should be for a different RF transceiver. All that being said, however, this Si4210 transceiver does look like an attractive alternative to TI's Rita: the Si4210 is 5x5 mm compared to TI's 7x7 mm (every square mm counts in a tightly squeezed modem module), and it has 4 separate LNA inputs for the 4 GSM bands, to be contrasted with Rita and Aero+ arrangement of 3 LNA inputs, one of which is shared between EGSM and GSM850. The Si4210 way with 4 separate LNA inputs allows a fully quadband MS to be implemented in a much more straightforward way. Thus tracking down a datasheet for this Silabs Aero II transceiver and adding it to the knowledge base should be a good step for the GSM enthusiast community as a whole. I already tried asking Silabs for the datasheet, and got the answer that the product line in question was sold to NXP back in 2007. Reading up on Wikipedia, it appears that this stuff did not stay long with NXP either, transferred first to ST-NXP Wireless and then to ST-Ericsson, and when the latter closed, it is totally unclear where the Silabs Aero stuff went, other than the great bit bucket in the sky. :-( M~ From mychaela.falconia at gmail.com Sat Apr 27 22:28:30 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 27 Apr 2019 14:28:30 -0800 Subject: Silabs Aero II transceiver datasheet? In-Reply-To: References: Message-ID: Following up on this inquiry, the datasheet in question has been located - one of the long-timers here sent me a copy. It has now been added to the archival collection: ftp://ftp.freecalypso.org/pub/GSM/Silabs/ I am now waiting for one of those Mot W220 phones I ordered on ebay to actually arrive. I ordered the first one back on April 1 from a seller in Albania, and it appears to have fallen into a black hole somewhere: the seller marked it as shipped, but there is no tracking number, and it has been almost a month. (The "estimated delivery" says April 16 to May 2, thus another week before I can report it to ebay as not delivered.) Giving up on that one, I ordered two more yesterday, one from Serbia and one from Canada - hopefully at least one of them will arrive.. And I did find the schematics for this phone, yay - if anyone needs them, I can add them to the FTP site. The notes in the OBB wiki say that Mot W220 has the Calypso boot ROM enabled and that it is accessible via the headset jack with the same cable as on Compal-made C1xx models, and the schematics seem to concur, so I am hopeful... But here is a mystery: there is another very seemingly-similar phone called C168, it is from the same time period and has essentially the same components, and it is mentioned on the same Potential Calypso Targets page as the W220, although it just lists the use of the Si4210 transceiver but says nothing about code download access. I already have one of those C168 phones - it was much easier to get than W220 because there are plenty of USA sellers for this model (AT&T carried them as basic prepaid phones just like the C139) - but I had zero luck in getting bootloader access through the headset jack on this phone. Unlike with the W220, I also had no luck in finding any downloadable schematics for the C168, so I don't know if this model has the boot ROM disabled via nIBOOT unlike the W220, or if the headset jack does not function in UART mode until the firmware configures it for the AT command interface after boot, or what. Has anyone else tried gaining code download access on the C168? Was your experience the same as mine? Has anyone figured out where the blockage is? Frustrated, Mother Mychaela with her curious-as-a-cat tinkerer hat on