Re: SHR source code
On 07/27/2016 12:43 AM, karimi wrote: Hi I'm looking for SHR source code. Where can i find it? Thanks It seems: http://wiki.openmoko.org/wiki/SHR has http://wiki.openmoko.org/wiki/SHR#More_Information which lists http://trac.shr-project.org/ and http://git.shr-project.org/ Mike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeCalypso status
Nick openmoko-commun...@njw.me.uk wrote: And am I correct in thinking that the latest revision of FreeCalypso is this: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1-bin.tar.bz2 It's the latest (and only so far) *practically usable* version. The full-source, gcc-built FreeCalypso firmware effort is trudging along and got interesting progress (I got the TCS3.2 version of L1 running on the Calypso), but it is still pretty far from usable: I'm just beginning to integrate L23. Am I correct in thinking that once flashed, the phone should work indistinguishably to the official firmware? SMS voice both fully work? That has been David's experience indeed - unlike me, he uses his FR running leo2moko with the end user hat on. :) David, thanks for testing and confirming the functionality of this fw. Do you still want calibration data? I can send it along if you like. No real need, but you can send it along if you like. Finally, is there some way I can donate to you for this stuff? Bitcoin donations are always welcome: https://blockchain.info/address/159Yx6JRJ4oMLPTYrh1jW7fQ5D5tPHdnoM Non-Bitcoiners can donate by snail-mailing a check or money order to the address on my domain name registration (Michael Sokolov, PO Box 488, Oceanside, CA 92049-0488, USA), but please be aware that with this method, a portion of the check/MO amount would have to be wasted on check cashing fees, between 3% and 10% depending on what kind of check it is - because of my illegal living status, I cannot have a bank account in my own name, hence I can only cash checks by utilizing the sleazy check cashing outfits. (No bank account in my own name also rules out Paypal.) VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA02 2450 mAh Smart Battery
Yury S z...@onego.ru wrote: how to restore the battery for neo (pictures without any description, sorry) https://www.flickr.com/photos/zyth_2011/sets/72157646722873307/ I vaguely recall one of the experts on this list (or maybe it was some other related list or forum) saying that a 2450 mAh battery in the size of BL-6C (let alone BL-4C as in those pictures) is a physical impossibility, hence anyone marketing one must be lying through their teeth. Can someone knowledgeable please comment on this issue? SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Indiephone.eu
David wrote: Is a GTA02 debug board any use to you? I'd be happy to mail it to you if so. I already have one. :) Excellent - I'm glad you decided to continue. Yes, I am continuing for the time being, finances etc permitting. From what I've seen and heard of the UK supplier 3 (the only 3G only network here AFAIK), it's reasonable to think 2G is going to still be around for a good long while, at least in some parts of the world. The 2G service provided by Operator 310260 in my part of the world is still working OK for now too. It is really a race: we need to get our Free Dumb Phone working in an end-user-usable state a year or two before 2G services shut down. If Operator 310260 starts shutting down its 2G services when we have a few hundred (or maybe even a thousand) users with our totally free phones, they might think twice about losing that many customers, and could perhaps be convinced to keep a tiny sliver of 2G capacity around for this segment of their customer base - and if not, if they do shut their 2G down despite all of our pleas, if we have a thousand users in our camp, we may be able to pull enough of our own resources together to set up our own operational 2G network to replace the ones taken away from us by the mega-carriers. In the hope of the project advancing to this stage, I'm interested in picking up a dumbphone before I return to SA. Is the C139 the best bet? It appears to be, as of this moment, subject to change as the project advances. I notice that osmocomBB says the C140 is virtually identical to this model. Yes, C139 and C140 appear to be exactly the same - I have yet to figure out what the difference is, if any. I usually say C139 because to the best of my knowledge, all units with NA bands are C139s, whereas EMEA band units have been observed with both C139 and C140 branding. Please note that all C1xx phones are single-region, i.e., either EMEA only (900+1800 MHz) or NA only (1900+850 MHz). That's the downside of these models compared to the triband GTA02 and Pirelli phones. What about the other phones oBB list as targets - is it reasonable to hope they will usably run freecalypso? All other targets listed by OsmocomBB are Compal family members. FC already runs on the C139/140 and C155/156 subfamilies - these two and not others because these two are the ones of potential use to me and my family operating in the USA-occupied territories. Getting it to run on other Compal variants goes along the lines of we'll add support for model X as soon as at least one user actually needs it. I'm guessing though that the gui code might be substantially model specific? Yes, the UI hardware in general (not just the LCD as implied by your reference to gui, but also parts like the ringtone generator) is the stuff that varies more widely from model to model. In particular, FC support for C155/156 may remain a toy, rather than practically usable, because these models have a ringtone generator chip for which we have no docs. OTOH, C139/140 use a piezo buzzer driven directly by the Calypso, no extra chip. My advice here is simple: for as long as C139/140 (which variant is right for your part of the world, in terms of freq bands) are still available, just grab one to make things easier. If you can't get this model, but some other is still available, then let's revisit the issue at that time. Of course the ultimate solution is for us to build our own FC phones, and I already made a start down that path - but my current game plan is to finish the software part, and then resume the hardware project. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Indiephone.eu
There is one more free phone project still kickin': https://bitbucket.org/falconian/freecalypso-sw I somehow doubt that these new folks on the scene (indiephone.eu) will produce a phone with a baseband processor whose firmware is delivered to end users in full source form. At best they might match the level of freedom one can get today with GTA04 (free AP + closed black box modem), but more likely they will probably end up like blackphone. I looked on blackphone.ch, and nowhere do I see any software source download links, let alone hardware schematics - WTF?! Do they seriously expect people to fork over $$$ for a closed plastic box that is just as proprietary as the standard run-of-the-mill Androids and iPhones to which they supposedly offer an alternative? Meanwhile, FreeCalypso is steadily progressing toward its goal of running 100% free software on all 3 hardware targets: Mot C1xx, Openmoko GTA02 and Pirelli DP-L10. Just yesterday I finished reconstructing the source for the required subset of TI's GPF OS Adaptation Layer (i.e., writing new C code to replace the bits which were available only in binary object form, replicating the original logic flow extracted from disassembly), and today I've got GPF integrated onto the fledging gcc-built firmware skeleton. It's running on my GTA02 as I type this. I am not aware of any projects other than OsmocomBB and my own FreeCalypso that have ever promised or done any work toward a phone of any kind, dumb or smart, that can make or receive phone calls using only Free Software, i.e., software that provides its users with the essential Four Freedoms as defined by the FSF. Yes, if one excludes the baseband from the freedom requirement, then anything from a Samsung device running Replicant to GolDeliCo's GTA04 will pass. But for some people that is not good enough, and if there exists a choice between a more-free solution and a less-free one, why would you choose the latter? The OsmocomBB community seems to be interested only in security research, aka hacking, whereas the goal of producing a usable phone, if they ever had such a goal at all, appears to have been completely abandoned. Consider this one little factoid: OsmocomBB was first presented at 27C3 in the last days of 2010; a video recording of that presentation (by Harald Welte) is online. If you watch that video, you can see what the state of functionality was as of that date. Well, here is a bit of breaking news: the level of functionality that OsmocomBB offers for normal phone usage (as opposed to hacking) is *exactly the same* today, in mid-2014, as it was at the end of 2010: the phone can kinda-sorta connect to cell networks (not very reliably) and can do calls and SMS for as long as it remains tethered to a PC, with the GSM protocol stack running on the PC instead of the Calypso. As evidenced by the video of Harald's talk, it did exactly the same in December of 2010. So what the heck have these people been doing for the past 3.5 years?? In comparison, FreeCalypso got a much later start: I only succeeded in obtaining the key starting-point materials when they were published in the fall of 2013, less than a year ago, whereas Harald Welte and his gang have undoubtedly had them many years earlier, probably before they even started OsmocomBB. If life circumstances (finances etc) permit me to continue working on FreeCalypso without slowing down, then by the end of 2014 we shall have fully free firmware with basic GSM functionality running on the GTA02 GSM modem, and by fully free I mean full C source compiled with gcc, no blobs or proprietary compilers. The same fw will run on dumbphone hw targets too, but will still be controlled by external AT commands, no UI, hence only a toy like OsmocomBB. Adding UI would be the next step. Because I would rather give an overly pessimistic time estimate than give an overly optimistic one and then fail to deliver, I'll estimate the time to fruition as follows: * 2014-12-31: GSM fw fully running on the Calypso baseband, controlled by AT commands, which would be good enough for practical use on the GTA02, but a toy on the other targets. Voice + SMS only; adding CSD and GPRS would be subsequent extra work. * 2015-06-30: the above plus the UI layers to make a Calypso dumbphone with available schematics and no undocumented chips (e.g., Mot C139) work as a practically usable cellphone running 100% free software which any user can recompile from source and reflash at will. (The above are estimates, not a binding contract; anyone interested in a firmer commitment in exchange for pay is welcome to contact me off-list.) So as you all can see, the goal of a phone that runs 100% free software with *no* closed baseband is quite within reach. Now back to your regularly scheduled programming. Viva la Revolucion, SF ___ Openmoko community mailing list community@lists.openmoko.org
Re: [QtMoko] GSM not turning on / registering
Nick openmoko-commun...@njw.me.uk wrote: Interesting results: [...] AT+COPS=? +COPS: (1,T-Mobile ,T-Mobile,310260) OK [...] If I'm not mistaken the above means that only T-Mobile is found. Yes, it does. 310260 aka T-Mobile USA is the only thing your FR can hear in the PCS1900 band. Because your FR is the 900/1800/1900 MHz version (like mine), there is no reliable way to tell if any GSM services exist in the USA-secondary band at 850 MHz. If you feel adventurous, you can go to ebay and get one of those Mot C139 phones I mentioned earlier - it's an ultra-basic candybar dumbphone that was made either EU-only or US-only, each version supporting the low and high bands for its region, so the US version supports both 1900 and 850 MHz. Which I'm guessing implies that ATT have decided to turn off GSM here. Which would be ... annoying. Given that T-Mobile still provides GSM1900 coverage in your area (and with good signal strength too, as far as I could tell from your previous captured modem output), it seems to me that the proper thing for you to do would be to close the feedback loop by promptly canceling your ATT service subscription, and making sure to tell their customer service exactly why you are no longer interested in their 3G-only services which do no good for freedom lovers like us. I've been a T-Mobile customer since 2003, and I've been quite happy with their service and plans. The latter have been greatly simplified when, because they only care about selling data and give voice calls away for free, they eliminated all counting of minutes and SMS texts, and set their lowest-end, most basic plan at $50/month for unlimited calls, unlimited SMS and unlimited 2G data as in GPRS - i.e., their lowest-end plan gives us unlimited, all-you-can-eat use of everything that our FreeCalypso phones/modems are capable of using. (CSD calls, which work very nicely, at least in SoCal, are part of the unlimited calls deal too!) More recently I have heard that some T-Mobile MVNOs apparently offer the exact same thing for less per month: that MetroPCS I mentioned earlier say they only charge $30/month, and their description sounds like the exact same thing that costs $50/month directly from T-Mobile. In my own case I'm not interested in switching because my plan is not just for me, but covers all of my family members too, and I'm a strong follower of if it ain't broke, don't fix it - but for someone new who does not already have service with T-Mobile, looking into these MVNOs would probably be a good idea. After I send off this post, I'll make a quick trip to that MetroPCS store I mentioned earlier, I'll bring my FR with me for testing, and I'll ask them about Boston area. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GSM not turning on / registering
joerg Reisenweber jo...@openmoko.org wrote: Please consider that - it seems / I heard - several 850/900 and 1800/1900 cells are getting reassigned in USA from GSM to UMTS or even LTE during last year. Ongoing. Yes, I heard that too. Dunno about Boston area, as I'm nowhere near there, but at least in my roaming area in SoCal I have not lost any T-Mobile GSM1900 coverage yet. Yet.. I do have to agree that the problem Nick is having (FR working like a charm for 2 months, then all of a sudden, bam, getting no coverage) sounds very suspiciously like the result of GSM cell shutdown, rather than anything being wrong with the FR. That is the reason I keep asking Nick to try a T-Mobile SIM in his area - while both carriers have the same GSM killing agenda in the long run, it is rather unlikely that both of them would kill GSM in one specific spot at *exactly* the same time... Open letter to FBI/NSA/etc: you guys might want to consider paying T-Mobile to retain some minimal GSM coverage in Southern California, just enough for one (1) user, so you can continue tracking my approximate location. For as long as I have working GSM (and you know I almost never turn my phone off, so my sweetie can call me any time), you can easily track my location with cell-site granularity, and if you care to do some actual work (call me to cause my phone to transmit continuously, then bring out your DF gear), you can pin-point where I am even more precisely than that. But I will never, ever, ever use a 3G phone, as a firm matter of principle, so if usable GSM service goes away in my neck of the woods, then I won't have a cellphone at all: of any kind, period, and then you will have no idea where I am at any given moment. Just some food for thought. Nick openmoko-commun...@njw.me.uk wrote: Yeah, I'm here for 6 months. It's a good place :) 6 months from now, or from your arrival however many months ago? Just trying to figure out what the time window is for possibly catching you in Boston area. :) No, it has worked fine (well, in fact) for the past couple of months, so it definitely *can* work here. Hence my worry about you possibly being the first victim of GSM shutdown by evil greedy carriers who only care about selling data, rather than traditional call minutes. I may end up doing that, but there isn't a T-Mobile store very conveniently located for me, I've heard that MetroPCS and Simple Mobile are T-Mobile resellers. If you spot either of these two in your area, try going in there and asking for a test SIM. so I'll at least try some fun logging of AT commands first. When the modem is working normally, the AT+COPS=? command gives a listing of all available carriers, so one can see what's available beyond the specific SIM you've got. But for some reason that command only works after I issue a plain AT+COPS first, which is the command to register to the default operator. I don't know what will happen if one issues AT+COPS and that operation fails: will AT+COPS=? work or not? I also have not yet studied the relevant part of the firmware source, so I don't know whether the behaviour I see in this area is a bug in need of fixing, or if there is some good reason it works this way. One can also use the cell_log utility from OsmocomBB to list all available GSM cells and their owners without having any SIM at all (and without registering to any of these detected networks), but because OsmocomBB is dominated by EUnians (not one soul from North America in that gang), getting cell_log to work in the PCS band was an incredible pita. At least I did it on a dumbphone (Pirelli DP-L10); trying to do it on a Neo would be even more pain.. Similarly, let me know if you come to Boston. :) See my question above as to the time window of your presence there. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GSM not turning on / registering
There is one more way to test/observe what 2G and 3G services and carriers are available at a given location: by giving that AT+COPS=? query command to a 3G USB modem stick that speaks AT commands. I've got a Huawei E303 (South American Claro branding), it is supported by recent versions of the usb_modeswitch package, which puts it into AT command speaking mode, and one can then run a terminal program on the /dev/gsmmodem symlink it generates. Giving this modem an AT+COPS=? query returns the list of carriers that looks like this: at+cops=? +COPS: (2,T-Mobile,TMO,310260,0),(1,ATT,ATT,310410,2),(1,ATT,ATT,310410,0),,(0,1,2,3,4),(0,1,2) OK The 5 fields in each parenthesized entry mean: - state: 2 means currently selected, 1 not selected; - full name in quotes - short name in quotes - the true numeric ID sent by the cell network (the decoded names in the previous two fields come from a look-up table in the modem fw); - 3G-added field not in the GSM 07.07 spec: 2 means 3G, 0 means 2G. The example output above is from a location that has both T-Mobile and ATT service, both 2G and 3G, but T-Mobile 3G in this location is on a frequency this modem doesn't support, hence it doesn't show up in the list. The modem has a T-Mobile SIM in it, hence in the shown example it is registered on T-Mobile 2G instead of ATT 3G. To Nick - if you happen to have one of these 3G USB modem sticks or are able to borrow one, you should try it at the location where you are having FR woes and see what it shows. Andrew Schenck and...@springahead.com wrote: I can verify that SimpleMobile is a T-Mobile MVNO, but I thought MetroPCS was Sprint. Perhaps it differs by region. Recently a new MetroPCS retail outlet opened in a strip mall near me, I went in there to mess with their minds a little (I was bored), and they told me they were a T-Mobile MVNO. SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GSM not turning on / registering
Nick openmoko-commun...@njw.me.uk wrote:
In the meantime, I tried running the AT commands with socat, but
didn't get very far.
I've never used socat (I use my own tool, see below), so I don't have
much to comment on that part, but the transcript you've posted shows
that you managed to catch some of the modem's output while it was being
driven by QtMoko (perhaps stopping QtMoko doesn't power the modem off),
and this output contains a smoking gun:
+CREG: 3
The +CREG unsolicited response from the modem indicates its registration
status, and looking up the meaning of status code 3 in GSM spec 07.07
tells us that it means registration denied - aha! So the GSM radio
signal *is* present, but when your FR tries to register to the network
it hears, the network actively denies that registration! Two
possibilities come to mind:
Possibility 1: ATT GSM service went away (either a deliberate service
shutdown, or the tower simply went down for some random reason or
another, and they are in no hurry to fix it because it's 2G which is
only used by outlaws and freedom lovers like us), but T-Mobile GSM is
still present; your FR tries to register with the T-Mobile network,
but the latter rejects the ATT SIM.
Possibility 2: ATT GSM service is still there, and your FR is trying
to register to it because it's got an ATT SIM, but ATT has decided
to reject your FR for some truly nefarious reason, such as an IMEI ban
against an entire range of devices they don't like - I've read stories
on the web about ATT specifically pulling such BS.
See below on my proposed method for distinguishing between these two
possibilities.
%CSQ: 18, 99, 2
%CSQ is TI's non-standard extended version of the standard +CSQ command
and unsolicited response; the standard +CSQ response gives two numbers,
while %CSQ adds a third. I don't fully understand the meaning of the
3rd number yet, but we can ignore it for now. 99 in the 2nd number
position is a placeholder meaning that the modem has no BER information,
but the 1st number is the RSSI: received signal strength indicator.
Numbers like 18 or 15 seen further in your transcript look good to me.
+CIEV: 1, 3
Yet another way by which TI's modem implementation returns the RSSI,
apparently.
The commands 'AT+COPS=?', 'ATE1', 'AT+CFUN=1', 'AT+CGMI' were
entered by me. I'm guessing I should have seen at least a 'OK' or
'ERROR' message, so maybe I'm using socat incorrectly?
Because I am the kind of guy who finds it easier to write his own
program than to learn how to use one that already exists, I've been
using my own ad hack tool called engcons to talk AT commands to the
modem in my Neo FR. The engcons.c source is appended at the end of
this post; you'll need to compile and run it on your FR. Use it like
this:
# stop QtMoko
/etc/init.d/qtmoko-neo stop
# power-cycle the modem
echo 0 /sys/bus/platform/devices/gta02-pm-gsm.0/power_on
echo 1 /sys/bus/platform/devices/gta02-pm-gsm.0/power_on
# run engcons to talk AT commands
engcons /dev/ttySAC0 r115200
Once you do the above, you should be in a state where you can type AT
commands and see the expected responses. Try AT+CGMI, AT+CGMM, AT+CGMR,
AT+CFUN=1, AT+COPS and AT+COPS=?, and post the results you get.
VLR,
SF
engcons.c source follows; this ad hack program was originally written
for some completely different purposes and thus contains a bunch of
crud that will make no sense, but I just reused what I already had
working.
/*
* This utility is used at Harhan Engineering Co. to connect to
* the console ports of various targets in the lab. Most of the latter
* are either MicroVAXen or our own designs inspired by the VAX/MicroVAX
* console, and this program has a few nifty features specifically
* intended for those consoles.
*
* Beyond simple pass-thru of bytes in both directions, the following
* features are provided:
*
* - logging
* - ^P sends a break
* - binary upload via X command
* - changing console baud rate on HEC MC68302 targets (not in this version)
*
* This is the POSIX termios version of the program; the original version
* was for 4.3BSD UNIX.
*
* Author: Michael Sokolov, Harhan Engineering Co.
* msoko...@ivan.harhan.org
*/
#include sys/param.h
#include sys/file.h
#include sys/stat.h
#include sys/ioctl.h
#include sys/errno.h
#include termios.h
#include ctype.h
#include stdio.h
#include strings.h
extern int errno;
int mypid;
int tfd;
FILE *tfdF;
struct termios saved_termios, my_termios, target_termios;
int kbd_eol_state = 1;
FILE *logF;
static struct speedtab {
int num;
speed_t code;
} speed_table[] = {
{300, B300},
{1200, B1200},
{2400, B2400},
{4800, B4800},
{9600, B9600},
{19200, B19200},
{38400, B38400},
{57600, B57600},
{115200, B115200},
{0, 0}};
main(argc, argv)
char **argv;
{
int zero = 0;
struct speedtab *spd;
int speed, rtscts = 0;
char *cp
Re: [QtMoko] GSM not turning on / registering
Nick openmoko-commun...@njw.me.uk wrote: I tried the SIM in another phone and it does work, and another SIM in this one does not (both the same network). OK, good observation. The problem is now narrowed down to the FR, rather than network coverage in your area, your service subscription or the SIM issued for it. There is one more thing we need to check before proceeding further, though. That other phone you used to confirm your SIMs as good, what kind of phone is it? Is it 2G or 3G? If the latter, please look through its menus and see if there is an option to force 2G mode. The reason for this exploration is to eliminate the possibility that GSM (aka 2G) service in your geographical area stopped working, knocking out Free Firmware phones while closed proprietary Apple/ Samsung/GTA04/etc still work on UMTS.. (In the event that some part of the world with a nonzero population of Free Firmware phone users does kill its GSM service, there are two possible ways for us to react to that development: either try to liberate one of the newer 3G+ phones/modems, or build our own GSM 2G network for our own use. If/when this situation ever occurs in my part of the world, I will do the latter, as I consider GSM/2G to be superior to 3G crap both technically and morally.) Assuming that your email TLD matches your location, you are doing this in the UK, right? Do you know if your service provider operates a 900 MHz GSM network, a 1800 MHz one, or both? Revision is: GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11 So Moko11, I guess ;) Any particular reason you have not yet upgraded to leo2moko-r1 aka moko12? While it is very unlikely that performing this fw update will fix the problem, running fw with a published Corresponding Source and a linker map listing will likely be a prerequisite for some of the more advanced troubleshooting steps, so you might as well do it now.. http://wiki.openmoko.org/wiki/Manually_using_GSM [...] That's a good idea. I'm hitting a snag before I get very far, though. Namely that I don't know which process is in charge of the GSM, so which one to kill to stop the phone accessing. According to this web page: http://winterveldt.co.za/leo2moko-p3.html the command you need is: /etc/init.d/qtmoko-neo stop (Whether the intent is to talk manual AT commands to the modem or to reflash it, the step of stopping QtMoko should be the same.) lsof would probably tell me, but I can't install it because it's tough to get the wifi to work (which I generally don't care about). Huh? WiFi? While you do need an ssh connection into the Neo, why does it have to be WiFi? Doesn't QtMoko support eth-over-usb networking like the others? HTH, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GSM not turning on / registering
Nick openmoko-commun...@njw.me.uk wrote: The phone that works is 3G, and it doesn't seem to have a 'force 2G' option anywhere. The option in question often goes by different names: it may also be named network type or network selection etc, with the choices being GSM or WCDMA or both. Try selecting GSM if you can find the elusive option. I'm in the Greater Boston area, Ahh - I didn't realize you were still here in the States - I remember you asking on this list a few months ago about GSM frequency bands in USA, with the intention of traveling to Boston area, but it was back in February, so I thought the trip was over and you were back home in the UK. How long ago have you arrived in Boston? Is the FR-not-working problem something that happened upon arrival in USA, or has it been working for you for a while in this part of the world? so I can't imagine the phone company could just have turned off 2G here yet; there are too many subscribers around. [...] As I said, I'm in the USA now, and I'm on ATT, FWIW. Ahh, so you decided to be adventurous and use ATT instead of the more tried tested T-Mobile. Before we spend an inordinate amount of effort figuring out why your FR doesn't work on ATT in Boston, perhaps you could try a T-Mobile SIM card just as a quick test? If you don't have one, just go into any T-Mobile store and ask them to borrow a SIM for a few minutes to test in your phone while inside their store. Also if there is any chance you might visit California before you go back to the UK, we could meet up and do some GSM hacking together. :) Basically because I just want a dumbphone that works, really, so tend towards laziness regarding my phone nowadays. If you are using your FR as an oversized dumbphone, have you considered using a real dumbphone instead? You might want to grab a Mot C139 on ebay while they are still available - it is one of the models which I am using for FreeCalypso firmware bring-up (along with the Neo FR and Pirelli DP-L10) before building my own dumbphone hardware, and it has the advantage of being a very simple dumbphone with full schematics available (unlike the Pirelli). That Linux application processor on the Neo really adds a lot of extra complexity into the mix, and I find true dumbphones to be much easier to work with, as in hack, troubleshoot and actually use on an everyday basis. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] GSM not turning on / registering
Nick openmoko-commun...@njw.me.uk wrote: I haven't been using my phone much recently, but it's always been reasonably reliable when I have. Today I turned it on, and all day it has just said searching for network. [...] I'm not sure where to go or what to look for to debug this. I've restarted the phone multiple times without success. What modem firmware version is this? Any advice? Since the GSM modem is no longer an impenetrable black box, you could try debugging the apparently misbehaving modem using standard Free Software debugging methods: study the source and the documentation, and make use of the modem debug interface accessible via the headset jack. Start by taking QtMoko high-level software out of the equation and talking AT commands directly to the modem: http://wiki.openmoko.org/wiki/Manually_using_GSM Try the AT commands shown on that wiki page, and tell us the results. That right there might spot an issue. If the modem behavior at the AT command level is that of failing to register for no good reason, the next debugging step would be to look at the debug trace output. Get a debug cable, if you haven't already: http://bb.osmocom.org/trac/wiki/Hardware/SerialCable Put the debug serial channel on the headset jack with this command: echo 1 /sys/bus/platform/devices/gta02-pm-gsm.0/download Make sure the audio is routed to your Neo's earpiece speaker and not the loudspeaker, to avoid damaging the latter or your ears. Plug the debug serial cable into the headset jack, and plug the other end into your PC or other host computer running GNU/Linux or some other Unix. Run the rvtdump utility from the FreeCalypso suite, e.g., rvtdump -l logfile /dev/ttyUSB0 With the serial cable connected, rvtdump running on the other end, and 1 written into that /sys/.../download node, power up the modem. You should get a bunch of debug output; tell us what you see. (The -l option will save this output into a log file, with a timestamp prepended to each line.) You should get more interested debug output when you issue AT+CFUN=1 and AT+COPS commands which start the actual GSM operation; tell us what you see at those steps as well. If the above steps don't reveal anything amiss, next debugging steps would be to examine firmware state variables in memory with fc-tmsh and/or send special commands (called system primitives, enabling more verbose traces and other debug functions) to the running fw with g23sh, both of which are FreeCalypso tools operating via the debug interface (called RVTMUX) presented on that headset jack. If you are running a firmware version such as leo2moko for which we have a linker map file, we can examine every single variable that fw maintains, and the system primitives provided by the GPF component (Condat's Generic Protocol stack Framework) allows us to capture and examine every primitive exchanged between GSM protocol stack layers: e.g., we could see the exchange between L1 and L2, or between RR and MM, etc. But let's see if you can manage the simpler steps above before I go into details of what you should peek and poke with fc-tmsh and g23sh tools - getting the simpler rvtdump working would be a prerequisite for the more advanced tools anyway. HTH, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FreeCalypso progress update
Hello project followers, Just a quick update on where the FreeCalypso project stands. I am still reconstructing the full-source form of TI's Calypso reference firmware, the one which we currently have only in semi-src form, running on TI's Leonardo board and on the GTA02 modem. How can one reconstruct a full source from a semi-src (half src, half objects) in which half of the original source is missing? By finding matching source pieces in other TI source leaks (the Peek LoCosto one mostly) and reintegrating them one by one onto the reconstructed FreeCalypso firmware skeleton. There are a few binary objects in the Leonardo semi-src for which no matching source could be found in any of the available leaks. I am currently working on one of these hard pieces: the OS Adaptation Layer part of the GPF, the thin layer that sits between the Nucleus RTOS microkernel and the higher sublayers of GPF. GPF stands for Generic Protocol stack Framework, and it is the foundation on which Condat's GSM/GPRS radio protocol stack is built. Back in the days when TI actively maintained their firmware for Calypso, LoCosto and other offerings in this family, the GPF code was already so stable and independent of the rest of the firmware that it was distributed and used mostly as binary libraries even inside TI, it seems. Take the LoCosto source for example: all of L1, L2 and L3 code is compiled from source, but GPF comes from *.lib files that are pulled into the build as blobs. But fortunately we've been able to find the real C source for most of GPF. The Leonardo semi-src includes a few pieces of GPF C source despite not actually using them in the build (which uses *.lib blobs instead); the LoCosto find includes the source for some *other* parts of GPF - once again, not actually used in the build which uses *.lib blobs. By putting together the GPF source bits from the Leonardo and LoCosto finds, we now have the original C source for *most* of GPF - and this source has already been integrated into the gcc-built FreeCalypso GSM firmware tree. The thin OS Adaptation Layer between Nucleus and the rest of GPF, and the equally thin OSX layer between GPF and L1, are the only two parts of GPF for which the original C source could not be found. The first out of these two (OSL) is needed in order build a test fw image with GPF included, hence it is the part I'm working on now; the other (OSX) should not be needed until it is time to integrate L1, so I plan on tackling it at that time. I am reconstructing the missing/lost source for the OSL part of GPF from the binary object form, by a process of disassembly followed by decompilation. The disassembly step is automated with a special tool I wrote for this purpose. See the leo-obj subtree in this Hg tree: https://bitbucket.org/falconian/freecalypso-reveng Anyone who wonders just how much info can be extracted from these COFF binary objects is invited to see for herself: hg clone https://bitbucket.org/falconian/freecalypso-reveng cd freecalypso-reveng/leo-obj make Look at the *.disasm and *.ctypes files that will be produced, and revel at all of the juicy C-level symbolic info contained therein. All that stuff has been extracted out of the object blobs; the only inputs to the tiobjd tool are the *.obj artifacts and some really minimal hints in the *.hints files (see for yourselves how minimal they are). Who was it who said (some 2.5 y ago on this list) that the ware in question is nothing more than useless blobs? The next step is decompilation, and it's being done in the gsm-fw/gpf subtree of the other Hg tree: https://bitbucket.org/falconian/freecalypso-sw The gsm-fw/gpf/osl directory contains the C modules which I am reconstructing from the above *.disasm through manual decompilation; the other subdirectories of gsm-fw/gpf contain the rest of GPF, the source for which has been found in the Leonardo and/or LoCosto semi-src. The inc subdirectory contains all of the original GPF header files, used by both the original sources and the ones I am reconstructing. Peruse the two source repositories above to see where the project stands; look at the commit history to judge the pace at which it is going. Viva la Revolucion, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko GTA06
Norayr Chilingarian nor...@arnet.am wrote: Yes, probably because they have this call and sms possibility. Of course they (the carriers) provide call and SMS capabilities, because I, their customer, want these capabilities, and would not be their customer if they didn't provide such! But I am quite sure, in your part of the world they must have possibility to get a plan, where calls and texts are prohibited, Of course you can block whatever you don't like. But giving up these services would not save you any money, because they are already *given away for free*, for zero extra cost. but Internet is unlimited, and just pay for it monthly fee. Yes, the carrier I use (310260) offers unlimited Internet too. But unlimited voice SMS is cheaper, and far more useful to me. Then, if their friends know how to use Internet for calls and texts No thanks, I want no part of that. The quality of a voice connection over bufferbloated mobile data networks is shit (latency in seconds) - I am much, much happier with traditional circuit-switched phone calls. they can refuse from using phones as devices, I don't have much more to say to you except that we shall fight on opposite sides. I *like* using a traditional phone for traditional phone calls, and I will never give it up. like washing machines, You refuse to use a washing machine? Do you wash your clothes by hand in a pond or a river? Where I live, none of the nearby natural bodies of water is clean enough for me to consider washing my clothes there, so I like using a washing machine. designed for specific tasks, in this case - calls via carriers, Yes, and I take great pride in my work to design and build a device that does just one thing: make voice phone calls via those carriers, exactly the thing you are against. and I see carriers gradually would become just an ISP's, not less and not more. Yes, but they still provide the old-fashioned circuit-switched services as well, and if/when they cease to provide these services, I will cease being their customer, and will instead become my own carrier - set up my own GSM network that provides only old-fashioned phone calls and nothing else, *no* data services whatsoever, except for CSD. need to add that the other thing we need, apart from encrypted calls, via gsm, as in your case, or over tcp/ip, as in my case, we need, yes, possibility to change IMEI's Joerg R. and others on this list have already explained quite well the pointlessness of those IMEI changes when it comes to privacy. There is only one good reason to change one's IMEI: if some operator X blocks your legitimate IMEI (or an entire range, like all known freeable phones), and you really need to connect to that network, you can set your IMEI to something that network will accept. and use anonymous SIM cards, The anonymity or non-anonymity of a SIM card (i.e., whether or not you have to show a govt-issued ID when buying or activating your SIM) is a social problem, not one that can be solved by technical means. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko GTA06
Norayr Chilingarian nor...@arnet.am wrote: just would like to mention my needs, and unfortunately I cannot satisfy them with your project. [...] So I don't need a phone, but a mobile computer [...] Then my project is not for you. It is for those who specifically want a plain old cellphone (dumbphone) and not a mobile computer. I already have a mobile computer which I'm reasonably happy with - it's a Lenovo X200 ultraportable laptop, running Slackware. But when it comes to my cellphone, whether I use my old Mot V66 (unknown chipset) or the Calypso-based C139 or Pirelli DP-L10, I am currently limited to running Mot's or Pirelli's original proprietary firmware sans source, with no ability to fix bugs or to tweak the UI design to my taste. I am very unhappy with this status quo, hence I am working to fix it in a way that is within my ability: by reconstructing TI's standard fw for modems and dumbphones from pieces (Leonardo+LoCosto+misc) and making it run on the Calypso-based GSM devices I have available. The related project of building a new Calypso-based dumbphone is primarily in response to the exhaustion of the surplus supply of ready-made devices. If there were an infinite supply of Pirelli DP-L10s with full schematics and with docs for that darned SPCA552E chip, or of Mot C139s with unlocked bootloaders, there would be little need to build new hw. But the Pirellis are no longer available, and even the stash I already have is of limited usefulness because this hw is cripped by the lack of schematics and by those extra chips w/o docs. Mot C139s are still somewhat readily available, but they are crippled by the boot ROM being disabled at the board level, so we have to rely on the original fw's bootloader instead. If you buy a C139 on ebay, it will be a gamble whether it arrives with a firmware version that features an unlocked bootloader, or one which allows no known way of loading our own code into the device. Hence I plan on getting FreeCalypso fw running on a C139 and/or a Pirelli as a proof of concept, then switching my attention to the design of a new Calypso dumbphone free of Mot/Pirelli's design flaws. Current status of the project: I've got the tool I wrote that parses TI's COFF objects and produces disassembly listings which take advantage of the symbolic information present in these objects (like objdump from binutils, but more specifically taylored to TI's COFF objects made by the TMS470 toolchain), and I am now working on integrating GPF into my gcc-built FreeCalypso fw. After GPF we'll have L1, and then the bulk of the GSM protocol stack, yay! Also, routing voice traffic through the Intrenet is a way to not be obliged to pay to carrier per minute or per text message. So you would rather pay those same carriers per kilobyte instead? I don't know how things stand in your part of the world, but here in USA the carriers only want to sell mobile data services while giving voice and SMS away for free - so it is the direct opposite of what you are picturing: old-fashioned voice calls and SMS are free here, whereas Internet packet data costs $$$. I think that carriers earn too much money just because not all the people still used to Internet. But it's the other way around - those mobile Internet users are the ones feeding the carriers' revenue stream, while outlaws like me who eschew all that packet data crap and use old-fashioned circuit-switched GSM services (yay CSD!) essentially get a free ride on that carrier! I believe, if we get Internet, then we can manage the rest without carriers. But why?? I *like* getting a free ride on my GSM carrier at the expense of all those fools whose sky-high mobile Internet bills pay for the upkeep of the infrastructure. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko GTA06
Dr. H. Nikolaus Schaller h...@computer.org wrote: I have received a rumor that somebody is working on a truly free and open phone This part is in fact true. with the following specs: But the specs you have in mind are wrong. * Quad-Core Intel Z3770D (1.5 - 2.5 GHz) Nope, it's an ARM7TDMI @ 52 MHz, chip made by TI, codename Calypso, from TI's Greek mythology series. * 4GB RAM Don't need that much; 8 MiB of pSRAM (combined with NOR flash as part of the S71PL129NC0 MCP by Spansion) is way more than enough for a good phone. (For comparison, the Motorola C139 I'm currently playing with makes do just fine with only 512 KiB.) * 128 GB eMMC Again, unnecessary complexity and bloat. Mine will have 16 MiB of NOR flash instead: S71PL129NC0 provides two flash banks of 8 MiB each; one will be for the firmware (execute in place), the other for user data storage. (For comparison, the user data flash partition on the C139 is only 320 KiB.) * LTE with free and open baseband GSM, not LTE - much better for plain old voice phone calls, which is what a *phone* is for. But the free and open part is absolutely correct! * 5 inch full HD display Unnecessary for a phone. I plan on using a 128x160 pixel 1.77 color LCD (TFT), which is quite luxurious compared to Mot C139/V66/etc. * 100g That sounds about right. * 4000 mAh battery Not sure if I can get a battery with such capacity, but because I'm using TI's source code with proper power management (unlike OsmocomBB), even a 1000 mAh battery can last a good while. * runs any x86 OS (i.e. Linux, Windows, Hackintosh, ...) It is beyond me why would anyone in his or her right mind want to run such complex, bloated and unreliable software on a *phone*, a device whose primary purpose is to provide ultra-reliable voice communication when all else fails, including emergency communication for potentially life-threatening situations. * shall cost less than Nexus 5 The very limited number of units I will physically produce myself will probably have a very steep price tag, but unlike you I'm going to put the gerber files, BOM and everything else on ftp.ifctf.org, so any community member will be able to produce it herself at whatever price her chosen PCB fab + parts suppliers + assembly house + RF calibration lab charge. Looks like some dream machine :) You and I have different dreams. Oh, and if someone were to build your April Fool's device for real, it should NOT be called GTA-anything, because it is not GSM-TI-AGPS. I am not calling my Free Dumb Phone GTAxx either - while the 'G' and 'T' parts are true for my design, the 'A' part is not. I do like the 3 letters + 2 digits model naming scheme, but my letters won't be GTA. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FSO project hosting (mailing lists, ...)
Quick update: I have gathered the old subscribers’ list and have invited (not autosubscribed) all former members. If you are not among the invited and have interest to participate on the future of the FSO middleware stack, then please feel very welcome to join f...@openphoenux.org Best regards, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM frequency bands in the USA
Nick openmoko-commun...@njw.me.uk wrote: It's interesting to hear that 850MHz is a quite recent addition, Just keep in mind that my idea of recent is within the last 10 y, at least in this case; most other people's definition of this word probably means a shorter time span. :-( All I know is that back in 2003 phones sold in USA with carrier branding were typically 1900 MHz only; I don't know when 850 MHz support began to be considered as a requirement. Of course all those proprietary 3G+ smartphones (Apple/Samsung/GTA04/etc) which we are all surrounded with typically act as quadband when they go into 2G compatibility mode, but because they are proprietary black boxes, only Cthulhu knows which band they are using and what is the total set of signals they hear across their supported bands. So I still don't know for certain to this day what GSM services, if any, exist in the 850 MHz band in my area. thanks, that makes me feel even more confident about my GTA02's chances. I wrote earlier that I only use T-Mobile USA. That status still holds, but earlier today I did an experiment: I walked into an ATT retail store with one of my Pirellis (900/1800/1900 MHz only, no 850, just like EU-Freerunner), got a test SIM from the guy in the store (he pulled it out of one of their demo phones), and inserted that random ATT SIM into the Pirelli. After displaying Searching... for a little while, it worked! The display read Cingular - so now we know that the operator name decoding table in Pirelli's fw is the same as the one we've got in our sources. :) Going into the Engineering mode menu confirmed that the actual network in this case (ATT in Southern CA) is 310410. A test voice call worked fine too. So now we know that *both* GSM networks in USA (or at least in SoCal) work OK with FreeCalypso GSM phones - although I would still recommend T-Mobile to non-adventurous users, simply because it's been tested a lot more extensively, including fun things like CSD. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko's downfall (was changing IMEI)
Radek Polak pson...@seznam.cz wrote: But there are other points of view. E.g. some people expect the phone ring when friends/wife/customer calls. Yes, that's exactly what I seek out of my cellphone too. And that is why I require having the source for all sw/fw involved in this telephony function, so when it breaks, I can debug and fix it myself, long after the original manuf has gone bye-bye. I had many phones before and 2 phones after (N900 and now Jolla). None of them had any problems with SMS and telephony. My experience is different. Until about a year ago, my true trusted phone was Mot V66 (a flip phone which I first got in 2003 if my memory serves me right). It mostly worked, but every now and then I would notice the coverage status LED flashing red instead of green - I would then open the flip to see what's going on, and the display would read Unregistered SIM. The only way to get it out of that wedged state was to cycle the power; doing the latter would immediately show perfectly good coverage with high signal strength - so it is obviously a case of the fw getting stuck in some wedged state, rather than the GSM network, although I reason that the triggering cause is likely some network transient event. This is on T-Mobile USA, Southern California, 1900 MHz GSM band. About a year ago I switched from this Mot V66 to the Calypso-based Pirelli as my everyday personal phone. Still running Pirelli's original proprietary fw for now - getting FreeCalypso into a state where it can drive a complete dumbphone rather than a mere modem is a big project still in its infancy. But it is still a freedom increment over the Mot V66, as now I have a full understanding of the GSM chipset I am using (the one in the V66 is something unknown to me), and because the original proprietary fw is TI-based, there are plenty of things I can poke at with my FC tools. And guess what, Pirelli's proprietary fw exhibits the same strange behavior with the phone inexplicably going out of service until rebooted - but instead of Unregistered SIM, the LCD simply reads GSM no service, just as if I went into a Faraday cage - except that the GSM signal is perfectly fine, as the phone itself indicates when I reboot it. So it is the same case of the fw stuck in some wedged state. I don't know if the GTA02 modem running moko11 or leo2moko suffers from the same bug or not - it manifests rarely enough that one needs to be using the phone on an everyday basis to catch it. Openmoko is different - they never provided SW for reliable phone. [...] And even 5 years after there is no good kernel for Freerunner. And why has no one in the community produced such a good kernel in all these 5 years? One probable reason is because the brightest and most talented kernel hackers, those most qualified to produce such a kernel, have left this community in frustration (moved on to other life interests and pursuits) when no liberated/NDA-broken GSM fw appeared. 2013-10-13 04:08:54 CEST came a little too late, I'm afraid - by that point all those best and brightest have already departed this community for good, doing something else for fun in their lives. 2.6.29-rc seems quite stable but the patch against mainline is horrible, besides it's power management is worse then it could be. 2.6.39 has hardly nearly unreproducible problem with resume. Now we have free firmware which is cool, but the usablity of the phone hasnt changed much. Hearing stories like this (both now and during the 2y I spent looking for the TI fw deliverables) helped convince me that I would be better off spending my time building a free dumbphone with no Linux at all, rather than whipping GTA02 Linux AP software into shape so it could function as a poor man's imitation of a dumbphone. Dr. H. Nikolaus Schaller h...@goldelico.com wrote: I invite every = remaining Openmoko GTA01/02 owner to cannibalize their device for a = GTA04A5 motherboard. There is a special place in Hell reserved for murderers of good free hardware like you. joerg Reisenweber jo...@openmoko.org wrote: A question to Michael S.: the heck which dang NDA are you talking about? Whichever NDA it was/is that is cited by a bunch of Om wiki pages as the reason for GSM modem fw not being free like the rest of the device. OM allowed all reasonable individuals access to all the docs and specs and schematics we ever had, on request Many were probably too timid to ask, or saw no point in getting such privileged access, reasoning what good would it do for me to have access to that shit under NDA if I can't freely share it with the world and hire any programmer of my choice to troubleshoot odd issues which I lack the skills to figure out myself... In any case, it's a solved problem now; the total collection of docs plus 4 different source versions in my GSM mini-Wikileaks is probably greater than what you ever had, so no more demands or threats from me. :) But it's hard to refrain from
Re: GSM frequency bands in the USA
Nick openmoko-commun...@njw.me.uk wrote: I'm going to the USA soon, Do you know which part of USA? and would ideally like to use my GTA02 there. It is a European 900/1800/1900MHz version (I presume - I bought it 2nd hand - is there an easy way to check?). As others have said, look at the sticker inside the battery compartment. It's the only way to tell, there is no software-based way: as discussed on this list earlier, with the standard /gsm/com/rfcap setting from Om the modem has no knowledge of which version it is, believing itself to be quad-band instead. Can I just use any network in the USA, In the part of USA where I operate (Southern CA) there are only two GSM networks: 310260 (current marketing name T-Mobile USA, used to be VoiceStream) and 310410 (current marketing name ATT, used to be Cingular - the decoding table in our GSM firmwares still calls it Cingular, BTW). All of my current/recent experience is with T-Mobile; the last time I used the other network was some 11-12 y ago, back when they were Cingular. If you come to Southern California, I can confirm that you can go to any T-Mobile retail store, buy a SIM card, plug it into your GTA02 (mine is exactly like yours), and it will work. (For me it works with *both* the original factory IMEI and the one I made up for testing. :) If you decide to try the other network (ATT), you'll be venturing into so-far-untested territory, and contributing new knowledge. :) and it will just register with the 1900MHz band Yup, that's the band I've been using here for all my cellphone-using life. I have yet to use a phone with 850 MHz capability - this secondary USA band is a relatively recent addition (a spectrum reallocation from AMPS, it seems), and back in 2003 when I got my first Mot V66 (the subsequent ones have been from ebay), all phones officially sold in USA with carrier branding were 1900 MHz only or 900/1800/1900 MHz world phones like that Mot V66! Again, this is with a T-Mobile SIM card, connecting to T-Mobile base stations in the 1900 MHz band - no idea what the picture looks like for ATT. HTH, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openmoko's downfall (was changing IMEI)
openm...@pulster.de (Christoph Pulster) wrote: I remember adverts of Openmoko in capitals 100% FREE mobile. that this was a false promise comes evident afterwards. I wonder how many people forked over their $$$ for those expensive Openmoko phones primarily in the hope that the bloody NDA would get broken by someone in a year or two, and were utterly disappointed when that didn't happen. I am convinced that the number is quite large, and the only thing that made me stand out is that I *voiced* this sentiment openly, without beating around the bush. I am also convinced that the *real* reason why Openmoko = failure in the general public's perception is precisely because of that NDA and no one having broken it during the years when it mattered the most. The Freerunner became truly free only on 2013-10-13, some 5y (or is it 6y?) after its introduction and 4y after cessation of production, at exactly 04:08:54 CEST, the date of this announcement: http://lists.openmoko.org/pipermail/community/2013-October/069010.html Prior to that announcement, i.e., at 04:08:53 CEST and for the 6y of Om community history prior to that, the Unfree-runner was a proprietary phone no different from anything out of Motorola, Samsung or Apple. But I'm afraid that the liberation came a little too late: I keep hearing the number 15k units made and sold being tossed around, but of those 15k units, after we subtract those which were cannibalized for plastic parts to stuff nasty Qualcomm modems into and those which got repurposed for some non-telephony uses, I suspect that the remaining ones are probably buried some place deep, forgotten by their owners who gave up on them when a few years passed after Om's disbanding, and yet no free GSM firmware emerged. Oh, and to add a little feminine perspective on the matter, when I told the Openmoko story (100% FREE mobile phone! - oh, oops, no, not the cellphone part) to my lady, her reaction was it would be like me saying I am only half-pregnant! I would argue that Om's biggest mistake, the one that led to their downfall, was the silly half-pregnant attempt to do it legally. It should have been done as a 100% explicitly-illegal black market operation instead. Hiring law-abiding Germans to run the show was the #1 mistake - the operation should have been run by the Chinese/Taiwanese instead. Contrary to what has been said, they did NOT have to sign the NDAs as they did - surely if the show were run by Chinese/Taiwanese without a single German on staff, they could have simply used the warez floating around that giant country. (As just one data point, the TSM30 source - *full source* - was published in 2004, at least 2y before Om came onto the scene.) The Calypso etc chips are easily sourceable on the grey market: some legit company buys 100k chipsets from TI, makes 90k phones, the remaining 10k chipsets sell on the grey market w/o unnecessary questions. The physical production of phones should have been done in some unmarked basement without any legit company attached, so there would be no one to sue, and the distribution (sales) should have been done through the same channels used to market and sell alternative medicine products like cocaine and heroin. But oh well, history is what it is. the knowledge about NDA restrictions of GSM components is still today only in some geek's mind. Huh? I'm afraid I don't follow what you are saying here. The GSM mini-Wikileaks collection at ftp://ftp.ifctf.org/pub/GSM/ now has *everything* related to Calypso and other related chipsets from TI, probably more than Om ever had. The documentation for the actual hardware components has been on my FTP site since the fall of 2011 (downloaded from 52rd.com where it had been available to those who can navigate in Chinese for much longer), and we now have TI's TCS211 fw deliverable semi-src no different from the one Om had, if we make the reasonable assumption that all of TI's chipset customers got identical or near-identical fw starting point deliverables. We even have an equivalent TI deliverable (hw docs + fw semi-src) for their LoCosto chipset (one of Calypso's successors), and while I have no desire to use LoCosto instead of Calypso (LoCosto has some freedom- reducing improvements), the LoCosto semi-src is something like 95% real C source (unlike the TCS211/Calypso/Leonardo one on which the current leo2moko port is based), hence I plan on using chunks of code from the LoCosto source to replace some of the binary-only libs in the TCS211 version. So the liberation part of the FreeCalypso project is now 100% done; what remains now is the (quite hard) purely technical work of reintegrating all of the pieces back together to build the fw using gcc without any Weendoze tools or blobs. As long as there are big players like government and companys, a 100% open mobile will never happen. Never. Of course it will never happen legally, but so what? We can build it illegally instead. Building an
Re: Openmoko's downfall (was changing IMEI)
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: You are a Pied Piper of Hamelin. I don't mind the role. Check out The Stolen Child, poem/song by William Butler Yeats - I particularly like this rendition: http://www.elvendrums.com/cddragon.php VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Focus of development [was: IMEI changing kit for GTA02]
openm...@pulster.de (Christoph Pulster) wrote: Besides legal issues, I miss the thanks to Michaels effords. Thanks, I appreciate the change in attitude from this previous post of yours: : From: openm...@pulster.de (Christoph Pulster) : To: community@lists.openmoko.org : Subject: Re: Building a new totally free phone : Date: 23 Aug 2013 11:54:00 +0200 : : just because something is illegal does NOT automatically mean that : it's bad : : Just because something is illegal does not prevent it to be crap. : You are not interested to built helpful hardware, but enjoy your : erection being a self-called outlaw. Have fun with it, but no applaus : from my side. For some reason that 2013-08-23 post is not visible in the web archive at http://lists.openmoko.org/pipermail/community/2013-August/date.html - perhaps your use of the word erection triggered some filter? but concerning technical effords, he was very insistant and pushed it as far as writing a tool for easy change of IMEI Just in case it isn't already clear, that IMEI change kit came about merely as a *side product* from my main work seeking to produce a better-than-OsmocomBB totally free GSM phone firmware. In TI's fw architecture, the actual GSM code runs more or less as an application on top of a quite rich RTOS environment, and getting this RTOS environment (by which I mean not just Nucleus, but also RiViera, RVT, FFS, ETM and other components) fully working and fully under our own control is a prerequisite for tackling the actual GSM code. This RTOS environment just happens to include a full-featured Unix-like file system (TIFFS), so naturally tools are needed to operate on this file system. The IMEISV is just one data item stored in TI's GSM device file system, and because of its forbidden fruit status, a lot of people have been asking for a way to edit it freely, hence it was quite natural to take several FreeCalypso tools (written for the primary purpose of free GSM fw development and debugging) and string them together into a very hacky kit for editing the FFS on GTA01/02 modems. without having full access to NDA-infos. The 4 TI source leaks on which my work is based are TSM30, LoCosto, MV100 and Sotovik, in the order of discovery/liberation. The real thanks go to those who have brought all of these leaks out into the public - as Comrade Stalin said, the country needs to know its heroes. But in the case of TIFFS specifically, I didn't have a source for this fw component until the MV100-0.1.rar find, and believe it or not, I actually reverse-engineered that FFS format on my own (by staring at hex dumps of flash read out of my GTA02 and Pirelli phones and reasoning how one would implement a writable FFS given the physical constraints of NOR flash) just a few days before I found that MV100 source leak! Matthias Apitz g...@unixarea.de wrote: I use my GTA02 FR as my daily phone, running a SHR from 2012. I have no other cellphone [...] i.e. I _highly_ depend on working phone features (call, SMS). And IMHO this should be our primary focus for an OpenSource cellphone, Just in case I haven't already made it fully clear, that is exactly the focus of my work. The IMEI change kit was/is merely a byproduct made by stringing together the tools which were written and are needed for main GSM fw development. because my FR sometimes fails in accepting calls, often fails in receiving SMS, not always works up from suspend, the people I call are blaming me for my poor voice, etc. With the current leo2moko firmware, I am quite confident that the GSM modem in the FR works the way it should, no major flaws. The fw in question does have a bunch of binary blobs in it, making it very hard to modify some things until we deblob it, but even these blobs are in the form of COFF objects with full symbolic information, parsable with the objdump utility from GNU Binutils built with the needed patch, so while having very limited ability to modify them at the present moment, we can still examine these blobs with a high level of transparency. And as you can probably guess, I have already examined these blobs quite extensively, and hence have a high level of confidence in the quality of the fw. So with the modem no longer being the black box which automatically takes the blame for any and all problems with phone functionality, the finger of suspicion now points at the Linux application processor software on the FR. In my opinion, the problems which reduce the usability of the FR as an everyday cellphone stem from the unnecessary complexity of the Linux AP. If all I want is a cellphone for making and receiving phone calls (plus SMS), why in the heck should I have to deal with the enormous extra complexity of a Linux computer built into that phone? As some may remember, which I first joined this mailing list in the fall of 2011, just before I got sidetracked for 2y to deal with the Closedmoko muck, my intent was to write a
Re: Focus of development [was: IMEI changing kit for GTA02]
Nick openmoko-commun...@njw.me.uk wrote: Any more hints as to what additional freedom enhancements you have planned? * Pirelli DP-L10 has a bunch of extra chips supporting the WiFi/VoIP and camera functions, chips for which there are no docs. I won't be using any chips without docs in my design. The WiFi/VoIP function is something I have no interest in at all (thus no plan of providing any hw for that), and the first version won't have a camera either. * The RF front end in my design will be quad-band; Pirelli is tri-band (2EU+1US) just like Om. More GSM bands = freedom to travel to more parts of the world with the device. * I plan on connecting the USB-serial chip (probably CP2102, same as Pirelli) to Calypso's MODEM UART, i.e., the more hw-capable out of the two. In the existing Pirelli hw it is connected to the IrDA UART, i.e., the less capable one. I would like to offer both RVTMUX and the traditional AT command interface over this USB-serial port, and TI's code wants to use the MODEM UART for CSD, not IrDA. (Pirelli's fw does not provide an AT command interface, only some proprietary i/f for their Weendoze PC software, built on top of TI's RVTMUX.) HTH, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IMEI changing kit for GTA02
joerg Reisenweber jo...@openmoko.org wrote: I have no idea, I took care about GSM firmware only much later. But I think until the point in time when I was able to contract Dieter Spaar for OM, there been significantly less knowhow about all that stuff inside OM than what you demonstrate here. Hehe. It looks like my effective taking of the stewardship of this modem firmware is not such a bad thing for the community after all. :) Or at least for what's left of the FR user community... I wonder though how Dieter acquired that knowhow back in the day - did he previously work for some other modem or dumbphone manufacturer that used TI chipsets? Or maybe even for TI-Berlin (former Condat GmbH) or somesuch? And the whole stuff been even temporarily considered lost forever, thanks to reformatting of a laptop HDD (iirc). Ouch! Also see bug # 666 which got fixed in moko5 but evidently the patched lib TI provided for that got dropped for no reason in later fw versions, until Dieter noticed that and included it again in Moko9-Beta1 Stories like this make me wonder how many other bugs of similar nature might still be lurking in those closed binary libs. That is one of the reasons why I seek to produce a hybrid Calypso fw by combining the RTOS environment / drivers / BSP pieces from the TCS211 source (the one leo2moko was built from) with the GSM stack source from the LoCosto find - it will give us a fully functional modem fw without any binary blobs! Whoever originally liberated the TCS3.2 (LoCosto) source which I found at http://scottn.us/downloads/peek/ in 2013-05 (through a Google search!) is a real hero. If it wasn't for this leak, the only C source we would have had for the core GSM stack would have been the TSM30 version from 2003, i.e., a definite backward step from the TCS211 version given in binary form to FIC, Foxconn (Pirelli DP-L10) and a bunch of others in the 2007 time frame. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
IMEI changing kit for GTA02
Hello fellow freedom lovers, I have just released the first version of the kit that allows a Neo Freerunner user to set his/her IMEISV to any value of his/her choice. Download it here: ftp://ftp.ifctf.org/pub/GSM/GTA02/ffs-edit-kit-r1.tar.bz2 Operating instructions are inside the tarball. The way in which this kit works is completely independent of what firmware version you have in flash: it can be moko11, leo2moko, or even blank or corrupt flash. (Just like with fc-loadtool, the chain starts with Calypso's on-die boot ROM, i.e., the wonderful hardware unbricking feature TI gave us in this baseband chip, similar in principle to FR's NOR U-Boot which is extra hardware just for unbricking.) Please also note that many vendors' standard proprietary firmwares include undocumented AT commands for setting the IMEI, and as my experiments indicate, moko11 appears to be one of them: ftp://ftp.ifctf.org/pub/GSM/hacks/imei-hacks-r1.tar.gz However, I do not recommend using that AT@SC command, as the half-baked implementation does not make the proper distinction between IMEI and IMEISV, and the last 16th digit of the complete IMEISV (which is what the modem actually uses and sends over the air) ends up being set to a random value that is an artifact of the obfuscation scheme. As an example, the original factory IMEI of the GTA02 I use for FC development is 35465101-961584-0; the original factory programming of the complete IMEISV is 35465101-961584-00. However, if one uses that AT@SC hack to change it, it is then impossible to revert the complete IMEISV back to this original setting using the same AT@SC command! If one feeds the correct obfuscated AT@SC string for setting 35465101-961584-0, the full IMEISV gets set to 35465101-961584-01 instead of the original factory 35465101-961584-00. In contrast, the FFS editing kit linked above allows you to set all 16 digits of the IMEISV to whatever you choose; the kit provides the mechanism and you decide on the policy for what the SV digits should be. However, considering that those with a desire to play with their IMEIs would probably find an AT command much more convenient than the rather cumbersome (albeit powerful) XRAM-agent-based mechanism presented in my current kit, I plan on making a new version of leo2moko that will include a new AT command for setting the IMEISV. I will not be replicating the obfuscated AT@SC command, instead it will be a different AT command that sets all 16 digits explicitly and works without any obfuscation. The syntax I propose is: AT+SIMEISV=1234567890123456 If anyone has an argument for a different syntax, please speak up now. Viva la Revolucion, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IMEI changing kit for GTA02
joerg Reisenweber jo...@openmoko.org wrote: you recall that single line I actually censored? http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt line 60, I assume. (Must have been the only time in my life I did this) In the changelogs, around moko5 or something. Considering the time proximity between this hack and the moko5-moko6 change in which you (not you personally, but the company) went backward from the sensible approach (used in most other TI-based products too) of storing configuration items in FFS to the non-sensible approach of hard-coding them in the fw, let me make a guess: the crappy Weendoze- only host tools for development and production which TI gave you (for FFS programming in this case) were unreliable, and you were looking for a way to avoid needing to do any FFS programming through the RVTMUX interface (TI's official way) at all. Of course the IMEI is one item which can't be hard-coded in the fw, and if you didn't want to (or couldn't) use the proper RVT/ETM-based method of programming, then you had to hack in some other way, such as a special AT command. But I assume that the issues with TI's production testing and programming tools must have been solved in time for GTA02A7 mass production, as my unit came with a /pcm/IMEI (IMEISV really) setting which cannot be programmed via that AT@SC hack, only via the proper RVT/ETM channel. I also find it cute that all mass-produced GTA02 units (at least the 4 that have been liberated so far: mine, David's, Norayr's and Giacomo's) came with a few files in FFS (/pcm/CGM[IMR]) which are not used by any of your fw's from moko6 onward, only by moko5 - surely flashing a GTA02 back to moko5 is NOT recommended (I even remember seeing admonitions somewhere to never do that), yet those files seem to be there just to support those people who might do that... Wasn't it your inability to write these strings into FFS reliably that made you go back to hard- coding them? When I made leo2moko from TI's standard Leonardo baseline, I had to add a bit of extra code to display these CGMI/CGMM strings with some extra wrapping around them. If one were to run TI's totally vanilla code on a GTA0x modem with this MokoFFS factory programming, something in their ATI layer gets confused because apparently it expects the strings to be wrapped in angle brackets, but the strings featured in /pcm/CGM[IMR] in factory-programmed MokoFFS don't have those angle brackets. Oh well, history is what it is. It actually been a weird secret AT command to change the IMEI, it claimed in changelogs that it had some really weird formula to add birthday^5 to old IMEI or sth and append that to the new IMEI, for authentication - and it never worked afaik. So I assume we are in agreement then that this secret AT@SC command is NOT recommended for use? Anyone who needs to change their IMEI for some good reason (because they need to be ultra-anonymous when going from one disposable prepaid SIM to another, or because they need to use some GSM network that wrongfully blocks their FR's factory IMEI) should use the kit I have just published. This method does work - I've tested it on T-Mobile USA :-). VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TIFFS in vitro analyzer tool released
Giacomo 'giotti' Mariani giacomomari...@yahoo.it wrote: Here we are: # diff -r michael-ffs my-ffs Thank you for these diffs; explanation follows inline. Binary files michael-ffs/Test/Production.bin and my-ffs/Test/Production.bin differ Yup, expected - if you hexdump this file, you'll see that it contains, among other things, the non-IMEI serial number which Om/FIC assigned to each Neo unit. Incidentally, these files under /Test (Production.bin and Teststate.bin) are neither written nor read by the modem firmware (any version); they were written by the factory production line and remain as decorative relics afterward, not actually used by the fw for anything. (Kind of like your belly button - serves no real purpose except to remind you how you came into being. :-) Binary files michael-ffs/gsm/cops/operimsi and my-ffs/gsm/cops/operimsi differ This file gets frequently rewritten during normal operation of the modem; it contains the IMSI read from your SIM card and some other info I have yet to understand. Regarding the flash dump on my FTP site, I read it out of my FR's modem before I put any SIM into it, so whatever IMSI-related info is in that image, it must be an artifact of testing or whatever by the manufacturer/distributor/etc. Binary files michael-ffs/gsm/l3/rr_white_list and my-ffs/gsm/l3/rr_white_list differ I have yet to learn what these files under /gsm/l3 are for, so I don't have much to add currently. However, I do know that these files get rewritten by the modem quite frequently in normal operation, so they are definitely in the dynamic state category, not factory-programmed data. diff -r michael-ffs/gsm/rf/afcdac my-ffs/gsm/rf/afcdac [...] Binary files michael-ffs/gsm/rf/tx/levels.900 and my-ffs/gsm/rf/tx/levels.900 differ These are the interesting ones: all files under /gsm/rf are calibration data recorded at the factory and never changed afterward, so the diffs we are seeing here are the measured physical variations from one produced unit to the next. The next natural question here is how great or small these differences are, i.e., the magnitude. To answer that, we need to look at the actual content of these RF calibration files. They are all binary, and are read directly into RAM data structures belonging to the Layer1 code in the firmware. I will give these structures their deserved scrutiny when I reach the point of deblobbing the L1 code and integrating it into my gcc-built FC GSM fw - IOW, not yet. In the meantime, I think it would be a good idea to collect the content of this /gsm/rf directory subtree from as many Neo units as possible - understanding the actual magnitude of per-unit differences in these calibration values would help us provide the best possible recovery for anyone unlucky enough to lose their FFS, and may also give us an idea as to what to expect in this department when the time comes to build new FreeCalypso phones and modems. Because all files under /gsm/rf are written only on the factory production line and not afterward, there is no personal information in there: nothing read from your SIM(s), no history of network connections or the like, and no IMEI or other identifying numbers, just measurements of physical process variations. Therefore, there should be no privacy problems in publishing this data. If you would like to contribute your RF calibration data to public knowledge, you can make a .tar.gz from your extracted /gsm/rf subtree (just that subtree, don't include any other directories which may contain private personal info), send it to me, and I'll put it on ftp.ifctf.org - I'll make a new directory for this calibration collection. Oh, and inside that tarball, add a note indicating whether the unit in question is a GTA01 or a GTA02, and whether it is the 900+etc or the 850+etc frequency band version. To repeat: if you choose to do the above, be sure to extract the content of your FFS with mokoffs xtr and then make a .tar.gz of just the /gsm/rf subtree - you probably do NOT want to publish your complete raw flash dump, as there's a lot of personal info that can be extracted from a complete FFS image. Binary files michael-ffs/pcm/IMEI and my-ffs/pcm/IMEI differ Obvious. Binary files michael-ffs/pcm/IMSI and my-ffs/pcm/IMSI differ Same deal as with /gsm/cops/operimsi seen earlier. Binary files michael-ffs/var/dbg/dar and my-ffs/var/dbg/dar differ This file appears to be rewritten every time the modem boots up. But TI's DAR component (Diagnostics And Recovery) is coming up next to be integrated into the fledging FC GSM fw source, so we will understand this file very soon. :-) Glad to help. I hope this gives you some information :-) One part which I have yet to learn is how the SMS receiving path works. It seems to me that when the network delivers an MT (mobile-terminated) SMS to the mobile, the modem has to store that SMS on its own and acknowledge receipt to the GSM network before it can pass that SMS
Re: TIFFS in vitro analyzer tool released
Giacomo 'giotti' Mariani giacomomari...@yahoo.it wrote: It's been easier than expected: root@neo:~# . /opt/qtmoko/qpe.env root@neo:/root# /etc/init.d/qtmoko-neo stop root@neo:/mnt/nfs/root/ModemFFS/Backup# fc-loadtool -h gta02 /dev/ttySAC0 [...] root@neo:/mnt/nfs/root/ModemFFS/Backup# /etc/init.d/qtmoko-neo start Nice. :-) Now I'm looking at it with mokoffs :-) Because my sample size so far has been 1, I would like to know how the FFS content on other FR units differs from mine. I would appreciate it if you could do a mokoffs xtr on your FFS image, then do the same on the image from my FR (from my FTP site, URL posted earlier), and then let me know what diff -r between the two extracted trees shows. David Matthews m...@dmatthews.org wrote: That's interesting - and it worked without a cacophony as accompaniment? I repeat: if one does not do 'echo 1 /sys/bus/platform/devices/gta02-pm-gsm.0/download' which is not necessary when running loadtools from the AP (but is necessary for the cable method), then the cacophony cannot occur. I just tried to confirm this myself; using the cable method it does not work for me on Qtmoko 54. I had the same problem using SHR and following the instructions that Norayr posted, but again using a cable rather than running loadtools on the phone as he did. Have you ever tried troubleshooting it like I suggested earlier? I.e., take loadtools out of the equation for a moment, run a standard terminal emulator program like minicom on the PC end of the cable, then try echo'ing '1' and '0' into the 'power_on' node in sysfs and see if the RVT output appears/disappears in response? VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fun with IMEI (was testing the free calypso software)
=?UTF-8?B?S2FpIEzDvGtl?= kaitobiaslu...@googlemail.com wrote: thanks to the recent activies I also thought about IMEI yesterday evening and it was fun that other's also did. Setting IMEI would still be a nice feature. A general purpose FFS editing kit for GTA01/02 modems, which will include the ability to set the IMEISV to whatever you like, is coming soon - be patient. (Or if you are impatient, feel free to follow the project as it happens in the Mercurial repository on Bitbucket.) Yes, I said IMEISV, not just IMEI - if you don't know the difference, read it up on Wikipedia etc. Even though the file in TI's device file system is named /pcm/IMEI (at least on older modems like Om's which don't use the so-called IMEI protection), the number it actually stores is the IMEISV. The file is (or should be) exactly 8 bytes long, storing the 16 digits of IMEISV, two digits per byte, and the GSM protocol stack into which this number is fed (by way of a function called cl_get_imeisv(), grep for it in the leo2moko source) treats the last two digits (stored in the last byte) as the SV field, not the Luhn check digit. That being said, it looks like both Openmoko/FIC and Pirelli/Foxconn set the SV field of their factory-programmed IMEISV numbers to x0, where x is the Luhn check digit for the IMEI part, such that one can cheat: take the 16-digit IMEISV, drop the last digit, and treat the remaining 15 digits as if they were the classic IMEI. (Such cheating is what my current leo2moko implementation of the AT+CGSN command does - I made it match Om's functionality before I realized that /pcm/IMEI is really IMEISV.) A more reliable way to retrieve the complete IMEI information on any TI-based modem is to issue an ATD*#06# command: it will return a 17-digit number consisting of the 14 digits of the IMEI proper, the Luhn check digit, and the 2 SV digits. In addition it would be interessting for me (in times of surveillance) whether silent sms (stealth ping) could be recognized and a report be dropped to the mobile phone. Also the change to non-encrypted transfer would be a similar event which might occure due to an IMSI catcher, so generating a message (SMS?) warning the user would be helpful. Before we can implement the alerting functions you are asking for, we need to liberate the GSM protocol stack first. The current leo2moko fw has this protocol stack in a bunch of binary object libraries, as that's what TI provided in the TCS211 (Leonardo) deliverable. Full source forms of closely related versions are available through the TSM30 and LoCosto leaks though, the latter being more promising - hence the current FC project plan is to try lifting the g23m* code layers from the LoCosto version, and see what we get. But there is a bunch of other preparatory work that needs to get done before we get to that point. Also: Could the gsm module be made working without a SIM, i.e. just by providing the necessary values like IMSI and Ki? Sure thing, and OsmocomBB already supports such usage. But where are you going to get a Ki that is recognized as valid by the GSM network you wish to use? And what would the corresponding phone number (MSISDN) be? VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TIFFS in vitro analyzer tool released
Giacomo 'giotti' Mariani giacomomari...@yahoo.it wrote: Hi Comrade, I can't find the FreeCalypso directory at $ ftp ifctfvax.Harhan.ORG For a moment I was wondering why are people going to that old FTP site and not the new one at ftp.ifctf.org?, but then I realized that I posted a bogus URL for loadtools-r2.tar.bz2... My apologies for that mistake. Well... I found the directory and the two files I was looking for: wget ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r2.tar.bz2 wget ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/tiffs-iva-r1.tar.bz2 Yes, these are the correct URLs for the correct FreeCalypso FTP site; sorry about my earlier mistake. Everything looks fine, but it does not work: # fc-loadtool -h gta02 /dev/ttySAC0 Sending beacons to /dev/ttySAC0 Toggling /sys/bus/platform/devices/gta02-pm-gsm.0/power_on Got beacon response, attempting download p command successful, switching to 115200 baud Sending image payload Block #0: No response to w command # The above looks like an effect of some other process competing with fc-loadtool for the /dev/ttySAC0 serial channel to the modem, or maybe even for the modem power control. Did you say you are running Qtmoko? Do you know how to stop whatever processes normally access the modem in that distro? (I certainly don't, as I've never used any of the normal distros on my FR, only the minimal Buildroot environment I hacked together for playing with the modem.) It looks like you will need to convince the maintainer of Qtmoko to tell you (and the rest of us) how to get his popular distro working with FreeCalypso tools. Or you could try the special distro which David Matthews put together - the 2nd version which works without the special cable. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Calypso/audio interaction
David Matthews m...@dmatthews.org wrote:
Making a general purpose distro such as Qtmoko loadtools capable is likely to
be a non starter.
I agree in general, but see below for some finer points.
it's likely to be advisable to rip out all the audio stuff also.
That's where I need to provide some clarification. The issue here is
that (as David discovered experimentally) the combination of
{Neo FR loudspeaker enabled} + {headset jack Calypso access enabled}
is rather unkind on the loudspeaker, and on the operator's ears.
(Look at the audio circuits in the public GTA02 schematics to see why.)
However, the take-away should NOT be all audio is bad when doing any
Calypso hacking - instead it can be fine-grained:
1. One needs to ensure that the loudspeaker amplifier is off when
using loadtools via the external serial cable method. But the
state of the audio subsystem absolutely doesn't matter if you are
running loadtools from the AP and are *not* enabling the download
channel via /sys dingling.
2. In some advanced debug scenarios (and I do mean advanced, as in you
actually digging in / debugging the guts of the GSM protocol stack,
and not just flashing prebuilt images from my FTP site) it can
actually be quite useful to have the headset jack Calypso access
channel enabled (with the cable going to the FC developer's laptop
running rvtdump/rvinterf/fc-tmsh etc) while the modem is running
normally, even during a phone call.
If you need to debug the Calypso via TI's RVT/ETM interface (presented
on the 2nd UART wired to the headset jack on the Neo) *while the modem
is making a phone call*, it is possible to have this download (or
debug) serial channel enabled while audio is also enabled at the same
time. The trick is that in this scenario, the audio must be routed to
the earpiece speaker, and *not* to the loudspeaker, and most certainly
not in the analog headset mode.
This latter scenario is where FreeCalypso tools do need to play nicely
with Qtmoko/SHR/etc - it would be very useful to observe the RVT/L1/G23
debug output from the modem on the external serial port (or to send
active ETM commands to it via the same interface) while it is being
driven normally by Qtmoko/SHR/etc.
Better idea - use the special distro (I used Qtmoko as a starting point)
with or without the cable - or else build your own single purpose
boot_and_run_from_sdcard system.
http://winterveldt.co.za/leo2moko-p2.html
Yes, for loadtools operations (saving FFS dumps, flashing different
firmwares, coming-soon in vivo FFS/IMEI editing kit) David's offering
seems like a better choice.
VLR,
SF
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Fun with IMEI (was testing the free calypso software)
Norayr Chilingarian nor...@arnet.am wrote:
Does anyone know what will happen in a cellular network where there is
more than one device has the same IMEI. In other words, if we all
could change our IMEI numbers, and use one imaginary number, are there
technical reasons for network to not work.
joerg Reisenweber jo...@openmoko.org responded:
: no technical but organizational. Usually that IMEI gets an instant ban, and
: a fat bold red alarm logline in carrier's network logs.
Yup, if all of us were to use the same IMEI number, it would be far
too easy for our enemies to ban that one single number.
I mean, MAC address is used on a physical layer, so if two network
cards connected to the same switch have same MAC adresses, network
won't work. I guess switch will down both ports connected to those
devices.
The analogy between IMEIs and Ethernet MAC addresses is a good one
from a manufacturing/management perspective, but not in terms of
network protocol usage. Unlike MAC addresses, IMEIs are not used for
any kind of addressing or routing anywhere in the network, only as a
management identifier that is unnecessary in the strict technical
sense.
But from the perspective of a device manufacturer (which I will become
soon, hopefully), IMEIs are just like Ethernet MAC addresses: the
nominal requirement is that each be world-unique for all time (a rule
that gets broken in reality with both MAC addresses and IMEIs), a
manufacturer has to buy a range (supposedly fresh and unused) from a
central registry, and then number individual produced units out of
that range.
But I don't know how IMEI's work. Are they technically necessary so
that 3G/gsm network can be operational, or they are only used to
identify (and track) customers by devices?
The latter.
Before everyone starts changing their IMEIs just for the heck of it,
let's analyze *rationally* how tracking works - or rather, what is the
total set of data elements available to carriers (and their gov't
partners etc) for tracking users, and how these data elements inter-
relate.
If you like maintaining a long-term-constant phone number at which
your family and friends can reach you (i.e., the whole purpose for
having a cellphone, at least for me), and you have a long-term-stable
SIM card associated with that long-term-constant phone number, then it
doesn't really matter if your IMEI is also constant or if you send the
output of a PRNG (or even a TRNG) to the network as your IMEISV every
time your phone/modem fw does the register operation. The constant
SIM card with its IMSI, as well as the associated MSISDN (phone number
for your family and friends to call you at), is what tells the network
that you are still the same you, no matter what device you use or
what IMEISV it transmits. Yes, you can deregister from the network,
then re-register with a different IMEI, making it look like you turned
your phone off, moved your SIM card to another phone, then came back
online with the latter - but what would be the point?
Instead, there are only two scenarios I can think of in which it would
make sense to change the IMEI of a GSM device:
1. If you really want to disappear w/o trace, such that you discard
your old SIM, get a new SIM (prepaid, presumably) with a different
phone number (and deliberately make yourself unreachable at your
old one), and you want to make it look like the user of the new SIM
is a different person from the user of the old SIM - in this case
the same IMEI would indeed give you away, so you might want to
change it in this case.
If the above applies to you (and it does *not* apply to me, as changing
phone numbers constantly would defeat the whole purpose of a cellphone
for me), then you need to be careful to change your IMEI *at exactly
the same time* when you change your SIM - if there is any time skew
between these two changes, such that a network sees {old IMEI, new SIM}
or {new IMEI, old SIM} at any time, even just once, your anonymity
effort will be instantly brought to naught! If you want to do this, I
would recommend pulling your old SIM out first, throwing it away, then
doing the IMEI changing operation on the SIM-less modem, and then
finally inserting your new SIM.
2. Changing one's IMEI may be necessary if your legitimate IMEI from
the manufacturer of your GSM device has been wrongfully banned or
blocked by some GSM network you wish to use, and you need to use
some non-blocked IMEI in order to get on the network.
The wrongful ban scenario is particularly frightening when applied to
whole classes of devices, rather than individual units. The first 8
digits of the IMEI comprise the Type Allocation Code (TAC), which is
supposed to be allocated per each device type. Hence if all
manufacturers involved played by the rules (of which I have no
knowledge), then every IMEI beginning with 35278901 is supposed to be
a Pirelli DP-L10, every IMEI beginning with 35465101 is supposed to be
an Openmoko
TIFFS in vitro analyzer tool released
Hello project followers, The tool for examining flash file system images read out of TI-based GSM devices (which include Openmoko GTA0x modems) has just been released: ftp://ftp.ifctf.org/pub/FreeCalypso/tiffs-iva-r1.tar.bz2 Aside from the naming and packaging change, the main functional difference between the current tool and the offering I put out last summer (mpffs-tools-r1.tar.bz2 in the same directory) is the addition of the lsino and catino commands, which enable forensic examination of FFS change history and the old content of deleted/overwritten files. For some examples of what one can do with this tool, see my previous post: http://lists.openmoko.org/pipermail/community/2014-January/069265.html VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Norayr Chilingarian nor...@arnet.am wrote:
If someone has no backup of calibration data, can she use calibration
data from other phone?
Then we can send our data to that person. Or it won't work this way?
I probably don't understand it well.
joerg Reisenweber jo...@openmoko.org followed up:
Not recommended and not entirely correct procedure but nevertheless should
sort of work, yes. You might want to edit the IMEI to what yours been, before
(or after) you flash that alien calib data.
I still have a lot of learning ahead of me in this department, but per
my current understanding, the purpose of RF calibration is to measure
those physical variations which exist from one produced unit to the
next, and to record these measurements (or some values derived from
the measurements) in per-device non-volatile memory, such that the
modem firmware can then take account of and compensate for these per-
device differences. I'm guessing it has something to do with non-
linearity in the amplifiers, process variations in the ADCs and DACs,
temperature sensitivities etc. This document from TI attempts to
explain some of it:
ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf
So my current understanding is that at least some of the calibration
values will differ from one unit to the next, and I reason that taking
the values from one unit and using them on a different unit may cause
some poor RF performance, or out-of-spec operation in terms of Tx
power levels perhaps. I have no way of knowing just how much
difference there is between one GTA02 and the next, and hence what
would the magnitude of ill effects from a calibration transplant be.
A good experiment would be to compare the calibration values (properly
programmed at the factory, presumably) read out of different GTA02
units. The flash dump from my GTA02 can be found here:
ftp://ftp.ifctf.org/pub/GSM/GTA02/flashdump.bin
I made that dump from my GTA02 back in 2013-04, and put it on the FTP
site in 2013-07, long before the recent project breakthroughs. The
first 0x225594 bytes of that flash image (just under 2.25 MiB) contain
the moko10 fw image (what my FR came with); the interesting part (the
FFS) starts at offset 0x38.
Using the new tiffs/mokoffs tools I just wrote (get them from the Hg
repository on Bitbucket or wait for my coming-soon tarball release),
we can examine the content in this FFS image. Let's start with the
basic vital stats:
$ mokoffs -f flashdump.bin blkhdr
Block 0: age , type/status AB
Block 1: age , type/status BD
Block 2: age , type/status BD
Block 3: age , type/status BD
Block 4: age , type/status BD
Block 5: age , type/status BD
Block 6: age , type/status BF
$ mokoffs -f flashdump.bin fsinfo
Active inode block (AB) is block #0
Root inode is #1
Root inode (format) name: /ffs-root
(mokoffs is a trivial wrapper around tiffs that spares the user from
having to specify the 64x7 FFS organization argument every time, and
-f means that one is looking at a complete flash dump, rather than
just the FFS sectors - hence the tool needs to go to offset 0x38.)
Listing the actual content is easy too:
$ mokoffs -f flashdump.bin ls
fr4096 /.journal
d /gsm
d /gsm/rf
d /gsm/rf/tx
f 512 /gsm/rf/tx/ramps.900
f 128 /gsm/rf/tx/levels.900
f 128 /gsm/rf/tx/calchan.900
f 512 /gsm/rf/tx/ramps.1800
f 128 /gsm/rf/tx/levels.1800
f 128 /gsm/rf/tx/calchan.1800
f 512 /gsm/rf/tx/ramps.850
f 128 /gsm/rf/tx/levels.850
f 128 /gsm/rf/tx/calchan.850
f 512 /gsm/rf/tx/ramps.1900
f 128 /gsm/rf/tx/levels.1900
f 128 /gsm/rf/tx/calchan.1900
d /gsm/rf/rx
f 40 /gsm/rf/rx/calchan.900
f8 /gsm/rf/rx/agcparams.900
f 40 /gsm/rf/rx/calchan.1800
f8 /gsm/rf/rx/agcparams.1800
f 40 /gsm/rf/rx/calchan.850
f8 /gsm/rf/rx/agcparams.850
f 40 /gsm/rf/rx/calchan.1900
f8 /gsm/rf/rx/agcparams.1900
f2 /gsm/rf/afcdac
f2 /gsm/rf/stdmap
f 24 /gsm/rf/afcparams
d /gsm/com
f 16 /gsm/com/rfcap
d /gsm/l3
f 144 /gsm/l3/rr_white_list
f 256 /gsm/l3/rr_black_list
f 44 /gsm/l3/eplmn
d /gsm/cops
f 16 /gsm/cops/operimsi
d /pcm
f 12 /pcm/CGMI
f 13 /pcm/CGMM
f 14 /pcm/CGMR
f8 /pcm/IMEI
f9 /pcm/IMSI
f 23 /pcm/LRN
f 21 /pcm/LMN
f 22 /pcm/LDN
d /sys
d /mmi
d /vos
d /vos/vm
d /vos/vrm
d /vos/vrp
d /var
d /var/log
d /var/tst
d /var/dbg
f 3152 /var/dbg/dar
d /Test
f4 /Test/Teststate.bin
f 196 /Test/Production.bin
d /aud
f 164 /aud/para0.cfg
Most of the above should be self-explanatory; the numbers shown before
the pathname for files ('f' as opposed to 'd') are the lengths of each
file in bytes. The files containing the RF calibration
Re: testing the free calypso software
Giacomo 'giotti' Mariani giacomomari...@yahoo.it wrote: Hi David, Michael, all, thanks a lot for your work, it is very emotional to see this little piece of freedom rising! You're welcome. :-) I'm still not brave enough to risk my only (I mean in all my life time so far) mobile phone, but I will soon ;-) There is nothing at risk really - if the leo2moko firmware doesn't work for you for some reason, you can always revert to moko11, using either our flashing tools or the official moko11 flasher. Even in the case of the FFS with the RF calibration values etc, there is absolutely no danger of corrupting this FFS if you issue loadtool commands exactly per the instructions. Saving a backup copy of the FFS sectors is a precaution just in case you erase or write to the wrong part of the flash. If you have this backup saved, you can always restore it. In the absolute worst case scenario imaginable, if someone does lose their RF calibration values and has no backup copy anywhere, you should be able to send your FR to some lab to get it recalibrated. I don't offer such service currently because I haven't acquired the necessary RF test equipment and process knowledge yet, but when I start building my own Calypso phones, I will obviously need to get them calibrated, and once we have the knowledge and the setup to do it, Harhan Engineering Co. will also offer recalibration services to Freerunner users. By the way, I think that your work, with the right notes about being experimental and so on of course, should also be in the official wiki. As much as I would love to see it happen, I doubt that the powers controlling that wiki will ever allow it. A small question about the procedure you describe: is the t191 cable only needed to backup the vital parts of the calypso memory or also to write the new firmware? Both if you use the uSD system which David just released; neither if you get FreeCalypso loadtools running on the Linux processor of your FR like Norayr did. Oh, and just to be clear as to exactly what the vital parts of the calypso memory in question are: the only entity that lives in the GSM modem's flash memory besides the firmware image (which is exactly the same in a device as it is on the web at the official download URL) is the flash file system, or FFS. The FFS in Openmoko's modems takes up exactly 448 KiB of flash space (64 KiB x 7); per TI's design it is structured like a UNIX file system (directory tree, forward-slash- separated pathnames, case-sensitive etc) and stores a bunch of things: * The modem's IMEI; * RF calibration values; * ID strings which say that your device is a Neo1973 GTA02 made by FIC/OpenMoko - Om's late firmwares (moko10/11) appear to not use these strings from FFS (fw returns hard-coded strings instead), but my leo2moko fw returns the strings from FFS following TI's canon; * Some dynamic data written into the FFS (the fw always mounts the FFS with R/W access, TI's fw has no concept of a read-only mount for the FFS) during the operational lifetime of the modem: history of what SIM cards this modem saw, dialed/received/missed calls, and probably received SMS as well - I have yet to play with the latter. Just this weekend I wrote a new utility for examining FFS images read out of TI-based GSM devices (our beloved FR being one of them); this new tiffs utility (with mokoffs and pirffs wrappers) supercedes my earlier mpffs-* tools I wrote and released last summer. The new utility allows one to list and extract not only the current file content of the FFS (i.e., what one sees when mounting the file system normally), but also those files which have been logically deleted or overwritten, but not yet reclaimed, i.e., not truly gone. Hence the tool can be used to do forensics on Freerunner modems - I suspect many of you probably never thought about the modem's flash memory remembering the history of what SIM cards you had in there, what numbers you called or received calls from, and probably your SMS exchanges too... The just-described utility currently lives in the freecalypso-sw tree on Bitbucket: http://lists.openmoko.org/pipermail/community/2013-August/068850.html Look in the ffstools directory. Now I need to write some more documentation and make a release tarball for the FTP site. Stay tuned; I'll post here when I make that release. By the way, yes, a distro able to flash and back-up everything without additional cables would be very appreciated. Of course... Shortage of qualified volunteer manpower is our only limit. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
joerg Reisenweber jo...@openmoko.org wrote: That's a bold misconception. OM wiki isn't censored, it just gets cleaned of SPAM and obviously incorrect AND hazardous info, like e.g. somebody suggesting to run wear tests against NAND to verify its formatting. But I still think that it would be better for FreeCalypso to have its own identity that is separate and independent from Openmoko, i.e., its own mailing list, its own website (wikified or otherwise) etc. As a result of my involvement on another mailing list (on a topic that is totally unrelated to mobile phones), I became aware of this document from the ISO Technical Committee on terminology: http://www.ucolick.org/~sla/leapsecs/ISOTC37toITURA.pdf Simply put, the authors of the above statement from ISO TC37 emphasize the importance of using terms which have a 1:1 mapping to the concepts they are meant to stand for, i.e., 1 concept = 1 term. As you and others have made it perfectly clear on numerous occasions, the term Openmoko was never meant to stand for the concept of free (or open) GSM modem; instead this term (according to you and other high-standing community members, which I obviously am not) stands for a different concept, namely that of a free application processor with a black box modem attached as a peripheral. And because the name Openmoko rightfully belongs to you and your former boss Sean Moss- Pultz, it is not my place to try to change its meaning. (In fact, Dr. HNS is effectively invoking this term=concept equivalence of Openmoko = free AP with a black box modem as a peripheral when he asserts the legitimacy of his GTA04 product as a non-downgrade successor to Om products.) But I am working with a completely different concept, namely that of a free GSM device, be it a modem or a complete dumbphone. And because it is an entirely different concept than that which is mapped by the term Openmoko, by the principles of ISO TC37 my new concept calls for a new term for referring to it. Hence the name FreeCalypso was born: I came up with this name about this time last year, following exactly the line of reasoning I've just outlined, and my first public announcement of FreeCalypso was this one: http://lists.openmoko.org/pipermail/community/2013-February/068270.html The FreeCalypso project is very much in need of its own web/list home under the ifctf.org domain name, which currently features only an FTP site. My desire is to create a lists.ifctf.org host first, hosting Mailman mailing lists exactly like Openmoko and almost all FOSS projects and technical communities have nowadays - anything else would be seen as substandard, and therefore unattractive to me. A website for FreeCalypso (wikified or not) can be created later, but my first focus is on the lists host on which we can create a proper new mailing list for FreeCalypso. And because I already have my own physical datacenter on my own physical turf, I *will not* buy hosting from someone else who would ask me to agree to their TOS or AUP or the like - hence my only option is to use my own physical hardware. A SAS JBOD chassis is already on its way to me from ebay, already paid for; the drives are next - as soon as I gather the cash to buy 6 SAS drives of some non-laughable capacity (I refuse to use SATA, and I desire 6 drives to start with for a raidz2 ZFS configuration - I'll be running OpenSXCE), I will finally have the necessary hw, and will begin the setup/configuration work. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
David Matthews m...@dmatthews.org wrote: I've done a bit of work, which I hope will encourage other people to give it a test. There is a full write up at http://winterveldt.co.za/leo2moko.html, with links to a distro I've prepared for the sole purpose of flashing your freerunner's calypso - either with leo2moko or moko11 firmware. Thanks, David! And just in time, I've got a new release of loadtools out: ftp://ifctfvax.Harhan.ORG/pub/GSM/FreeCalypso/loadtools-r2.tar.bz2 Changes from loadtools-r1 to loadtools-r2: * A flash ID check has been implemented in fc-loadtool, invoked automatically before doing any erase or program operations, or explicitly at any time with the flash info command. This check ensures that the type of flash chip in the target GSM device is the same as what loadtool thinks it is, based on the hardware parameters file. * fc-xram command line syntax changed slightly in order to support immediate passing of the serial line to rvinterf/rvtdump. * Miscellaneous minor polish. Note that because the uSD card distro which David just put together does not include loadtools internally (requires the use of the serial cable instead, with loadtools running on your PC), nothing in that distro became outdated as a result of this new loadtools release. Just download the new loadtools and build them on your GNU/Linux PC. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A5 / Letux 2804
Stefan Monnier monn...@iro.umontreal.ca wrote: There are tradeoffs everywhere. I think that having a 100% free firmware for the cell-phone part is really great. Having an up to date smartphone that runs Free Software is also great. Hypothetically speaking, if someone would like to have a device in the Neo FR form factor that combines a FreeCalypso modem with an up to date AP (application processor) subsystem like that in the GTA04, there is nothing to stop you (that's an abstract you, not directed at anyone in particular) from building such a hybrid device. Calypso and its companion chips are still available on the Chinese surplus market; the 100 chipsets I bought some months ago most certainly weren't their last. But I doubt that someone would want such a device badly enough to invest the massive amount of time, effort and money such a project would require. I suspect that I may be the only person crazy enough to actually (want to) build a new phone (or a mobile device of any kind) based on the ancient Calypso, but it just so happens that I want a dumbphone rather than a smartphone (or mobile computer or whatever you want to call it) in my pocket, and naturally I'll be building the device which I would want to use myself... Oh well - when I do build that dumbphone for my own personal use and enjoyment, it will also have a side effect of a known-working Calypso reference design (quad-band!) becoming available for anyone to reuse, so at that time (probably in a few years) we can look into combining this FreeCalypso modem with something like Neo900 for the AP subsystem. I see no reason why one project should feel like the other is a threat. It's the destruction of GTA02s entailed in the process of making GTA04s that sets me off. Some months ago (or was it a year or two ago?) someone here posted about how he wanted to use GTA02 motherboards as wall decorations or somesuch - now THAT kind of waste should be criminally punishable! If you feel that your Openmoko-made case+LCD+misc set would serve you better with a GTA04 mobo inside, and you don't see value in the GTA02 mobo, then please pass that old mobo to someone else who would appreciate it enough to 3D-print a new case for it or whatever, rather than waste it. BTW, one issue with Calypso is that as the proportion of non-3G phones in use decreases, coverage for non-3G phones is going down. Maybe it's not yet a problem, but it's only a question of time. Yes, that is a very major threat. Fortunately it hasn't happened yet, at least not in my part of the world. I use a Calypso-based Pirelli DP-L10 as my daily phone, I roam all over Southern California (from Los Angeles to the Mexican border), and I have yet to encounter even one spot with poor or no GSM coverage. And that's despite this phone (like all of my other GSM phones) supporting only the primary USA band at 1900 MHz and not secondary band at 850 MHz! (The latter is a relatively new addition, a spectrum reallocation from AMPS which was still in service as late as 2008, at least according to Wikipedia.) But when the major commercial operators do shut down their GSM services, we would have to set up our own, squatting on unused frequencies like pirate radio broadcasters do... VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
CSD calls from Neo Freerunner
For those who don't know what CSD is: http://en.wikipedia.org/wiki/Circuit_Switched_Data Here is an AT command session log of me making a CSD call from my GTA02 on T-Mobile USA: at+cgmm +CGMM: Neo1973 GTA02 OK at+cgmr +CGMR: FreeCalypso leo2moko port OK at+cops? +COPS: 0,0,T-Mobile OK atd13034944774 CONNECT National Institute of Standards and Technology Telephone Time Service, Generator 1b Enter the question mark character for HELP D L MJD YR MO DA HH MM SS ST S UT1 msADV OTM 56677 14-01-20 05:30:54 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:30:55 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:30:56 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:30:57 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:30:58 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:30:59 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:00 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:01 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:02 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:03 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:04 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:05 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:06 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:07 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:08 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:09 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:10 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:11 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:12 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:13 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:14 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:15 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:16 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:17 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:18 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:19 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:20 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:21 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:22 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:23 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:24 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:25 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:26 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:27 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:28 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:29 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:30 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:31 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:32 00 0 -.1 045.0 UTC(NIST) * 56677 14-01-20 05:31:33 00 0 -.1 045.0 UTC(NIST) * NO CARRIER -- end of log -- The number I dialed in this test is the Automated Computer Time Service provided by the National Institute of Standards and Technology: http://www.nist.gov/pml/div688/grp40/acts.cfm Note how the above web page says, in part: Digital modems, such as [...] wireless modems, cannot synchronize using ACTS. Well, the log above clearly shows that they are wrong, at least in the case of high-quality wireless modems like Calypso. :-) CSD calls may be placed from a GSM mobile either to a land line or to another mobile. (I don't know if it's possible to establish a CSD connection from a land line to a mobile.) When placing a CSD call to a land line, one can connect to a traditional dial-up modem on the receiving end - that's how I connected to ACTS, and if you've got your own UNIX etc server at home with an old-fashioned modem on a land line, it is really neat to be able to connect to it from anywhere in the world via CSD, *bypassing the Internet*! When you place a CSD call to another mobile, the network tells the latter that it is a CSD call rather than voice. If you have a GTA02, you can have some fun by testing how various other mobile phones react to incoming CSD calls: just have your FR dial a CSD call to the number belonging to some standard cellphone (dumb or smart), running standard proprietary fw, and see how the latter reacts to receiving such an unusual call. :-) To dial a CSD call, just omit the ending ';' from the ATD command you would normally use to dial an ordinary voice call - see my log above. But not all modems are created equal. I've got a Huawei E303 3G modem in the USB stick form factor to play with, and it appears that this modem's fw does not support CSD at all. After doing the usb_modeswitch voodoo typically needed for these USB 3G modems (usually automated via udev rules, but I had to install an updated usb_modeswitch package on my Slackware 13.37 laptop), the modem shows up as a bunch of /dev/ttyUSBx devices, supported by the option kernel module - hence I wonder if it's anything like the modem in the GTA04. /dev/ttyUSB0 presents an AT command interface, and the following observations can be made from the latter: * One can dial voice calls with ATDnumber; - makes the phone ring on the other end; upon answering that call one hears noise - the modem must be implementing some way to pass digital audio over USB, which is not being
Re: USB networking Win7
dmatthews.org m...@dmatthews.org wrote: PuTTY is quite a decent (free as in beer) ssh client for windows PuTTY is free as in speech too, i.e., it is bona fide free software - not just free as in beer. Of course Windows isn't, but we are talking about PuTTY, right? VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] GTA04A5 / Letux 2804
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Not everybody is weighting the factor of freeable down to the modem equally when calculating the relative position of two devices to decide between upgrade and downgrade. You have a different weighting than me. If freedom is not important to you, then you might as well use an iPhone or the latest Android from Samsung. As Jim Marrs has said very eloquently in the preface to one of his books, being free is like being pregnant - either you are, or you aren't. I don't know, but isn't *that* something you should fight against instead of modifying leaked firmware for a system that never has been locked? Modifying leaked firmware is not an accurate description of what I am doing. As you should know full well, I am designing and building my own Free Plain Phone, and I have chosen to use the same Calypso chipset as used in the GTA02. I chose this chipset because it already exists, because it is known to work exceptionally well, at least in dumbphone applications (I've been using one of my Pirelli phones as my everyday cellphone since last spring, and I have nothing but praise for it in terms of battery life, GSM signal strength and call quality), because all hardware documentation and firmware sources for this chipset have already been freed, and because I have already amassed a great deal of experience working with this chipset. Providing hacking support for Openmoko-made modems is simply a side- product of my FreeCalypso work: I have chosen to bring my firmware up on known-working hardware first, so that when I build my own hw and get to debug it, I will have the benefit of known-working firmware. Put another way, the free phone community (combination of FreeCalypso and OsmocomBB projects) has already made great progress with the Calypso chipset. Switching to another vendor's chipset on a whim would be an enormous setback for the project and for the community, and it is not fair for you to ask that of us - here I am referring to the you should be working on this instead of that argument in your comment. So your claim of GTA02 is 100% freeable and GTA04 is not is only based on your disinterest to work on solutions? I am working on solutions, but the problem I have chosen to solve is different from yours. Some people, such as me, simply want a good working cellphone, a device for making and receiving phone calls on the go - and we want this cellphone to be free as in 100% owned and controlled by the user. If the objective is to have a plain phone, rather than a mobile computer, a device consisting of just one baseband processor, without an extra application processor, is a technically superior solution for the problem at hand: greater battery life, less unnecessary complexity, fewer points of failure. And the existence of the Calypso chipset makes it possible for such a simple and efficient dumbphone to also be 100% free by virtue of the user owning and controlling the complete firmware. Then there are those people who do want their pocket-resident device to be a computer complete with an OS like GNU/Linux, rather than just a phone - but some of those people would also want that device to be 100% free including the telephony processor - and not just half-free aka half-pregnant. For this class of users, the best currently extant device is the GTA02, made by Openmoko - not your GTA04, and not my dumbphone either. Yes, there is the problem of these devices no longer being made - but instead of solving this problem by building a new device that would be as near-identical to the GTA02 as possible, including the Calypso (just like how I seek to copy the Pirelli DP-L10 as closely to verbatim as possible), you are making it worse by *actively destroying* the remaining stock of Openmoko phones! Hence we will likely always be fighting on opposite sides. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] GTA04A5 / Letux 2804
joerg Reisenweber jo...@openmoko.org wrote: Please can you save me from reading those walls of text filled with [...] Thinking about it more, I realize that my initial post in this thread was more inflammatory than necessary. So I do apologize for posting that on an emotional impulse without thinking some more first. In retrospect, perhaps my initial post in this thread would have been better worded like this: Dr. H. Nikolaus Schaller h...@goldelico.com wrote: So please think again if you want to upgrade your GTA02 with a GTA04A5 board. Please understand that some people may find the word upgrade in this context to be objectionable - it is a matter of personal opinion and different choice of emphasis as to which device (GTA02 or GTA04) is better. Perhaps instead of calling the conversion an upgrade, it could be called a sidegrade, or just simply use the neutral word convert? And for those who do choose to convert their GTA02s into GTA04s, please be considerate of others in the community who may see the GTA02 as having more value, and please try to do the following simple gestures: * When removing the original GTA02 motherboard, please exercise due care and caution to not damage it in the process - please do NOT treat it as a throw-away item; * If you no longer want that original GTA02 board, please do not discard it, and do not subject it to any treatment (such as recycle) that would destroy the ability to use it for its original purpose. Instead please offer it to others who may have more appreciation for its original functionality. * When storing or shipping that GTA02 board for the benefit of other community members who may view it as being better than GTA04, please observe the full precautions for handling delicate and sensitive electronic components, including ESD protection. -- Would the above have been better? Aside from that, there are only two points in Nikolaus' last post which I feel a need to respond to: And if you encrypt the whole communication path yourself, why do you care what the modem is doing? Because there are many kinds of bugs which have nothing to do with privacy/security issues - plain old bugs which cause the device to simply not work under certain circumstances. I have encountered more than my share of such bugs in products of every kind, cellphones and modems being no exception (although none in Om's firmware so far), and I highly value the ability to diagnose and fix such bugs myself when and if I get bitten by one. No. If you fight for freeing the Qualcomm modem you will satisfy both sides: Your 100% freedom and a device that can be produced as many as you need - and has higher data rates and a better processor. Of course it would wonderful for all kinds of reasons to have a free modem that can connect to UMTS networks in addition to GSM, and can make use of mobile data services at EDGE or even 3G speeds rather than just plain GPRS. But given a choice between (a) continuing my current FreeCalypso work and producing a 100% free GSM-only phone/modem in a foreseeable time frame with 100% certainty or (b) abandoning this work and venturing into the completely unknown territory of baseband chipsets from other vendors, with nowhere near the guarantee of success in the near future like we have with the Calypso, I feel that (a) is a much more sensible choice for a developer in my position, and I suspect that at least some people on this list would agree with me on this question. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] GTA04A5 / Letux 2804
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: So please think again if you want to upgrade your GTA02 with a GTA04A5 board. Upgrade? Surely you must have meant downgrade - why would anyone in his or her right mind voluntarily give up a device that is 100% freeable down to the modem (GTA02) for a Qualcomm-based closed proprietary product like yours? Sorry, couldn't resist. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] GTA04A5 / Letux 2804
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Why do you assume that your (IMHO unlawful) procedure done to free the Calypso is not possible for a Qualcomm modem? Because all modern baseband processors (MTK, Qualcomm etc) have ROM bootloaders which perform cryptographic verification of downloaded fw images, and will not boot any image that has not been signed by the secret key corresponding to the public key whose hash is burned into OTP (one-time programmable) fuses right in the modem chip silicon! The FSF term for this freedom-robbing feature is tivoization. Even the later chips from TI (Calypso+ and LoCosto) have this feature, but the classic Calypso used in Openmoko GTA0x and Pirelli DP-L10 phones does not - that is the critical distinction. Of course the classic Calypso chips are no longer made, but I have a stash of 100 of them sitting right here in a desk drawer - should be enough to make illegally-free phones for the true freedom lovers among us. And if I'm not mistaken, some Chinese sellers still have quite a bit more available. So I think your conclusion is just based on your pure incapability to do the same. s/incapability/disinterest/ If I wanted to obtain a bootleg copy of Qualcomm's modem source code, I could probably do it. Don't forget that I operate in the very same geographical area where Qualcomm has its HQ, Qualcomm has a habit of employing desperate for a job programmers for stupid grunt work at offensively low pay rates (with high turnover as a result), and people in USA are not as obsessed with being law-abiding citizens like Europeans. But life is short, I have plenty of other things I wish to accomplish before I kick the bucket (building a new quad-band GSM-only dumbphone based on the Calypso being just one of them), so I leave the task of freeing Qualcomm/MTK/etc modems to someone else who, for whatever reason beyond my comprehension, finds the good old GSM and the good old Calypso to be not good enough for him or her. If and when someone posts sources and instructions on this list that do for the GTA04 modem what my hack does for the Calypso, only then will GTA02 and GTA04 become equally free. Until then, GTA02 is significantly more free, and GTA04 is a freedom downgrade. VLR, SF P.S. As to your IMHO unlawful comment, if some lawmaker decides to make a law that makes it illegal to breathe, does it mean that we should all obediently suffocate ourselves? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
/gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band
Hello Om community, In the course of hacking TI GSM firmwares, I have come across something that some of you may find interesting, or might even have some insight into. We all know that our good familiar Neo Freerunner (GTA02) was made in two versions: one with 900/1800/1900 MHz bands, the other with 850/1800/1900 MHz instead. The hardware difference is one RF SAW filter part populated differently on the same PCB; see this picture: http://wiki.openmoko.org/wiki/File:Gta02a6_comms_chips_under_shield.JPG The SAW filters for the GSM downlink Rx path are the 3 little buggers near the upper right corner, immediately adjacent to the shiny metallic component which is the antenna switch. There is one Rx SAW filter for each of the 3 supported bands: one for 1800 MHz (both GTA02 versions), one for 1900 MHz (ditto), and one populated for either 850 or 900 MHz. (*I think* the topmost one out of the 3 in that picture is the one responsible for the 850 vs. 900 MHz difference, but please double-check that before attempting any surgery on your Neo!) Well, here is the part which will surely surprise at least some of you: the standard firmware for the GTA01/02 modem (which is the same for all versions, both GTA01 and GTA02) does not actually know which 3 frequency bands are supported by the device it runs on! And no, it does not auto-detect either: there is no way (short of ESP) for any firmware running on the Calypso/Iota/Rita chipset to divine what kind of SAW filter sits between that chipset and the antenna. Instead, as strange as it may sound, the modem (at least when running the standard mokoN firmware, see below) believes itself to be quad- band! In TI's universe, the standard way to teach a GSM device (phone or modem) which GSM frequency bands it supports is *not* to hard-code that knowledge in the firmware at compile time; instead this property is stored in a configuration file named /gsm/com/rfcap in the GSM device file system. Yes, TI-based GSM devices all use a flash file system with a very UNIX-like look and feel, including UNIX-style pathnames; see my write-up: https://bitbucket.org/falconian/freecalypso-sw/src/1852900ce9ea4ac52d4648f7d9ca46897eb3640b/doc/TIFFS?at=default Like most files in TI's GSM FFS, /gsm/com/rfcap is a binary file, not ASCII. It is a file of exactly 16 bytes, and although I haven't found a formal document describing its format in plain English, we can study the code that reads this file and acts upon its content: http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m-gsm/rr/rr_csf.c The 16-byte file is being read into a variable of type EF_RFCAP, which is defined here: http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m/condat/com/include/pcm.h Lines 442 through 460 (inclusive) give the structure definition, which is followed by the definitions for the bit fields in each byte. And here is what this /gsm/com/rfcap file contains on a standard GTA02 modem, as revealed by a TIFFS parsing tool such as the mpffs-tools-r1 package I released last summer: 00 1F 41 14 00 00 00 00 50 00 00 A5 05 00 C0 00 Decoding the meaning of the rest of the bytes is left as an exercise for the reader, but I draw your attention to the 2nd byte, which is 1F. This byte indicates which RF bands are physically supported by the MS (mobile station) hardware, and 1F means quad-band, i.e., all 4 of 850, 900, 1800 and 1900 MHz. Thus even though my trusty GTA02 is only 900/1800/1900 MHz tri-band in reality, it believes itself to be quad-band! Digging some more, one finds that the 16 bytes quoted above appear in the moko10 and moko11 fw images (convert them from *.m0 to plain binary with the mokosrec2bin.c utility I wrote almost a year ago, then do the binary grep with the memmem() C library function), and further analysis reveals that these standard firmwares unconditionally overwrite the /gsm/com/rfcap file in FFS with the hard-coded string of bytes on every boot. To convince yourself of the latter fact, take a GTA02 modem with moko11 in it, change the rfcap file in FFS to something else, reboot the modem normally, and observe that the rfcap file will be reverted back to the 16 bytes shown above, claiming to be a quad-band GSM device. My leo2moko firmware does not contain this rfcap-resetting feature: it does not automatically overwrite the rfcap file with anything, and uses whatever settings happen to be written in the FFS (the modem's flash file system). At the present, there is no practical difference: if your modem ever ran moko10 or moko11 prior to being flashed with leo2moko, the content of the /gsm/com/rfcap file in FFS will be what moko10/11 wrote into it the last time it booted, which is the hard- coded I am quad-band value. But I wonder - and this is really the main reason for this lengthy post of mine - is it really a good idea for a tri-band GSM modem to believe itself to be quad-band? There are two potential problems I can think of: 1.
Re: /gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band
joerg Reisenweber jo...@openmoko.org wrote: Bottom line: even 850MHz FR can do 900MHz but the reception is pretty poor= though just sufficient in usual urban environment. Hmm, interesting! Of course given the geographical theater I operate in, my interest would be in going the other way around. The funny/sad thing is, I do not currently have *any* GSM (or GSM+newstuff) device which has proper support for the 850 MHz band (the secondary GSM band in the lands I operate in) and which I can hack in any way at all: sure, there are 3G+ smartphones all around me, and they all claim to be quad-band when they go into GSM fallback mode, but of course they are the typical Android etc crap, and I don't know how to hack them (if that can be done at all), so I don't even know whether that SGS2 (as an example) is connected to an 850 MHz network or a 1900 MHz one! As to the hackable Calypso devices I have (one FR and a few Pirelli DP-L10s), they are all 900/1800/1900 MHz, so to this day I don't even know what GSM services might exist in the 850 MHz band around me... I do use one of these devices as my everyday phone though (and the non-Calypso Mot V66 I used previously was/is 900/1800/1900 MHz as well), so basically all my cellphone-using life I've been using what is effectively a 1900 MHz only device. I roam over a pretty wide area and have yet to encounter a spot without good coverage - and it is kinda neat when I realize that I get all this great coverage despite my phone supporting just GSM1900 and absolutely nothing else! (Meaning nothing else relevant to my geographical area.) But given what you just said, I am now tempted to try running cell_log (from OsmocomBB) set to the [128,251] ARFCN range (corresponding to the 850 MHz band), and see if it can pick anything up. I'll try it when I get some time to play. I don't think network/BTS can direct the mobile to another channel, it can only adveritse other channels but it's up to mobile to determine if that=20 channel actually works in the particular situation Indeed I think that the scenario I hypothesized in my original post is very unlikely in reality, but as far as the network directing a mobile to a channel, I was thinking along the lines of what happens in call establishment, channel hopping etc - granted, I still have a lot of GSM learning ahead of me as I set out to reintegrated that code from http://scottn.us/downloads/peek/ in the place of the binary libs in leo2moko, but I was under the impression that whenever the BTS basically tells a mobile let's continue this conversion on channel so-and-so, that direction contains not only the new timeslot number, but also the new ARFCN, and at least in theory the network is free to pick any ARFCN which it serves and believes the mobile to support as well. But of course I could be entirely off-base here, as I haven't really learned that part of GSM yet. there may be other=20 problems to receive 900MHz band than just a SAW filter, like local interfer= ence=20 or whatever. I see what you are saying: the scenario of a tri-band mobile device advertising and believing itself to be quad-band (what Om modems do) is indistinguishable from that of a genuinely quad-band device having the 4th band rendered unusable by some unpredictable external factors like local interference. A valid point indeed. The fact that, as you say, an FR made for 850 MHz could receive 900 MHz and work so-so (limp along) does make for an argument in favor of keeping the I am QB setting in that /gsm/com/rfcap file - if that file were changed to reflect just the bands officially supported by a given FR unit, it would not even attempt tuning its radio to the 4th band. Has anyone else in the community ever used an FR successfully in the wrong band? When the mobile can't use a certain frequency, the BTS will not force the mobile to that frequency. OK, I need to learn some more about what happens in channel hopping scenarios, and how (and by whom) the frequency channel is selected in those cases. Oh, and while we are on the subject of GSM frequency bands, I guess I need to give everyone an update on my efforts to build my own quad-band Calypso phone. Right now that project is bogged down in mechanical design issues which have nothing to do with the number of GSM bands or even with the Calypso chipset. What I really want is something as nearly-identical as possible to the Pirelli DP-L10, and I won't feel satisfied with anything less than that. Back in 2013-11 I was in communication with some seller (German apparently, but advertised on a Chinese site) who claimed to have around 700 of those Pirellis for sale. I wanted 100, and the price would have been some 3-4 months worth of my spare budget. But just as I raised the money for the first partial order, the guy told me that someone else bought all of those phones, they had no more left, and whoever bought all 700 or however many they had, was not willing to resell any of them
Re: First small steps toward free GSM firmware
Norayr Chilingarian nor...@arnet.am wrote: Hehe, flashed your image! http://norayr.arnet.am/tmp/2013-11-09/Screenshot-2_patched.png Nice! Thanks a lot. You're welcome. :) I don't use gsm usually, I'll check how gprs works over gsm. It did not work before, usually SHR did not want to connect. [...] But I would like to learn to establish gprs connection from console. Right now all my knowledge of GPRS consists of just this one paragraph from Harald Welte's paper: http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf (Paragraph 6.1 on page 8 in the PDF.) Given this highly limited amount of GPRS knowledge on my part, I'm afraid that I won't be of much help with GPRS until *much* later down the road, when I'm ready to try integrating (and learning) GPRS, well after I get all basic GSM functionality (voice, SMS and CSD) fully working in the gcc-built FC GSM fw. P. S. one day I'll play with IMEI too. Have fun! Here are some tools to get you started: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/mpffs-tools-r1.tar.bz2 In another msg: I can already tell that I could not use sms's previously, they did not work. I just received many sms's after reboot, and I was able to remove them. It did not work before. Now this is truly interesting - are you saying that you are seeing differences in SMS handling behaviour between moko11 and my leo2moko, and that leo2moko works better for you in this regard? Details, please! I find it rather improbable that moko11 would have a fatal defect in something as basic as handling incoming SMS, hence me trying to understand exactly what it was that didn't work for you with moko11 and got fixed with leo2moko. Don't get me wrong, I would *love* to find out that my fw has some actual functional improvement over moko11, beyond the feel good of having a viewable source, but let's first confirm that it's real and not imaginary... VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
Wow, I went to bed after my last post, and when I got up this morning, there had been a lively discussion between Norayr, Joerg and Nick! As much as I would love to be proven wrong on this, I consider it *very* unlikely that there is any functional defect in moko11 which somehow gets magically fixed with my current leo2moko transitional step. There probably *are* bugs galore in TI's binary object libs which contain the bulk of the GSM protocol stack, likely even buffer overflow etc bugs which could be exploited by someone setting up a rogue BTS and feeding control packets over the air containing things which shouldn't happen - but if such bugs are present in moko11, they are probably present in all versions of TI's TCS211 binary libs, including the versions used in my current leo2moko port, hence we don't have a fix for that malady yet. The LoCosto source at http://scottn.us/downloads/peek/ does have the GSM/GPRS protocol stack in full source form (aside from GPF, which appears to have been distributed as binary libs even inside TI!), and I do seek to replace our current blobs with this LoCosto version, but before we can do that, I first need to go through the hellish process of reintegrating all of the lower-level pieces (basically everything under chipsetsw in the leo2moko source tree) into my Unix/gcc build environment - and I'm just starting on that one, currently trying to figure out why the RVT task is not emitting system time trace messages every 20 s like it should... In the meantime, the only gain which the community can get from my leo2moko transitional step is the change from a black box to a glass box: you can see all of the sources and binary objects from which I have built my fw, the binary objects contain a good amount of symbolic information making disassembly quite practical, and there is a map file from the linker which shows what every byte in the final flashable binary is for and what it corresponds to in the source. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
Norayr Chilingarian nor...@arnet.am wrote: Okay, so first thing I did is I have compiled loadtools, as planned right on freerunner. [...] After short build I have three binaries installed fc-iram fc-loadtool fc-xram I believe they will run. Congrats, you have successfully navigated one part which I thought would be very hard for most users. Using the loadtools you've got installed on your FR now, you can do another important step: make a backup copy of your modem FFS. Step 1: run fc-loadtool like this (from inside the FR): fc-loadtool -h gta02 /dev/ttySAC0 You should see a bunch of messages followed by a loadtool prompt. Step 2: when you reach that prompt, enter this command: flash dump2bin my-flashdump.bin You should get a dump of your modem flash content in a file whose name will be whatever you've entered as the last argument. The file should be 4 MiB long. Transfer it from your FR to your PC and examine it with your favourite hex viewer. You should see the original fw image (moko10 or moko11 or whatever you are running) in the first 2.25 MiB or so, then blank flash (all FF bytes) until offset 0x38, then 7 sectors of 64 KiB each (0x7 bytes total) of FFS (flash file system), then blank flash again for the last 64 KiB. Verify that the content of the flash dump is as expected, and save it securely - having this backup copy will keep your FR from becoming a brick in the case that some subsequent operation will destroy the RF calibration values in FFS. Then, I have tried to compile the firmware with supplied wine environment. [...] Inspite of using nowhine, I saw a lot of fontconfig warnings . I never got those on my system; the whines I get from my wine are the ones you can see in my cheesy nowhine.c source. You are more than welcome to edit nowhine.c and make it suppress whatever whines _you_ get. :-))) Build fails, failed a couple of times, both by using nowhine or wine without wrappers. Because one windows utility, probably linker, fails http://norayr.arnet.am/tmp/2013-11-09/openmoko/wine_error.png Yes, it is the linker indeed, which is bad news because one can't build a firmware image without passing the linker step. :-( Error details http://norayr.arnet.am/tmp/2013-11-09/openmoko/wine_error_details.png Backtrace: http://norayr.arnet.am/tmp/2013-11-09/openmoko/backtrace.txt Not much I can do with these: I don't have source for TI's compiler toolchain any more than you do, and I'm not a wine expert either. See below regarding what system I use. Report: http://norayr.arnet.am/tmp/2013-11-09/openmoko/report.txt Looks as it should, except for the wine page fault error when running vlnk470. I wonder, if the problem is in my wine version or system setup. I have 32 bit wine running on x86_64 GNU/Linux, use it sometimes, and it worked fine before. I use Slackware (a GNU/Linux distro for Luddites like me), all 32-bit only, nothing x86_64 at all: hec@darkstar:~$ uname -a Linux darkstar 2.6.37.6-smp #1 SMP Sun Jan 27 05:32:33 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux hec@darkstar:~$ cat /etc/slackware-version Slackware 13.37.0 hec@darkstar:~$ wine --version wine-1.5.23 I am sure, it would be much easier to debug and understand the problem in case of using native Unix build environment. Yeah, no kidding! Firmware that can only be built with a proprietary compiler which exists only as Weendoze binaries for which none of us has any source is not really free - hence my chosen subject for this whole thread: First small steps toward free GSM firmware, not Free GSM fw is finally here. What we have so far is indeed only the first small steps, not a complete victory yet. I am working on it, albeit at a snail's pace. I've got an ex-TI person helping me with my FreeCalypso project (when TI shut their Wireless Terminal Business Unit down, a lot of people were out of a job - wasn't fun for those people, but guess why my FTP site now sports 4 different TI source leaks :), and with that person's help I was able to understand the overall architecture of how the major pieces fit together. Now I have an arduous task in front of me: in order to rebuild the firmware in a sane environment (using gcc and all that good stuff), I have to reintegrate the fw architecture piece to piece. The dependency graph isn't cleanly-vertical, so it is not a simple matter of the higher layers sitting atop the lower ones - almost every piece depends on almost every other in some way. So I have to take one low-level piece, temporarily remove whatever dependencies it likely has on other pieces which I haven't got to yet, and get that piece integrated in my gcc-built fw tree. Then add the next piece in the same manner, and at some point I'll get to re-enabling the things I had to temporarily stub out to get the first pieces to compile and link... Not fun at all, but I don't see any other way. You are more than welcome to see my progress in the
Re: GTA04A5 ready to be pre-ordered
Le samedi 9 novembre 2013, Parchet Michaël a écrit :
Hello,
GTA04A5 has 4g (LTE) so I'm interests for an openphonux with GTA04A5..
Is it possible in the future ?
Could you inform me when it's available and what's the price ?
Best regards
mparchet
Le 8 nov. 2013 à 23:20, Dr. H. Nikolaus Schaller
h...@goldelico.comjavascript:_e({}, 'cvml', 'h...@goldelico.com');
a écrit :
Am 08.11.2013 um 23:08 schrieb Michael Parchet:
Hello,
Sorry I found only GTA04A4 but not GTA04A5 with LTE for pre order and
price.
Why
If you look at the date (22 janvier 2013), a long time has passed. We did
start for preorders
back then, but there wasn't enough response. So it was put on hold some
weeks later.
In the meantime the list cited below is still almost correct, but not
everything.
Now, we are *thinking* about restarting the project with *maybe* LTE
(option).
Restarting means to think about all details - and decide if it is now a
better time to
do it. You know world economy has changed, attitudes for openness, freerom
have
changed and people are no longer following that much the top 2 brands.
I.e. please wait for a new announcement.
BR,
Nikolaus
Thanks for your answer
Best regards
mparchet
Le mardi 22 janvier 2013, Dr. H. Nikolaus Schaller a écrit :
Hi all,
finally, the GTA04A5 batch is ready for production and we are open for
pre-orders through
http://www.handheld-linux.com/wiki.php?page=GTA04
What will be different to GTA04A4?
* the GPS receiver can provide a 1 second impulse interrupt to the CPU
* the infrared receiver can be independently powered off (it was
alternatively powered with RS232 before)
* some sensors have been upgraded to non-obsolete versions (e.g. BMA180
is out of production)
* WLAN/BT power controlled through a GPIO (so that VAUX4 is now free for
other use)
* 6-pin ZIF connector for external keyboard or other I2C devices
* it is possible to use a new earpiece (from Knowles) so that we finally
can offer a complete case kit
* the GPS antenna switch has been redesigned
* improved headset detection hardware
* CPU will be always 1 GHz and Memory 512MB RAM / 1GB NAND
* UMTS module may have newer firmware inside (tbc.)
* there is a plan for a 3D printed case (approx. 50 EUR) with integrated
touch pen
* there will be 3D data (STEP) of the PCB and components so that you can
design your own case that fits with a micrometer precision :)
Preliminary (there may still come minor changes coming from PCB
Layout tuning and from first production feedback) schematics can be found
here:
http://projects.goldelico.com/p/gta04-main/downloads/48/
-- hns
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org javascript:_e({}, 'cvml',
'community@lists.openmoko.org');
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org javascript:_e({}, 'cvml',
'community@lists.openmoko.org');
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04A5 ready to be pre-ordered
Hello, Sorry I found only GTA04A4 but not GTA04A5 with LTE for pre order and price. Why Thanks for your answer Best regards mparchet Le mardi 22 janvier 2013, Dr. H. Nikolaus Schaller a écrit : Hi all, finally, the GTA04A5 batch is ready for production and we are open for pre-orders through http://www.handheld-linux.com/wiki.php?page=GTA04 What will be different to GTA04A4? * the GPS receiver can provide a 1 second impulse interrupt to the CPU * the infrared receiver can be independently powered off (it was alternatively powered with RS232 before) * some sensors have been upgraded to non-obsolete versions (e.g. BMA180 is out of production) * WLAN/BT power controlled through a GPIO (so that VAUX4 is now free for other use) * 6-pin ZIF connector for external keyboard or other I2C devices * it is possible to use a new earpiece (from Knowles) so that we finally can offer a complete case kit * the GPS antenna switch has been redesigned * improved headset detection hardware * CPU will be always 1 GHz and Memory 512MB RAM / 1GB NAND * UMTS module may have newer firmware inside (tbc.) * there is a plan for a 3D printed case (approx. 50 EUR) with integrated touch pen * there will be 3D data (STEP) of the PCB and components so that you can design your own case that fits with a micrometer precision :) Preliminary (there may still come minor changes coming from PCB Layout tuning and from first production feedback) schematics can be found here: http://projects.goldelico.com/p/gta04-main/downloads/48/ -- hns ___ Openmoko community mailing list community@lists.openmoko.org javascript:; http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
dmatthews.org m...@dmatthews.org wrote: This is something I've quietly had an interest in for a year plus. Yup, I remember you from 2011. :-) I'd like to suggest that it would be beneficial not only to have some hand holding for people that want to compile, but also sample binary for those of us that may not have easy access to necessary hardware and software. Compiling the leo2moko version of the GSM fw from the semi-src does not require any special software, let alone hardware: the hardware is any regular PC, the software is your favourite GNU/Linux distribution with working Wine. Nothing more is needed: if you have a system with working Wine, just unpack my tarballs and run the winebuild.sh script. However, having a prebuilt binary of the leo2moko GSM fw (to encourage prospective testers from the shy-land) does sound like a good idea, so I have just put one out: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1-bin.tar.bz2 Or was your reference to necessary hardware and software regarding the flashing process, rather than compiling the gsm-fw.m0 image itself? Regarding the flashing process, I do agree that the current barrier to entry is still a little too high and could use some lowering. As things stand right now, if you want to do your own flashing operations on the GSM modem in your GTA02, the following skills/tools are required: 1. Whatever distro you are running on your FR, you need to know it inside out: you need to know how to ssh into your phone, how to kill gsmd or whatever process talks to the modem (and to ensure that it doesn't get restarted until you are done flashing your new fw and wish to test it live), and how to twiddle the power_on and download controls for the modem under /sys, as appropriate for whichever GTA02 kernel version you are running. 2a. You need to be able to cross-compile my fc-loadtool utility to run on the application (Linux) processor of your GTA02, and do it in a way that will be compatible with your distro from the previous paragraph. (I could send you my binary, built with some CodeSourcery toolchain for my Buildroot AP environment, but I doubt that one would be able to just plop it into SHR or QtMoko or whatever, and have it just work.) -or- 2b. You need to buy a T191 unlock cable that would plug into your Neo's headset jack - in that case you would be able to run fc-loadtool from your GNU/Linux PC, removing the need to build it for running from inside the Neo. But even with this magic cable, you would still need to satisfy requirement 1 above: you still need to ensure that there is no gsmd etc running, and you'll need to twiddle the download and power_on modem sysfs nodes by sshing into the phone. I'm thinking that one possible way to lower this entry barrier would be to produce and publish a bootable SD card image with the following features: * A known environment, eliminating the whatever FR distro you happen to be running factor; * Specifically designed for manual poking at the GSM modem - no gsmd and no normal functionality; * Have the special Linux image come up with the headset jack serial channel enabled and with the device screen showing pressable buttons for Modem ON and Modem OFF - thus anyone using the headset jack serial cable method would have no remaining barriers; * Have the image also come up with ssh access via USB enabled, and have fc-loadtool and some other tools already available inside - thus anyone using the sans-special-cable method would be able to ssh into the phone in a known way and run commands which can be given verbatim with no sophisticated preparations needed. Producing a Linux image like the above won't be an overnight deal, but it is something that I can work toward. I might have had some qualms about repercussions of using this software in Europe, Why? The radio transmissions from the illegally-free fw are strictly identical to those produced by the original (presumably legal) mokoN firmware, so how would anyone ever detect that you are using my illegally-free fw? The physical appearance of the device (as would be seen by a cop pulling you over on a highway for driving too fast or whatever) also does not change with illegal fw flashing, so if the device looked like a legal cellphone originally, it will still look the same... I'd be able and would love to test once this effort approaches some level of maturity. Ahmm, asking for some level of maturity before one is willing to even *test* a piece of software is rather dysfunctional. How would the sw *ever* reach any level of maturity without some people testing it early on, reporting their experiences, sending bug reports etc? Therefore, *someone* needs to be willing to act as an adventurous alpha tester, trying out what exists currently. I do concede though that the barrier to entry for prospective testers needs to be lowered, so I won't be holding my
Re: First small steps toward free GSM firmware
Norayr Chilingarian nor...@arnet.am wrote: Why not add information about free fw and loader to the mentioned wiki page? So that people who are not in this mailing list, may know about this fw and a free fc-load tool. Adding the info to the wiki would be a good idea indeed, but there would be several difficulties with that: * Editing the wiki requires a login account; I don't have one and don't feel comfortable asking for one. * Most of the Openmoko community sees my FreeCalypso work as being illegal, because they have voluntarily chosen to live and/or accept citizenship in repressive countries which deem it to be so. I suspect that the power-keepers of the Om Wiki would not want to have anything to do with my illegal project and its equally illegal fruits. Also, it would be good to have step by step instructions like get this source here, These 3 tarballs contain everything one would need: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/leo2moko-r1.tar.xz -- the source ftp://ftp.ifctf.org/pub/GSM/TI_src/wine/installed-env.tar.xz-- build tools ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r1.tar.bz2-- free flasher compile it like that, The leo2moko and loadtools tarballs contain README files with compilation instructions. get another source there, compile it, See above. and run this command with these arguments. The README file in the loadtools package tells you how to run fc-loadtool as well. I will grant though, that my current instructions are written assuming a highly technical user, and it would indeed be beneficial to have another, more hand-holding version for more novice users. What we need for that is a community volunteer who would be both able and willing to produce one. I.e., we need a community volunteer who can work with someone like me on one end (understand my instructions etc), and also be in touch with more novice users on the other end. Anyone wants to volunteer? All you would need to do is to go through the process of compiling and flashing my GSM firmware into your GTA02, become comfortable with the process, and then document it for others who would need more novice-friendly hand-holding. If you or anyone else would like to give it a try, you can start by downloading the 3 tarballs listed above and then attempting to follow the steps in the README files inside. Tell me where you get stuck, and I'll help you navigate that step. If you can go through the process once, even if it requires a lot of hand-holding from me, chances are good that you would then be able to document the process for others at the less technical level. VLR, SF P.S. If anyone manages to get as far as the loadtool prompt, please give me a shout before you type any flash erase or flash program commands - I would not want you to ruin your device by wiping out its very hard-to-recover RF calibration data. If you succeed in reaching the loadtool prompt, stop there and ask for further assistance - I will then tell you how to save those precious RF calibration values. There is no possibility of damage until you reach that loadtool prompt and type a flash erase or flash program command though, so prior to reaching that point, there is nothing to worry about - please play freely! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
Ian Stirling openm...@mauve.plus.com wrote: However, once anyone has used your work to change the IMSI of their phone I assume you meant IMEI. Phones don't have IMSIs, those are numbers stored in SIM cards. and you are aware of this, Yes, I will most likely be aware of it, as I will gladly hand-hold any criminal or want-to-be-criminal through the process of changing their IMEI. Just as an FYI - if you use the competing OsmocomBB software (which is much more readily accepted by this community), transmitting whatever IMEI you like toward the GSM network is even easier: because OsmocomBB doesn't know how to parse TI's FFS (flash file system) format and to extract the IMEI (or the RF calibration values) from it, there is no IMEI changing with OsmocomBB per se. With OsmocomBB you *always* have to enter your own IMEI manually in their CLI, and the software has no psychic powers to tell whether or not the number you've entered matches what's printed on the sticker inside the battery compartment. So if all you are after is transmitting a false IMEI toward GSM networks, a very easy way to do so has been available through OsmocomBB for many years before my recent work. Changing the IMEI in FFS (where either the phone's original firmware or my illegally-free replacement will read and use it) is necessary only if you want to not only transmit a false IMEI, but also retain the full functionality of the phone - OsmocomBB lacks the latter. if you do not stop distribution, Of course I won't stop distribution, I don't bow down to any f***ing governments. you are liable to conviction and a term of imprisonment not to exceed 5 years. http://www.legislation.gov.uk/ukpga/2002/31/section/2 UK laws don't apply to me as I have no plans of ever setting foot on UK soil. This is a poorly drawn bit of legislation, and in principle could also cover the operator of any website hosting such code, once the operator becomes aware that they are facilitating this. Yet another reason why I don't use any servers other than my very own: I would not want to entrust the distribution of my software to some cowardly law-abiding webhost who would take my ware down out of fear of being sued or prosecuted or whatever. In principle, this could lead to an EU arrest warrant, I have no plans of setting foot on EU soil either. or even a request for extradition. This one is truly laughable - I am the sovereign of my own micronation. What are they gonna do, send a diplomat to the Micronation of Falconia asking me to extradite myself? Paul Wise pa...@bonedaddy.net wrote: There are separate issues around the IP that you do not have permission to use. This is the illegality that he is referring to, not any potential spectrum/GSM/IMEI issues. Correct. I guess he would ignore the latter as well as the former though. Also correct. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
Jose Luis Perez Diez jl...@escomposlinux.org wrote: The procces to flash GSM firmware used linux, the serial port, and the fluid binary see http://wiki.openmoko.org/wiki/GSM/Flashing#Manual_Update_.28GTA01.2C_GTA02.29_.2F_geek_way Yes, and that exact same procedure should work just as well if you substitute your own *.m0 image built from my leo2moko-r1.tar.xz source in the place of calypso-moko11.m0. I say should because I haven't tried it myself - like Richard Stallman, I avoid proprietary software, so I use my own fc-loadtool instead of that fluid.exe for which I have no corresponding source. Just give it a try - if you don't like my illegally-free GSM fw, you can always reflash back to the official calypso-moko11.m0. Patryk Benderz patryk.bend...@esp.pl wrote: Can't we just use dfu-util? The GSM modem has its own processor, its own independent address space, its own address and data buses, and its own independent flash memory (NOR in a Multi-Chip Package combined with SRAM). Neither dfu-util nor the AP (application processor) bootloader it is talking to knows anything about that separate hardware block. In order to reflash the GSM modem, one needs to establish communication with Calypso's own boot ROM. That can be done either from a running Linux system on the phone's AP (i.e., from inside the phone) or externally via a classic T191 unlock cable plugged into the headset jack. (The latter approach makes more sense for FreeCalypso developers.) Either way, one needs Linux software running on the phone's AP in order to control the power to the modem and to enable the headset jack serial channel if you wish to use the latter. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
For those following the FreeCalypso project, I have just put out a packaged release of my GSM flash reading/writing etc tools: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/loadtools-r1.tar.bz2 Of course the source for these tools has been available all along in my freecalypso-sw Hg repository on bitbucket.org and in my snapshot tarballs on the FTP site, but the release I've just put out includes a prebuilt loadagent.srec image as well, so you can now compile and run my fc-loadtool utility without having to build an ARM7 cross-compiler toolchain first (to compile loadagent for the Calypso target). My fc-loadtool is a free (source-enabled) replacement for TI's proprietary FLUID tool documented on the now-classic Wiki page: http://wiki.openmoko.org/wiki/GSM/Flashing The *.m0 byte-reversed S-record format for GSM firmware images appears to have been used in all of TI's builds, both Calypso and the later LoCosto etc (see the http://scottn.us/downloads/peek/ find, for example), so it is no surprise that the official mokoN images linked to from the above wiki page use this format. My leo2moko port, which builds with TI's original toolchain under Wine, produces an image in the same format as well. My fc-loadtool can flash these *.m0 images as well as the more standard S-record and binary formats; I don't know too much about the exact capabilities of TI's FLUID as I never found a source for that one. You can thus use either fc-loadtool or the original fluid.exe to flash either an official mokoN image or an image you built yourself from my leo2moko port, i.e., the compatibility matrix is complete. Enjoy! Viva la Revolucion, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First small steps toward free GSM firmware
Norayr Chilingarian nor...@arnet.am wrote: then flash into your GTA0x GSM modem Wait, it works both on gta-02 and gta-04? By GTA0x I meant GTA01 and GTA02. GolDeliCo' so-called GTA04 is rather badly misnamed: GTA originally stood for GSM-TI-AGPS; thus a device that does not use a GSM chipset from TI cannot be properly called GTA0x. It is also quite misleading that Nikolaus markets his product as an upgrade to the good old Openmoko phones, as it is actually a downgrade: it replaces a free-able GSM modem (i.e., one on which the ability to run 100% free fw is within reach) with a non-freeable one, i.e., one on which such freeing is totally out of reach. And for the record, regarding the recent prolonged debate on this mailing list about the freeness of GolDeliCo's product or lack thereof, I agree totally with Bob Ham. However, I differ from Bob in that in my view, the closed proprietary nature of Nikolaus' product is not worth shedding any tears over because it is a useless product in the first place. The good old GTA02 from Openmoko is a MUCH better phone than any GTA04. Also, did you test if data connection works? Only CSD, not GPRS. I.e., I have tested CSD and saw it working; as to GPRS, I haven't tested it because I have not yet learned it well enough, but I suspect that it works - please test it yourself and let the list know what you find. I don't use phone calls, only encrypted ssl over tcp over 3g/wifi. There is no 3G on the real GTA0x, i.e., on GTA01/02. I am very interested if this can be flashed to gta-02 device, I have it flashed into mine. :) (unfortunately I don't own gta-04). Don't say unfortunately, you are very fortunate to have a much better device, which are sadly no longer made, and even more sadly, the leftover stock of Om-made ones is rapidly being destroyed by people like Nikolaus who cannibalize these great phones for plastic parts to make their inferior GTA04... Also, is there is a possibility to change IMEI during flashing? Yes, you can change the IMEI quite easily to whatever you like, and in fact the ability to do so is completely independent of which fw you use: my current leo2moko port, the future full FreeCalypso fw, or even the original factory fw from Om. The modem has a total of 4 MiB of its own NOR flash, divided (hw-wise inside the chip) into two banks: a 3 MiB bank at the lower addresses and a 1 MiB bank at the higher addresses. The lower-addressed 3 MiB bank holds the fw image - that is what you erase and overwrite when you reflash from moko10 to moko11 for example, or when you flash my FreeCalypso firmware. The higher-addressed 1 MiB bank (or more precisely, 7 sectors of 64 KiB each within that bank) holds the modem's FFS (flash file system) in a TI-invented format - one which I had successfully reverse-engineered even before I found the source, I should add. Whatever you do, DO NOT DESTROY YOUR ORIGINAL MODEM FFS! The original GSM modem FFS from Om's factory contains RF calibration data, and if you lose these calibration values, your precious GTA0x will become a brick (at least GSM-wise) unless you can get that RF calibration redone. For an idea of what kind of special RF test equipment would be needed to redo the RF calibration, see this document from TI: ftp://ifctfvax.Harhan.ORG/pub/GSM/Calypso/rf_calibration.pdf Needless to say, redoing the RF calibration would be *very* expensive. My fc-loadtool utility (which you will need to compile from source from my freecalypso-sw Mercurial tree) allows one to read out the content of a flash memory region and to save it into a file. If you are going to do any hacking at all on your GTA0x GSM modem, I recommend that you make a dump of your FFS sectors (containing these precious RF calibration values) and save that dump very securely, before you do anything else. The IMEI is stored in the same FFS as the RF calibration values, just in a different part of the directory hierarchy: the IMEI lives in an 8-byte file named /pcm/IMEI; the RF calibration data live in a bunch of files under /gsm/rf. I have not yet written a utility to edit that /pcm/IMEI file inside the FFS image in a user-friendly manner, so for now you would need to use a hex editor - the IMEI is stored in a very simple unobfuscated form in that /pcm/IMEI file. Sorry if my questions are a little bit off topic. Anyway I am very interested in free fw for my devices - OM gta-02 and n900. See above regarding Om GTA02. As to the N900 from Nokia, I doubt that much freeing can be done with its BB5 modem: I don't know of any leaked hw docs (let alone fw sources) for that modem, and I've heard something about it having a crypto-signature-checking bootloader - we are VERY fortunately to NOT have one of the latter in the Calypso! (Calypso's on-die ROM bootloader is actually awesome - not only is it completely non-secure, but it is also completely unbrickable: no matter what state you get your flash into, one can *always* break
First small steps toward free GSM firmware
Hello Om community, I am very pleased to announce that after many years of searching, I have finally found a copy of TI's firmware deliverable package for their Leonardo development board, i.e., for their Calypso/Iota/Rita chipset reference platform. It is the package which TI must have given to all of their chipset customers including Nokia, Motorola, Compal, FIC/Openmoko, LG, BenQ and many others, and which was used by all of these companies as the starting point for making their unique proprietary firmwares. This Leonardo firmware source can be found here: ftp://ftp.ifctf.org/pub/GSM/TI_src/Sotovik/ It is a source with some object blobs unfortunately (but that was expected), but it is complete in that one can build a functional fw image from the included sources and object libraries. This original code will NOT run on a GTA0x modem; it runs on the Leonardo board instead. If you are curious as to what the Leonardo board looks like, you can see a picture of it on page 10 of this TI document: ftp://ftp.ifctf.org/pub/GSM/Calypso/chipsets+refdesigns.pdf However, I have known for a long time that Om's GSM modem is actually very close to the Leonardo board in terms of how the Calypso/Iota/RF chip interconnections are wired. (I already knew this fact ~2y ago when I first saw the doc/calypso-signals.txt file in the OsmocomBB git tree - read that text file and judge for yourselves.) The implication from this hardware similarity is that it should be quite easy to take firmware code that runs on the Leonardo board and port it to run on the GTA0x modem instead. I have just proven the above hypothesis by producing a leo2moko port, i.e., a port from Leonardo to moko. You can find the Wine-buildable source here: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/ You can build that source under Wine (see instructions in the README file inside the tarball) and produce an S-record image which you can then flash into your GTA0x GSM modem with fc-loadtool - the latter is my free replacement for TI's proprietary FLUID. My own limited experiments indicate that this firmware is able to dial voice calls (makes the other party's phone ring), receive voice calls (I dial the number of the test SIM card in my GTA02 and see RING messages appearing in the AT command channel), and even make CSD (circuit-switched data) calls successfully - being the outlaw that I am, I take great joy in playing with CSD (which I plan on using for encrypted voice further down the road) and thereby showing my middle finger to the NSA etc. However, I have NOT fully tested the normal voice call operation: I have only verified that the fw places and answers these calls, but I haven't tested the actual voice audio. The latter omission exists because I have very poor understanding of the Linux-based software that needs to run on the GTA0x AP, and on my test GTA02 I run a very minimal buildroot environment on the AP. I have not yet figured out how to configure the AP-controlled audio system to pass the voice path between the GSM modem and the physical earpiece and mic, hence my current inability to test this voice path. Therefore, I encourage other community members to play with this firmware and see if it actually works end-to-end for voice calls. Viva la Revolucion, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building a new totally free phone
joerg Reisenweber jo...@openmoko.org wrote: I invite you to visit me at my home If you meant it seriously, you might as well give your address or GPS coords (by unicast if you prefer) - but I highly doubt that you meant it seriously. trying to force me to hand to you Hand to me? What me? There is no me - I could be dead tomorrow and absolutely *nothing* will change. I have never, ever, ever asked any of you Openmoko bastards to give anything to me. Instead I have merely voiced the demand that the materials be released freely to all Humanity - with a capital 'H' - and yes, I have indeed contemplated being the one to sacrifice my life in order for the remaining 7 billion people on Earth to gain free unrestricted access to a working turnkey GSM firmware package in the form of COFF objects with full symbolic information - a format which any embedded software engineer worth his or her salt should have no problem working with. [FYI, there is a patch to GNU Binutils which enables objcopy and objdump to read TI's COFF. The support isn't perfect, but it can easily be improved if need be - and I also invite you to grep for my name in the binutils ChangeLog files.] the MOST SECRIT SOURCES that everybody [...] had access to since ~2011. The reference to ~2011 makes me suspect that you are talking about the TSM30 version - it was indeed late 2011 when this code (first released in 2004 apparently) became widely available once again - and the latter happened because *I* had sent it to Cryptome on a CD-R. And you know as well as I do (or would know at least, if you ever actually *looked* at the modem code you're sitting on) that the TSM30 version is drastically different from what you got from TI as Om-Inc: different RTOS (Nucleus vs. SOS), different code structure, different flash file system, totally different hardware (ABB, RF and probably a different Calypso variant), almost everything is different. Heck, the TSM30 code isn't even TI, it's Purple Labs, a company that bit the dust. OTOH, if you are talking about something *other* than the TSM30 code, something that everybody passing the idiot test supposedly has access to, why don't you try being transparent once for a change, and actually post a URL? everybody passing the idiot test Like anyone else, I have my own strengths and weaknesses. What I'm good at is designing and writing embedded software, and some hardware too. I've been doing it professionally since ~2000 (and as a hobby long before that), and I make enough money doing it to support not one, but two full households on my sole income - so I guess I probably do it pretty well. I do it on the hobby side of my life too, so you can look at any of my projects and judge for yourselves. Like this one, for example: http://ifctfvax.Harhan.ORG/OpenWAN/ I'm sending this email through the Internet connection served by that SDSL modem designed and built by me: hardware, firmware and the logic in the FPGA - not to mention all the reverse engineering that was needed to get to this point. But I have my weaknesses too. I am NOT good with people, and I am NOT good with finding information that is passed around in a hush-hush manner. I don't do *anything* hush-hush: if I have or find something that may potentially be of value to others, I announce it publicly and openly, on the relevant mailing list. I absolutely do not understand how someone can be like you. I absolutely do not understand how ANY human being (or so-called human being) can be as cruel and callous as the three of you (JR, HW and PF). It's one thing to be slow with releasing things on occasion. I've been slow with releasing my software many a time, mostly because of my handicaps with modern technologies and my heavy use of seriously ancient gear - as well as my fear and distrust of any servers or online services other than my own. But it's an *entirely* different thing when you are holding something that someone else is very willing to DIE for, something that you could easily share with the whole world at absolutely zero cost, risk, loss or other detriment to you, and yet you STILL refuse to share. It absolutely baffles and boggles my mind that there are such cruel people living on this planet, and *especially* in the so-called community of so-called freedom and openness. And because it is so totally incomprehensible to my mind how someone can be like you, and be able to live with yourself while watching someone else's life wither away because of your selfishness, I find myself at a complete loss as to how one should interact with people like you. And I even promise I won't call the police or any other officials. It doesn't matter whether you call them or not - I am still the most wanted criminal in their eyes. Your country is a police state, no different from the way it was in WW II and just before, and I have no desire to go anywhere near it. Unless, of course, I were to enter it in the same manner in which both of
Re: Building a new totally free phone
Nick openmoko-commun...@njw.me.uk wrote: Your free phone idea appeals to me enormously, Michael. Yay, one more supporter! However, can GSM really be a base for secure communication anyway? I see that after your post, the thread on the mailing list veered off into a discussion of security. But that diversion totally misses the point: it isn't so much about secure communication as it is about the Four Freedoms of software: http://www.gnu.org/philosophy/free-sw.html When it comes to the matters of free software philosophy, I am very much like RMS. I have a major problem with carrying a device in my pocket containing firmware for which I lack the source - not because it is a security threat, but because it's morally wrong. The only difference between me and RMS/FSF is on the matter of legalities. While I define free software in terms of exactly the same 4 freedoms as the FSF, RMS and the conventional free sw camp add an additional condition that these 4 freedoms be exercised legally - whereas I add no such extra clause: whether it's legally free or illegally free, it's still free software to me. There also are some practical considerations that affect only feature phones and not smartphones. I have yet to encounter a phone UI design that doesn't suck, and I hope that most people on this list will agree with me that being able to customize the UI to one's preferences is an essential freedom that a geeky, empowered phone user should have - and I mean *really* customize the UI, not just twiddle menu settings, but being able to study, modify or even totally rewrite the UI code. Smartphones have a separate application processor to run the UI, so you can indeed play with the UI on Linux to your heart's content while keeping the modem as a black box. But this approach does not work for a feature phone where the UI and the modem are tightly integrated into a single whole. Exercising full freedom over the UI code in a feature phone requires having a complete and rebuildable source for the firmware suite as a whole. (Having the GSM stack pieces as binary objects to be linked with the UI source would work too, but then one gets tied to a proprietary compiler toolchain, etc. In any case we already have full source for the GSM stack thanks to the TSM30 and LoCosto leaks, so it's a solved problem now.) Now look at the situation from the perspective of a user who does NOT want his or her phone to be anything other than a plain phone. For such a user, a non-smart feature phone ought to be ideal, but if the user also wants the freedom to fully own the UI design, s/he currently has to pay for an otherwise completely unnecessary application processor. And when I say pay for, I'm *not* referring to the purchase price of the device - I would gladly pay a lot more for my ideal Free Dumb Phone than the most expensive GTA04 or Ubuntu Edge or whatever. Instead I mean pay for in terms of carrying extra weight, extra power consumption, extra system complexity otherwise unneeded, many additional points of failure, etc. *That* is what I seek to rectify with my Free Dumb Phone project, aside from the moral issue. Freedom is a right that all phone users should enjoy, not a privilege that's limited to just Linux smartphones to the exclusion of non-smart feature phones. I've heard that the encryption used is really crappy, and while some things like MITM forced reregistration to disable encryption and ease surveillance could be countered by appropriate phone settings, if the best encryption algorithm available can be cracked by a home PC in a few days, you're still screwed. The GSM encryption is a red herring - it makes absolutely no difference whether it's there or not. Imagine if the GSM encryption were perfect and unbreakable - what would change? Nothing. The over-the-air encryption is only between the mobile station and the network. In a public phone network, where you can dial the phone number of any stranger and hear each other's voices if the other party answers, encryption can't be end-to-end. The network has to be able to decrypt with one end's key and re-encrypt with a different key for the other end, so the network itself has (and must have) access to the cleartext form of your digitized voice. If I am the world's most wanted criminal and enemy #1 of all major governments, and they want to spy on my phone conversations, they aren't going to bother with cracking GSM over-the-air encryption, they'll just put in a lawful intercept at the switch. The only way to render all lawful intercept mechanisms ineffective is to use end-to-end encryption. That won't work when calling strangers, or calling the transit line to check bus/train schedules etc, but it's a very feasible mechanism for private and secure communication mechanism among family members, friends etc. Here in USA we have one advantage over the EU etc lands where most people on this list seem to be located: CSD (circuit-switched
Re. Building a totally new smart phone
Adam Bogacki adam.boga...@clear.net.nz wrote: I have not been able to find working links to freecalypso-sw anywhere. Not able to find *working* links? So the link I had posted earlier in this thread: ftp://ftp.ifctf.org/pub/GSM/FreeCalypso/snapshots/freecalypso-sw-SE52Fru5.tar.bz2 is not working for you? There is also a Mercurial source repository where the development takes place: https://bitbucket.org/falconian/freecalypso-sw But if it gets taken down because some suppressive person reports it, don't blame me. Of course Mercurial is a distributed SCM just like git, hence even if bitbucket.org takes it down, no source or history will be lost - but it will make the project inaccessible to others (except via the occasional snapshots which I post on my FTP site) until we (the FreeCalypso community, currently consisting of one developer and a few supporters watching from the sidelines) find a new Hg webhost. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re. Building a totally new smart phone
Adam Bogacki adam.boga...@clear.net.nz wrote: Now that I have dir 'freecalypso-sw-SE52Fru5' I am not quite sure what to do. Is there some documentation available, or a man page ? No documentation has been written yet, because there is nothing to document yet: all that's there is a FreeNucleus RTOS skeleton and some host tools for pushing code images to the Calypso. See my earlier posts in this thread for my planned roadmap of adding meat to this skeleton. The FreeCalypso project is still in a very early stage - most projects aren't even announced at all when they are this early in the development process. The only reason why I'm releasing this code at all is to satisfy the moral requirement: on my planet it is a crime to have some ware and not share it, no matter what the ware is. If you want to play with the current code just for fun (there isn't anything more that you would be able to do with it), you should be able to at least compile it, and if you have one of the two supported phone models (DP-L10 or GTA02), even run it and see the serial output from the FreeNucleus demo app. The steps are: 1. Build and install the arm-elf cross-compile toolchain. Look in the toolchain directory and it should be obvious. 2. Using that toolchain, compile the target-utils part. (Just run make in the target-utils subdir with the toolchain in your PATH.) You'll get the loadagent.srec image. 3. Compile loadtools - again, just run make in the corresponding directory. These are host tools, so they need to run on whatever Unix/Linux machine you'll be using to push code to the Calypso. If you are doing this with a Pirelli phone, FreeCalypso loadtools need to run on your PC/desktop/laptop. If you are playing with a GTA02 instead, you will need to either make a special cable to get to the Calypso via the headphone jack, or build loadtools to run on the GTA02 AP. 4. Once you've got loadtools, loadagent.srec and a compatible Calypso phone, you can actually try running this stuff. If you have successfully passed steps 1 through 3, but are having difficulties with this step, ask and I'll help you. If you are still struggling with one of the previous steps, work on that first. A command like this (from a laptop with a Pirelli DP-L10 phone connected and showing up as /dev/ttyUSB0): fc-loadtool -h pirelli /dev/ttyUSB0 or like this (from the GTA02 AP, talking to the Calypso part of the same phone): fc-loadtool -h gta02 /dev/ttySAC0 should produce output that looks like this: Sending beacons to /dev/ttyUSB0 Got beacon response, attempting download p command successful, switching to 115200 baud Sending image payload [a long line of dots]Sending checksum c command successful, sending b b command successful: downloaded image should now be running! FreeCalypso loadagent running Loaded via UART 1 (IrDA) at baud rate #0 TCXO clock input autodetected to be 26 MHz Executing init script pirelli.init Script command: w16 fb00 00A4 Script command: w16 fb02 00A4 Script command: w16 fb06 00A4 Script command: w16 fffef006 0008 loadtool The 3 lines beginning with FreeCalypso loadagent running will be printed by code running on the Calypso chip itself, which you would have built in step 2. Once you are at the loadtool prompt, you are interacting with the host utility you would have built in step 3, which is in turn communicating over a serial channel with loadagent.srec running on the Calypso. Loadtool has commands for things like peeking and poking registers, dumping and programming flash, etc. But right now the only documentation is the source code. Type exit, quit or ^D when you are done - it'll reboot the Pirelli phone or power off the GTA02 GSM modem. 5. The Nucleus-based skeleton for what is meant to become the main GSM firmware lives in the nuc-fw directory. You can build it as soon as you've got the arm-elf toolchain from step 1. Unlike loadagent, which is meant to remain universal for all Calypso phones (just like TI's FLUID), the main firmware obviously has to be configured for a specific target. The snapshot you are looking at has the beginnings of the configuration mechanism, but the latter doesn't do anything yet. For now all that's there is the Nucleus demo, and it happens to be the same for all phones, so just type make in the nuc-fw directory with the toolchain from step 1 in your PATH. You'll get ramImage.srec, which you can run on your Calypso phone with the fc-xram utility: fc-xram -h pirelli /dev/ttyUSB0 ramImage.srec If you are doing this with a Pirelli DP-L10, you should see the output from the demo app pouring on your terminal when you run the above command. Type ^\ to kill the fc-xram process on your host, but to stop the demo app running on the phone and make the phone usable again, you'll have to pull the battery and put it back in. (And then reset the clock, as this phone doesn't have a separate RTC
Building a new totally free phone
Bob Ham r...@settrans.net wrote: Please allow me to address a question to the community as a whole: if you can produce a free phone then why aren't you? Do it! What are you *waiting* for? Well, as you've asked the community as a whole, without restrictive language to exclude any particular factions of the community (e.g., the illegal faction, which I'm heading), I'll take the liberty of posting my answer. I am in fact working on building a new phone - as in new physical hw. However, the type of phone I'm seeking to build is quite different from what Canonical tried to fund, and from what most of this community seems to be interested in. I personally will never be happy with a smartphone *of any kind* as my everyday phone - instead the kind of phone I want is the kind we all had in the 1990s - a plain or dumb or feature phone. And that is the type of phone I'm working on building - a plain old-fashioned candybar phone without any smarts, and no application processor to run Linux or any other smartphone OS - only the traditional ARM7 baseband processor running traditional RTOS- based GSM phone firmware. But the plain/dumb/feature phone which I'm working on building will have one key difference from the ones you can buy for $20 on ebay: it will be 100% free as in freedom, in terms of both hardware and firmware. In the case of hardware it means publishing full, *unredacted* schematics and PCB EDA files, and choosing only those components for which full documentation is available. As for the firmware, yes, it will be an RTOS phone, no Linux or the like, no application processor, but the full C source for that RTOS-based firmware can still be published. And because such a totally free phone can never, ever, ever be produced legally, I am doing it as an explicitly-illegal project, under the aegis of the international community of outlaws, criminals and lawbreakers - i.e., my brothers and sisters. Of course a project of this magnitude won't happen overnight. But I handle it the same way I've handled all other projects which appear totally insurmountable at first: I divide the problem into bite-sized chunks, and work on the initial stages without worrying too much about what difficulties may lie in the later stages - I'll deal with those when the time comes. The FreeCalypso phone project has the following rough roadmap: 1. Build the FreeCalypso software/firmware first. In May-June of this year I have found some new and exciting TI firmware source leaks (archived on my mini-Wikileaks at ftp.ifctf.org) which will hopefully make it unnecessary for me to sacrifice my life in a gunfire exchange with the German or Russian police after kidnapping a moko-hoarder: these new leaks appear to be much closer to TI's mainline than the famous PurpleLabs TSM30 source, and I'm quite confident that by using these new leaks I can recreate something very close to what Om-Inc and its former employees/contractors have wrongfully withheld from Humanity - but in full source form. (The LoCosto leak in particular, which I'm backporting from LoCosto to Calypso, has the GSM stack in full source form, unlike what Om-Inc purportedly got, and it appears to be from the same time frame as Om's version - much newer than the TSM30 one.) I am working on this sw/fw part right now, using the Pirelli DP-L10 feature phone and the GTA02 GSM modem as my two bring-up/test platforms. In fact, the Pirelli phone fits me almost perfectly in terms of hardware features, and I have thought long and hard about just settling on it as my hw platform. But there are a few problems with this existing platform which have ultimately swayed me to my current plan of biting the bullet and building my own phone hw instead: a) No schematics could be found for this phone. (The OsmocomBB folks are also hacking on Compal/Motorola phones for which there are full schematics, but their hardware features are insufficient for me: I would really miss the tri-band support, the loudspeaker and the USB charging capability.) Schematics can be reconstructed by PCB reverse engineering given enough determination, but it would be hard to justify the effort given the other two problems: b) This particular phone has a bunch of extra chips beyond the essential Calypso chipset, and for most of these extra chips no docs can be found. While they support functionality which I can easily live without (camera and WiFi), their presence would tremendously complicate any attempt to reconstruct the full schematics, and may throw up issues when the time comes to implement thorough power management: how do we ensure that these undocumented and unsupported chips are fully powered down? c) The biggest show-stopper of all: the supply of these phones on the surplus market appears to have been exhausted. I've managed to grab a few before they disappeared, so I've got enough for my sw/fw
New GTA02s (was WIKI is in read-only mode?)
Radek Polak pson...@seznam.cz wrote: But one day your GTA02 will stop working - it might fall on the floor or whatever. GTA04 is only replacement - Although it may be the only available replacement at the present moment, it shouldn't remain that way for long. We, the FreeCalypso community (see below), need to make an effort to produce a new GTA02-like phone, Calypso-based. The first naive thought would be to contract with some pirate manufacturing company to make verbatim unauthorized clones of the GTA02, by reverse-engineering the GTA02 PCB and copying it verbatim, layer for layer, trace for trace, via for via. But it probably wouldn't be the wisest choice in technical terms, even if all of the components were still readily available (which they aren't) - the GTA02 board includes some really stupid design choices which I would want to get rid of if we're going to the trouble of building new boards - the Glamo being first and foremost. Because the single most important feature I seek to retain from the GTA02 is the Calypso, we will probably still need to send a dead GTA02 PCB to a pirate manufacturing / reverse eng shop to recover the PCB layout withheld by Closedmoko-Inc. (We already have the schematics for the Calypso block, TI's Leonardo reference design, but the corresponding PCB layout is currently missing.) As for the rest of the GTA02 board, i.e., the AP realm, I would want to simplify it quite a bit - take the Glamo, Wifi and BT out, connect the audio directly to the Iota (Calypso's analog part) so that nothing on the AP side needs to remain powered during a long voice call, and if the original Samsung AP is no longer available (which is probably the case), replace it with whatever other AP we can find that does the minimal functionality we need using the least amount of battery power. The Calypso chips themselves can still be obtained on the grey market. And once that supply runs out, we'll need to send a Spetsnaz unit into whatever TI facility has the old IC fabrication masks, seize those, and take them to some Chinese fab to restart the production of those chips. that's why it's important to support GTA04 - either by donation or buying the device. Not being Calypso-based, the GTA04 is a massive downgrade from the GTA02, and can't really be seen as a replacement except a very feeble one. Therefore, anyone who wishes his/her phone to be a *phone*, rather than a PDA or whatever, who sees the GSM processor as the most important part of the phone, rather than some unimportant modem, and for whom the concept of a Free Phone means running fully source-enabled firmware on the actual phone (GSM baseband) processor, should NOT waste his/her money on a GTA04 downgrade, and should instead donate to the FreeCalypso project - the latter will need to raise funds to pay for the professional pirate-manuf reverse engineering of the GTA02 PCB, to buy Calypso chips on the grey market, and to build the actual new Calypso phones. The firmware will be the user's choice of FreeCalypso or OsmocomBB. I choose the former, but others can use whatever they like. Maybe i am wrong but openmoko as company is for years dead and nobody of the old admins is willing to spend much time on maintaining the infrastructure. I guess the number of spammers is now 1000x higher the number of contributors, that's why it's readonly. And it's no wonder that GTA04 has separate wiki because of these reasons. Dr. HNS of Golden Delicious has been saying for quite a while now that with Openmoko being effectively dead, the Openmoko community is in need of a new successor/replacement, and that successor/replacement is OpenPhoenux. I agree with the first part, but not the second. There is not one but TWO camps seeking to continue the work of Openmoko in different directions: one is OpenPhoenux, the other is FreeCalypso. In order to become a bona fide new community, FreeCalypso needs its own web presence, its own wiki and its own mailing list. I already have a set of physical servers in my own sovereign micronation, all that remains to be done is the software setup - sysadmin stuff. I will post an announcement when the new FreeCalypso community home is up. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeTSM30/FreeCalypso project started
joerg Reisenweber jo...@openmoko.org wrote: Aha, and do you know how those files made it there?. You obviously don't which is a shame. Shame? You call it shame that I protect the anonymity of contributors who have chosen to be anonymous? The person who contributed the files in question to my FTP server chose to be anonymous - hence anonymous it stays. Are you trying to tell us that it was you or someone you know? If so, here is my sincere heart-felt thank-you, and a welcome to my side, the dark side. Alex Samorukov m...@os2.kiev.ua wrote: I dont understand where is achievement and i would expect that anyone with basic compiler/linker knowledge and some free time will be able to repeat this. You've obviously missed the most important part: my work in now in a public Hg repository, including my still-ongoing work to further Unix-ify the build process, i.e., make it less Windows-ish - an obvious prerequisite to any actual porting pruning work. Thanks to this work being done in an open, public source control repository, others *won't have to* duplicate it. The work continues; anyone interested is encouraged to check the Hg repository periodically. Expecting to do the next hg push in a few days. I'm also working with a comrade on setting up a new web home for this FreeCalypso project, with its own wiki and mailing list, so we can be our own bona fide community. It is also absolutely clear that distribution of this sources or firmware will be illegal, If you have chosen to live and accept citizenship in a country where such things are illegal, I feel sorry for you. If you like, I can give you a free immigrant/refugee visa to come to my country that has no such repressive laws. But otherwise, please keep your draconian laws to yourselves, and don't try to impose them on those of us who do NOT live or hold citizenship in any country with copyright laws. so it will not be possible to integrate in qtmoko or shr or any other open source product. But phones with the firmware flashed into them can instead be made available on the Silk Road, the same place where you would go to freely buy alternative medicine products such as cocaine, heroin or MDMA. (No, I don't use any of the just-listed products myself, but I know many wonderful people who do.) It is also very clear that osmocom bb team did much more interesting job When they get their entire stack running on the Calypso, have power management that is no worse than the original fw, and implement 100% of the original stack functionality, including fax calls, CSD (circuit-switched data) and GPRS, then I'll look at it. Until then, I shall continue working on the FreeTSM30/FreeCalypso code base. Patryk Benderz patryk.bend...@esp.pl wrote: right... now I remember - Michael Sokolov. I am not using my old name any more, I go by Michael Spacefalcon now. Yes, I know, my Ancient UNIX email address still has my old last name as part of my login name - a login name is harder to change than a gecos field; see http://xkcd.com/910/ I will always keep this email address for backward compatibility, but I will also have a new one based on my new name when I get my new mail server set up. I am glad you have changed your MUA Nope, no changes there. SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeTSM30/FreeCalypso project started
Alex Samorukov m...@os2.kiev.ua wrote: Which country is that? dprk ? :) Yes, I love it. SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeTSM30/FreeCalypso project started
Bob Ham r...@settrans.net wrote: You moved from Canada to North Korea? I have never lived in Canada. I don't live in North Korea either. In fact, I don't live anywhere at all - being an active-duty internationalist operative, I only *operate* in various countries, working against their governments and laws, but don't actually live in any of them. I don't understand why the people here find this concept so difficult to grasp - that's just how all military forces work. Both of my grandfathers were in Germany in the 1940s as part of the Red Army. They were on German soil, but they weren't living there, and they most certainly did not obey any of the German laws that were legally in effect at that time - instead they obeyed the orders of their Soviet Army commanders. Ditto with me and the countries I operate in. This will be my last post in this particular subthread; any further mails involving the subject of countries won't elicit any response from me. Drop the subject and move on. SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeTSM30/FreeCalypso project started
Patryk Benderz patryk.bend...@esp.pl wrote: There is leaked TSM30 source code for this GSM chipset firmware... Yes, that's exactly what I'm using as my starting point. maybe there also is some documentation? As far as hardware documentation goes, all of it is neatly gathered on my FTP site: /pub/GSM/Calypso on ifctfvax.Harhan.ORG. 100% complete as far as I can tell - haven't spotted any omissions yet. But software documentation is a different story. The TSM30 source release is just bare code, no documentation whatsoever, excepting the scattered comments in the *.[ch] files and build scripts themselves. My common sense tells me that TI had most likely provided its customers (handset manufacturers) with some hand-holding documentation on how to work with their firmware - where to go to make product-specific UI, hardware support, etc changes, how to flash the firmware, how to talk to it - setting IMEI numbers, RF calibration, testing, etc. If some kindred soul would be willing to leak that documentation (e.g., put it on a .onion and have some disposable tormail.org account post a link to it), it would be immensely helpful to the FreeCalypso project. But I won't sit and wait for it with bated breath - I'll just bite the bullet and painstakingly study the code to recover that knowledge. It will take longer, but the project will still proceed. Did you checked this? http://tpb.noflag.org.uk/torrent/6834542/TSM30_Source_Code http://www.monova.org/torrent/4899164/TSM30_Source_Code.html I'm the guy who sent that ware to Cryptome.org, from where those torrents were then made. :-) joerg Reisenweber jo...@openmoko.org wrote: You also know that what Openmoko had access to (mostly the AT interpreter) plus much more is available as leaked source in internet since ages. And you know as well as I do that the widely-available version, the one I am currently using as my starting point, is set up to target the wrong hw platform and the wrong feature configuration. Being able to take a peek at a version that is already configured as necessary, even if that version is mostly binary objects, would be a very helpful aid for the FreeCalypso project seeking to recreate that configuration starting from the wrong but full-source-available version. But I will persevere nonetheless, with or without the bits which you are hoarding. We also granted access to what we had to many volunteers that didn't sound as lunatic and mad as you did - your fault. It isn't just me that you are hurting - it is the entire GTA02 user community. I am pretty confident that I can rip out the TMS320DA250 ties from the FreeTSM30 code base, and make it run on a Calypso-only phone. I will also *attempt* to recreate the changes you have make for the moko version (custom AT commands, wake-up signaling, whatever else is there that I'm unaware of), that is, recreate them independently while being denied a peek at your version. If I succeed in that part, great. But if not, I will just screw the GTA0x and find a Calypso-only phone to use, with no AP and hence no need for the wake-up logic, etc. Either way, I will have a working cellphone in my pocket, running my FreeCalypso firmware - which is my goal. But your refusal to share the moko-specific modifications you have made to the firmware will make it less likely that my firmware will be a functional drop-in replacement for the old one, which obviously has a direct bearing on others' ability to benefit from my work. So in the end it will be the community which you are screwing, not me. C) you threatened our engineers in private mail (one or 2 years ago), Not just private email, but quite publicly too, on this very list. to a degree where anybody else would've sent the police Why don't you go right ahead - I challenge all police forces of the world to try to stop me. To me you sound like a silly consequential angry child. This silly consequential angry child will produce a working, fully-functional, full source, illegally-free GSM firmware for the Calypso, and make it available to the entire worldwide community of lawbreakers, anarchists and revolutionaries. That *will* happen with or without your help. The *only* part that isn't certain is whether or not that firmware will be usable on GTA02 phones as a drop-in replacement for the old binary-only one. If it isn't, the community will know whom to blame. Oh, anybody said glamo? You mean this: $ hostname ifctfvax.Harhan.ORG $ ls -l /pub/GSM/GTA02/Glamo total 2808 -rw-r--r-- 1 msokolov 248664 Oct 20 2011 Glamo_3362_CmdQ_Spec1.pdf -rw-r--r-- 1 msokolov 1919990 Oct 20 2011 Glamo_3362_Datasheet_V1.0-Full.pdf -rw-r--r-- 1 msokolov 147740 Oct 20 2011 Glamo_3365_2D_Engine_Spec_v1.0.pdf -rw-r--r-- 1 msokolov 390670 Oct 20 2011 Glamo_3365_3D_Engine_Spec_v1.0.pdf -rw-r--r-- 1 msokolov 102131 Oct 20 2011 Glamo_3365_MPEG_Engine_Spec_v1.0.pdf Available via anonymous FTP, as usual. Viva la Revolucion, SF
FreeTSM30/FreeCalypso project started
Hello ex-Openmoko community, The purpose of this announcement is to let everyone interested know that my effort to liberate the original, fully functional (non-OsmocomBB) firmware for the Calypso GSM baseband (as found in Closedmoko GTA0[12] smartphones and many simpler feature phones) has not been abandoned. Lacking the source or even semi-source for the specific version of the Calypso GSM firmware that was used by the Closedmoko company (FIC), I am taking the alternate approach: starting from the already-liberated version of the same Purplelabs GSM stack for a different Calypso phone (TSM30, aka SPT2C platform), and seeking to back-port it to the Leonardo (reference board for basic Calypso phone designs) and to the GTA02 GSM modem. Specifically, I have just made the first successful step on that long journey: I have successfully recompiled the Calypso GSM firmware image from HispaPhreak's source code release, and done so without resorting to a Windows machine or VM - using Wine version 1.5.23 under Slackware Linux version 13.37. Of course it still targets TSM30 hardware, so don't even think about flashing it into a GTA02, but it's just the first step of an exciting journey ahead. Previously I kept saying that HispaPhreak's TSM30 release *seemed* to be the complete source for the GSM stack running on the Calypso, but now we know that it actually *is* complete - yay! I am doing this work in a Mercurial source control repository, and of course I share it freely with the world. Until I get my new Solaris ZFS-based server up, I have temporarily hosted the Hg repository here: http://www.harhan.com/Hg/FreeTSM30/ The README file at the top of the Hg source tree summarizes what has been done before me, what I have done, and what I plan to do next. The ultimate goal of this project is to back-port the code to run on the GTA02 Calypso, producing a new GSM firmware image that comes as close as possible to the original Closedmoko one, but is fully built from source, no binary blobs. Of course I am lucky to have a GTA02 unit, which has become a rare privilege now that the stock has apparently been exhausted. To those who don't have a GTA02, desire one, but can't get one because of the discontinued production and stock exhaustion: don't despair yet! After we are done liberating the Purplelabs Calypso firmware and getting it to run on Leonardo/GTA0x platforms (not SPT2C/TSM30), we can then address the hardware shortage problem by building a new Calypso-based phone motherboard - essentially do what Golden Delicious did, but instead of going to that UMTS modem, keep the Calypso. My FTP site already has the complete schematics for the Leonardo board (TI's reference design for a Calypso phone), the PCB layout of the Calypso block can be recovered by sending a dead GTA02 board to a PCB reverse engineering shop (think pirate manufacturers), and I have some ideas as to how/where we may be able to obtain some Calypso chips and related components. But this is a topic for much much later - let's get the firmware liberated first, using our existing GTA02s. Just don't despair if you aren't one of the lucky GTA02 owners. Viva la Revolucion, Michael Spacefalcon, formerly Michael Sokolov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeTSM30/FreeCalypso project started
Harley Laue losinggenerat...@gmail.com wrote: While I think the project you're working on is great, you come off sounding petty using terms like Closedmoko. I /still/ don't think any open hardware phone has come out without some kind of NDA attached to some part (I could be wrong.) My beef isn't so much with the NDA itself, but with their unwillingness to break it all these many years after the company has gone defunct and all engineers have been let go. I have lost count of how many NDAs I have broken, but it is probably somewhere around 20. It would be *so* easy for one of those guys to leak the ware completely anonymously without ever being identified... Hence their refusal to do so is what makes them criminals in my eyes, and they shall always remain so until and unless a leak occurs, anonymous or otherwise. Just to be clear, I shall continue with my FreeCalypso project based on HispaPhreak's release whether or not we ever get a leak of the Closedmoko bits. After all, the latter were mostly object code as we've all been told (let me guess guys, your TI bits have files like l1c.lk, l1d.lk, gmm.lk etc, right?), whereas HispaPhreak's version is 100% full source. It is unfortunate that the full source version targets the wrong hw platform, and it will take some work to back-port it to Leonardo/GTA0x, but the result (a full source fw version for the GTA02) will certainly be worth it. But if someone does leak the semi-source for the moko version, it would probably help a lot with guiding the back-porting effort, particularly when the time comes to recreate the moko-specific logic of the AP and BP signaling each other to wake up. SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] No gta-04 available
Hello, Could you inform me when the 3g or the 4g motherboard, or best, a freerunner with this will be available by a supplier ? Tanks by advance. mparchet 2012/10/30 Al Johnson openm...@mazikeen.demon.co.uk: On Monday 29 October 2012 20:16:34 Michael Parchet wrote: Hello, The switzerland mobile phone providers will prepare the LTE (4g) network. Do you think to make a 4g matherboard gta05 ? Option now have LTE modules, but they are a little bigger than the gtm601u in the GTA04 so aren't quite a drop-in replacement. They do say the 601 will fit on the footprint of the 801 though, so they are probably electrically compatible. http://www.option.com/en/products/products/lgamodulegtm801u/ In my opinion, with only a 3g maserboard, the future freerunner will be quickly out of date. Whath's your opinion ? Any low volume product that isn't backed by a big corporate is going to be a bit behind the times simply because the manufacturers won't release That said, the 4G issue looks like a relatively easy problem to solve. Getting the economics to work seems to be the biggest hurdle at the moment. Best regards mparchet ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] No gta-04 available
Hi, I'm waiting for an openmoko freerunner phone with gta04 or more recent. Do you know when it will available ? Best regards mparchet 2012/10/28 Xavier Maillard xav...@maillard.im: Hi, It might be a good idea to have such a survey on your website on what components people excpect on their tablet. I second that (if that's important). Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] No gta-04 available
Hello, The switzerland mobile phone providers will prepare the LTE (4g) network. Do you think to make a 4g matherboard gta05 ? In my opinion, with only a 3g maserboard, the future freerunner will be quickly out of date. Whath's your opinion ? Best regards mparchet 2012/10/29 Michael Parchet mparc...@sunrise.ch: Hi, I'm waiting for an openmoko freerunner phone with gta04 or more recent. Do you know when it will available ? Best regards mparchet 2012/10/28 Xavier Maillard xav...@maillard.im: Hi, It might be a good idea to have such a survey on your website on what components people excpect on their tablet. I second that (if that's important). Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Hi, Arguably those two paragraphs are already well satisfied by oFono. oFono probably now has the advantage in terms of maturity and deployment, is compilable by a standard C compiler, and has a recent version packaged in Debian. FSO is compilable with a standard C compiler as well. Every tarball release we did has been shipping C files. The following may sound pointlessly controversial, but I don't intend it that way; I think it may help the FSO developers to review and understand more precisely their objectives. Why is FSO still needed at all, given that oFono exists and appears to have the development mindshare and advantages noted above? Would your objectives be achieved more quickly or easily by switching to oFono and contributing any needed additions to that? Oh, FSO is so much more than oFono. If you want to compare, then compare oFono to fsogsmd alone. As for the comparison between those two, well, fsogsmd was first, has (IMO, of course) a better architecture, a better API, and supports other modems. And there's no agenda of a company behind – some people may view that as an advantage, rather than a disadvantage. I don't see why we should invest time in something we consider not being superior. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: server update
Very well summarized, thanks Timo! Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
On 02/29/2012 05:35 AM, Nikita V. Youshchenko wrote: Then, we have to define a keyboard layout. QWERTY or ABCDEF. Add numeric keys or make them Num+QWERTY to save one row of keys. And to unsimplify, we need a US, a UK, a German, a French, an Italian layout and maybe Chinese, Japanese etc. This is doable by exchanging keycaps or keymats - but we have to stock and provide several different ones. Layout could be changed via software. What is actually printed on keys, does not matter much, it is changable on user side. Or just don't print it, a la http://www.daskeyboard.com/model-s-ultimate/ . :) For me, it's the tactile feedback of a hardware keyboard I like--and I don't mean making the phone vibrate or the whole screen's clicking down or the phone's making a click sound when I hit a key, but being able to clearly /feel/ the edges of the keys so I know what key I'm hitting before I hit it and even when my finger is covering the keys. No idea if you could simulate it well enough with something like Senseg's (electro-static) haptics technology ( http://senseg.com/ + http://senseg.com/technology/senseg-technology ), but I have my doubts, and I'm sure patents and licensing costs make that a no-go, anyway. Mike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Could it be possible that those greedy bastards don't even exist except in your wishful thinking? I don't buy that - I don't buy the fairy-tale that each and every former employee of Om-Inc who had NDA'd access to The Treasure has refrained from sneaking a personal copy home with him. That is a preposterous claim. There most certainly do exist former Om-Inc employees who are sitting on personal copies of the deliverable which that company had received from TI. I know of at least two former Om-Inc employees who have demonstrated detailed knowledge of what that deliverable contained - I take that as evidence that they are the ones most likely to be holding on to personal copies. Not 100% proof, but enough evidence to hire some professionals to do a kidnapping operation as soon as I can gather up the funds to do that. And if the people whom I suspect to be holding personal copies of the TI-Om deliverables have deleted those personal copies, well, too bad for them, as the hot soldering iron won't get taken out of their rectums until a copy of the ware is in my hands. So, to those reading this who are holding those personal copies: just upload a copy anonymously to some warez site, announce it on this list using an untraceable anonymous email account, and then you will no longer need to worry about getting kidnapped and receiving thermorectal treatment. This sounds like shooting yourself in the foot. As soon as I would do that, I can't sell you a GT04 any more because I don't receive any more of these modules. So it is not a realistic option. The obvious solution is to use two separate unconnected identities for the NDA-signing and NDA-breaking activities. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: IMHO that has nothing to do with freedom at all. Just personal enrichment. Objection: it is *NOT* personal enrichment if I share. If I were to ever get a hold of the ware that I am after, I would NOT greedily hoard it for myself like its current holders are doing, I would make it available to everyone who wants it. And does *not* bring forward the community. Depends on which community you are talking about. If *your* community has chosen to cripple itself by limiting to just those means which don't offend the repressive legislative regimes, then indeed your community won't benefit from IFS (Illegal Free Software) work. However, my work on building a Totally Illegal Phone (whether I do it by kidnapping an ex-Om-Inc employee and beating the TI deliverable out of him, by taking the publicly leaked TSM30 source and modifying it in a copyright-disregarding manner to backport it to Leonardo/GTA02, or by taking OsmocomBB and adding illegal enhancements to it) will most certainly benefit a DIFFERENT community: a community of brave and determined revolutionaries who are officially At War with all law-making regimes and who would like to use the enemy's Public Land Mobile Networks infrastructure in our asymmetric warfare against them. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: That points nowhere. For you maybe, but not for me. I think you should instead try to go the legal way, I disagree. Man-made law of every kind is my arch-enemy, and the purpose of my life is to break those laws. Without law-breaking life becomes devoid of meaning. so you can't be attacked in court, That is irrelevant to me: I can never be attacked in court because I WILL NEVER SHOW UP TO COURT. because it's way too easy to attack you if you do something illegal. No, it isn't easy. Theses companies have a lot of lawyers and spend a lot on it. So what are they going to do? Send me threats? How? By email? I'll laugh at them, then hit delete. By postal mail to my PO box? There's a paper recycle bin conveniently located right next to it. Look up one of the addresses I've used for receiving shipments, addresses that look like real physical ones? Well, they only *look* like real physical addresses - in reality they are mailbox services. So GOOD LUCK on trying to force me to show up in court... The way to go is to improve nuttx port on calypso phones. it's not that complicated. It may not be that complicated, but it is morally wrong. It is morally wrong to help or support someone who is guilty of hoarding the good code and denying it to the public. Harald Welte is the leader of the entire Osmocom family of projects. He is a former employee of Om-Inc and I have every reason to suspect that he is hoarding a personal copy of the good code, although he'll obviously never admit to it. That makes Osmocom morally tainted, i.e., it is morally wrong to contribute in any way to any of the projects under that umbrella, particularly OsmocomBB. Just to be clear, there is nothing wrong with merely *using* what those projects have already produced: Leninist philosophy states that any and all means are acceptable, so we can use whatever tool or resource does the job. But it *is* wrong to help them with contributions. Therefore, if I ever feel like making enhancements to the OsmocomBB code base, I'll be sure to make them non-GPL-compatible so that my work benefits only the illegal community and not the legal one. so please instead of attacking the openmoko people which points nowhere( they won't give you the source, they could have given it to you already if they wished but they didn't. so I guess they don't want to and will never give you theses sources), I can still kidnap one of them and do the thermorectal procedure. And the prospect of going to prison for kidnapping/assault/battery/ whatever they call it doesn't scare me one bit - I am very confident of my ability to upload the seized code to some warez site *before* the cops arrive and get me. Then I could spend the rest of my life in prison or perhaps die in a gunfire exchange with the police while resisting arrest, but the deed will be done: the code will be FREE - once it hits a public warez site, it'll get copied by all the other warez sites and the copyright/NDA police will never be able to take all of those copies down. do something productive and join us in making osmocom-bb usable(by improving the nuttx port on calypso and then porting osmocom-bb on top of it). so instead of waisting time on useless things, please join us. NO, NEVER. If I have NO other option, I would rather take a gun, shoot one of those bastards who are denying me the good code, then shoot myself before the cops arrive. I will be dead, but my tormentor will be dead too, so that makes it a fair exchange, a life for a life. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
arne anka openm...@ginguppin.de wrote: so, what do you group tour subscribers plan to do with the replaced parts? just sink them in the waste basket? hang on the wall? or do you have a meaningful solution? Please please please don't waste them, please make them available to people like me who like GTA02 BETTER than GTA04 (for Calypso GSM firmware hacking reasons). One way to do that would be to ship the GTA02 PCBA back to Goldelico who will then save these parts for resale to the interested people. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
arne anka openm...@ginguppin.de wrote: but if nikolaus is ok with that (re-stocking the used GTA02 boards, that is :-), that's certainly solution. As I understand it, he already does that. - what's so hackable about the calypso fw? as far as i recall, it was a major afford to get an updated fw and make it flashable. Certain individuals in the Om community are holding personal copies of that firmware in semi-source form, or more precisely, in the form of object modules with full symbolic information (names of functions, global variables, etc) - not quite the same as full source, but pretty close in terms of hackability. Unfortunately the greedy bastards are refusing to share, hence extracting the ware from them requires the use of a soldering iron, inserted rectally. If anyone is willing to perform such an operation for the benefit of the community, I can supply the names of the suspects and my best available information as to their physical whereabouts. Alternatively, there exists the TSM30 firmware source: it's a different Calypso phone, and that code is full source and readily available from Cryptome.org and other sites. Unfortunately the TSM30 hardware has been very heavily modified from the Leonardo* baseline (whereas the GSM part of GTA02 is almost identical with Leonardo), hence backporting the TSM30 source to run on a Leonardo-style Calypso subsystem like GTA02 would take a lot more work than what we could do if we had the real GTA02 version of the semi-source. But the backport of the TSM30 to Leonardo/GTA02 does not seem impossible, just really difficult, and I am hoping to find the time some day to tackle that project - in my view, it is an ethically superior approach than OsmocomBB. [*] Leonardo is TI's reference design for the Calypso/Iota/Rita chipset; liberated Leonardo board schematics and chip docs for all components are on my public FTP site. There is also a possibility that someone in the People's Republic of China may have a copy of the same semi-source deliverable which FIC got from TI (that exact same deliverable or a very very similar one must have been given to *all* makers of Calypso-based feature phones), but who would be more open to sharing than the Om bastards. Any comrades in the PRC reading this, you know whom to email. and how much less hackable is the new gsm chip's fw? We shall only know if Nikolaus were to grow the b*lls to burn or shred his German passport, apply for citizenship in the Principality of Sealand, the Republic of New Poseidia or some other (micro)nation in which NDAs have no legal validity and in which all intellectual creations of every kind are automatically and unconditionally in the public domain, and publicly share all materials which he has received from the maker of whatever GSM/UMTS module he has used in the GTA04. If and when Nikolaus does the above, I shall gladly and immediately buy a GTA04 - but not till then. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] [FOSDEM] Third call for sessions for the FOSDEM cross-distribution miniconference
Am 21.12.2011 um 13:37 schrieb Dr. H. Nikolaus Schaller: Looks as if they urgently need more talks. This is IMHO a chance for SHR, QtMoko, FSO to present the latest great progress to a wider audience! Yeah, there's just one thing that's annoying me... 15 minutes is pathetic. Ok, for FSO we could split that into two talks like one describing the idea and the architecture and the other one describing the state of the ports. Anyone volunteering to submit part 2 if I submit part 1? Cheers, :M: ___ App-Developers.de - Lauer, Teuber GbR Frankfurter Str. 181 - 63263 Neu-Isenburg - Germany Tel. +49 6102 8376 32 - Fax +49 6102 8376 33 Twitter: twitter.com/AppDevelopersDe ___ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak pson...@seznam.cz wrote: With my wooden case i had fully working phone - only single part that was from GTA02 was the speaker + microphone. I really dont think this is big problem. Yes, and if I wanted to do the same thing (use a self-made wooden case), I could have done it just as well with my own APH01 PCBA (quad-band Calypso based on the liberated Leonardo+ schematics) rather than GTA04. So I still disagree with your reasoning chain of (shortage of existing GTA02 units) - (GTA04 is the only solution) MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak pson...@seznam.cz wrote: i am rather saying: (shortage of existing GTA02 units) - (GTA04 is the solution) It is *a* solution for some classes of users. It is not *the* solution for all use cases. Also pool graphics performace of GTA02 make the user experience very bad - hardly acceptable for normal users and this is fixed in GTA04 and that's one more reason to upgrade. Fancy graphics is something I couldn't care less about. I would be quite happy with the most bare-bones UI which should be implementable just fine on the GTA02, producing responsiveness no worse than my ancient Mot V66. Instead what I want is an everyday cellphone that does voice calls, SMS and CSD, and does so using software and firmware for which I have access to inspectable and recompilable source, be it legal or illegal. I'm currently in the process of trying to acquire a TSM30: that may be the right phone for me, given that my GTA02 is currently a paperweight due to the lack of an army capable of invading Germany and prying the Closedmoko fw semi-src from its hoarders. I should be able to acquire at least one TSM30, but I'm hoping to be able to find at least two: since no TSM30 schematics are available (I don't know whether it's because they've never been released in the first place, or if they are available in some obscure location and those who know that location are selfishly refusing to point me to it), I will probably have to reconstruct them by taking an actual TSM30 PCBA and sending it to a professional PCB/PCBA reverse engineering lab where they would remove all components, separate and image the layers of the PCB or whatever they do to reconstruct the netlist and the layout of inner layers. Unfortunately that process requires destroying at least one PCBA. :-( Of course hiring a professional PCB/PCBA reverse eng lab is devilishly expensive, but it should still be less expensive than hiring the kind of people who could help me recover the semi-src I'm looking for by some brute-force means... Not to mention the cost of restructuring my life to avoid ever visiting any country that does extradition... What would I do if someone was willing to release an anonymous copy of the GTA0x (or Leonardo baseline) Calypso fw semi-src, so that instead of expending 100% of my life-force to recover that jewel I could actually do something productive? Well, in that case I would start by taking my GTA02 out of the box in which it came, and putting my own very simple distro on the Samsung application processor. I would then bring up the Calypso, using the knowledge of its code to understand the process better. Maybe even find and fix a bug or two in that Calypso fw in the process. After bringing up my own distro on the GTA02 that uses built-from-src code for both the AP and the BP, I would quite seriously consider building my own replacement PCBA just like Dr. HNS did. If he and his team could do it, why can't I? Expect that my hw design goals and target audience would be quite different. I would keep the Calypso, no UMTS, but possibly make it quad-band, copying the quad-band GSM RF front-end from the Leonardo+ schematics - if I can find a place to get that little passive component. While I have no problem with the Samsung AP on the GTA02, I realize that the component is most likely unobtainable. But since I would be targeting a user base for which the part that really matters is the BP rather than the AP, I don't really care which AP to use. Perhaps I would borrow the OMAP AP from the GTA04, or maybe find some significantly cheaper really basic AP that can do the absolutely minimal functions I expect from it. And I would most certainly omit the features/components/complexity that is of no interest to me: WiFi, BT and the accelerometer/etc sensors. The result would be a device meant to be a *phone*, not something else. But I'm not going to put any more serious thought into that project until and unless I can obtain the source or semi-src for the Calypso fw, i.e., either a GTA0x/Leonardo/other non-TSM30 version or some docs for the TSM30 which would make that already-available source version a more viable starting point. I am not saying that everyone should upgrade. I would personally wait a bit until i knew that the power management in GTA04 will be working - without that the it's not much usable as phone (i.e. charging twice a day is not comfortabe and will kill your battery soon). But it's up to anyone to collect objective information and decide. PM issues are one of the major reasons why the absence of src/semi-src for the Calypso fw is making my GTA02 serve as a paperweight. From what I understand, the engineers at Openmoko-Inc took the Leonardo baseline code and made their own adaptations to it. One of the latter was the addition of the GPIO signal by way of which the BP wakes up the AP on certain conditions - an incoming call being the prime example, one would hope. I've heard that they
GTA04 openness/freedom (was GTA04 Group Buy - Status)
Dr. H. Nikolaus Schaller h...@goldelico.com wrote: it is obvious why the open and free software community needs a device where every individual has control over the software. But isn't the GTM601 GSM/UMTS modem in the GTA04 just as closed as any other? How is then GTA04 an improvement over GTA02 in terms of openness/freedom? If anything, it's a step backward from the GTA02 in terms of openness/freedom: at least for the GTA02's Calypso the free world already has free physical access (legalities aside, please) to full hw documentation for all guts of that chipset and to the fw source for a different Calypso phone (TSM30) which may some day be back-ported to Leonardo/GTA02. For the GTM601/GTA04 we don't have even that. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak pson...@seznam.cz wrote:
What's the point in investing time into device that is no longer manufactured
and the number of users is decreasing to zero?
If it is so worthless in your eyes, why are you (not Radek personally,
but some others in this community) guarding that moko fw src/object
code so zealously? Why are you so unwilling to brighten up at least
one person's life by having some anonymous account upload a copy from
some public WiFi hotspot?
Did you realize that very soon you will loose the freedom to buy GTA02?
Well, I've already got mine. :-)
But seriously, swapping PCBAs between GTA02 and GTA04 is a zero-sum
game. The number of existing {case + LCM + GSM antenna + other bits}
sets is finite, and it stays the same whether you leave the original
GTA02 PCBAs in those cases or replace them with GTA04s.
And if someone solves the problem of existing case shortage by making
a new case and starts selling full GTA04s with cases, perhaps I'll
make my own Calypso-based PCBA to stuff into those new cases. I've
been thinking about using Leonardo+ schematics (quad-band Calypso
reference board) as my starting point, including the quad-band GSM RF
front-end, and slapping some simple application processor in front of
it, whatever is most readily available. Maybe even the same OMAP
which Dr. HNS has used in the GTA04 - I don't really care what the AP
is as long as it can run Linux with full source, but I want the GSM
part to be Calypso, because it's the best-understood cellular baseband
chipset from the hacking standpoint.
MS
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
Ben Thompson ben.thomp...@yandex.ru wrote: If someone on this list from Spain would buy a TSM30 I would be happy to buy it from them (at a reasonable price), Me too. Alternatively, if someone else succeeds in obtaining a TSM30, please share your resulting findings: * exactly what chips are inside * any other hw reverse engineering notes * the results of any attempt to run an image rebuilt from the leaked sources. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
Ben Thompson ben.thomp...@yandex.ru wrote: Here is my attempt :- http://wiki.openmoko.org/wiki/Image:Gta02a6_comms_chips_under_shield.JPG This photo is pretty good - thanks! From it we can tell that: * The RF transceiver chip is TRF6151C, just like the one on the Leonardo board for which we have the docs. It's a *quad-band* GSM RF transceiver chip, although it isn't obvious from the pinout: it has 3 differential-pair RF inputs, but one of them (the one called GSM in the datasheet) handles both 900 and 850 MHz Rx. (1800 MHz Rx is on the DCS input pair and 1900 MHz Rx is on the PCS one.) The RF outputs going to the PA are single-ended and combined: one for the low bands, one for the high bands. * The RF PA (power amplifier) is the classic RF3166, once again the same as what one would find in a vanilla Calypso phone. The Leonardo board schematics feature AWT6108, but also say: Second source option is RF3133 from RF Micro Devices that can be used on same footprint. * The shiny block component (corresponding to U401 in Om's component placement PDF doc) must be the antenna switch. One can also see 3 little components next to it, corresponding to U402 through U404. I reason that these must be the SAW filters for the 3 bands supported by each GTA02 version. It's too bad that Om-Inc chose not to use a part like M034F instead (an antenna switch version with the SAW filters built in), as that would have made it a quad-band phone: all other components are already quad-band-ready. I wonder if the only difference between the 850/1800/1900 MHz and 900/1800/1900 MHz versions of the GTA02 is in that one SAW filter part that sits between the low-band output pins of the antenna switch and the low-band input pins of the TRF6151C. (What makes me think so? See how real quad-band phones based on the same Calypso chipset handle it: Leonardo_plus_quadband_schem.pdf and the M034F.pdf in my PDF Calypso doc collection.) Makes me wonder if a GTA02 can be changed from one version to the other by carefully replacing that one part and changing the Calypso FW image accordingly... Now we need to figure out what the RF block looks like in the TSM30: that would tell us whether or not the RF chip control code is something we would need to be concerned with when porting the TSM30 source to the GTA02. What we *really* need are TSM30 schematics. Schematics used to be included in phone service manuals, but I don't know how to search for a service manual in Spanish... MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
Hello Openmoko community, I am happy to announce that the archivists at Cryptome.org have added my contribution of the TSM30 source to their website collection: http://cryptome.org/tsm30/tsm30.7z The content inside is exactly the same as what I have, they have merely repackaged it from ISO to 7z format to make it more compact. The actual TSM30 firmware source (for both processors, i.e., both the Calypso and the TSM30's unknown other processor) is fully contained in the Official.zip file inside the 7z. The rest is the Windows development environment with which one can actually recompile the beastie. Unfortunately the latter is *not* simply ARM gcc/binutils under Cygwin, it appears to be some proprietary compiler toolchain native to the Windows culture. The build process is driven by DOS *.bat files, which then invoke some Windows version of make. The makefiles for the latter (usually of the *.mak form, DOS/Win-style) are mostly autogenerated from some IDE rather than human-written, and can be quite difficult to human-parse in some places. I haven't actually tested if that Windows dev env can fully recompile the source into flashable fw images. No Windows machines here, and no time to mess with wine or virtual machines or whatever. And even if it does successfully rebuild an fw image for the TSM30, what are we going to do with it? We want something that can run on GTA02 hw, not TSM30 hw, or at least I do... Making that TSM30 code truly useful would practically require porting it from TSM30 hw to some more reasonable Calypso phone platform, such as GTA02 or one of those really basic Calypso phones that OsmocomBB folks are hacking on, and converting the build process to the standard free software way while at it. However, that is much easier said than done. Given that this TSM30 src has originally been leaked and publicly posted back in 2004 (I assume that's well before Om) and has been on various mirror sites for years before various FUD forces had reduced it to a hard-to-find status, I assume that many people, including some here, have had copies of it, had been familiar with it and had studied the code extensively (out of sheer curiosity if nothing else) for quite some time, much longer than I have. Now that the booty is once again publicly available from a well- publicized location that is resistant to non-court-order-backed FUD-style takedown requests and we can discuss it in an open manner, perhaps someone who has been looking at this code for far longer than I have can post some comments regarding its overall architecture, some knowledge that would be helpful to those who might want to attempt porting it from TSM30 to GTA02? MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Recommendations for a data-only GSM/UMTS device in USB stick ff
David Pottage da...@electric-spoon.com wrote: I think you will find that it is imposible to make data calls to an analoge modem. The reason is that GSM and it's sucessor standards are inherently digital, and are derived from ISDN telephone standards, so nothing in your phone or in the phone network will create tones that will be understood by an analogue modem. There is a gateway somewhere in the network, probably at the point where the mobile network connects to the old PSTN, that does the trick. Just like for voice calls some gateway has to convert between the 9600 bps or whatever codec is used in GSM and the classic 64 kbps of the wireline world, that gateway is apparently also capable of acting as a voiceband modem emulator, handling a data call on the GSM side and doing V.32 or whatever modem tones on the wireline side. I have personally used this feature back in 2004-2005 timeframe. I had a Mot V66 phone on T-Mobile USA, just like I do now, and I was able to connect the data cable to my phone, run minicom or similar on the laptop, and type ATDnumber, where the number was that of a land line with a USR Courier V.everything modem. It worked, connected at 9600 bps. I want to do the same thing again. Hopefully whatever gateway makes it work hasn't been dismantled, although I will likely be its sole user... Given your other requirements for off the shelf hardware, I think your simplest solution would be to buy a mobile phone with a data port, and learn how to use that port as a GSM modem. For example I used to work for Nokia, and I know that with their phones, if you put them into PC Suite mode they will respond to AT commands on their serial/usb ports and let you do dial up internet to your ISP, or any other phone number. You may find that your current phone does what you need. Yes, that's exactly what I used to do, using an identical phone. But it's a very clumsy solution, the data cable is bulky and inconvenient, and the Mot V66 makes it impossible to connect the data port and external power at the same time. I was wondering if I could take one of those cell modem USB sticks that a lot of people use nowadays for Internet on the road, and talk AT commands to it. Then I could try doing the ATDnumber from it: if it works, it would be a lot more convenient than using a phone and a data cable. The data-only cell modem devices in the USB stick form factor have the additional advantage of being completely batteryless, taking power from the laptop's USB port and nowhere else. It's a little easier for me to tolerate using a device whose GSM firmware I have no source for if that device is incapable of having any of its circuitry powered up except during those brief moments when I plug it in. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
The bubble mailer with the TSM30 CD among other things is now on its way to Cryptome; the post office has told me to expect around 2-3 days delivery. Hopefully the archivists at Cryptome will be interested in hosting this stuff, as it would cut out the delay of waiting for me to get around to setting up my new FTP server. Patryk Benderz patryk.bend...@esp.pl wrote: On the other hand, I wonder how many people here are skilled enough to get some use out of this legendary documentation. I am not :) I probably am, but it would surely help to have a community that supports the effort instead of responding with sermons on legality or with comments like the line above the part I've quoted. I don't know whether or not it would be possible to put together what I'm after (fully built-from-source and fully functional Calypso fw image for GTA02) without the Moko semi-source bits that someone-other- than-Paul-Fertser is greedily withholding, but I will give it a try, using the TSM30 and OsmocomBB bits as I've outlined previously. However, I have a few other projects ahead of it in my work queue, one of which is the setup of that FTP server so that I can share everything I've got without having to jump through massive silly hoops. In the meantime, if anyone else would like a copy of the TSM30 source without waiting for the Cryptome archivists to get to it, you can either: 1. Give me the hostname, username and password for an FTP server to which I can upload it, and I'll promptly do so; or 2. Give me a snail mail address to which I can send a CD or a set of CDs, and I'll promptly send out a CD-R copy. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
Martix martix...@gmail.com wrote: Ok, no need to hurry. Openmoko community waited for more than three years for full open access to whole GTA02 internals, we can wait another month. The CD set destined for Cryptome, including the TSM30 CD, has been written and will go out in the mail tomorrow (Friday): the post office is already closed for the evening today. Now we have access to full documentation for TI Calypso and SMedia Glamo Ahh, so I assume you have found them under /pub/GSM on the ifctfvax.Harhan.ORG FTP server. :-) Note about the Calypso docs: while they are quite a bit more extensive than the two famous PDFs linked to from Openmoko wiki pages (the Leonardo board schematics really help one understand how the various pieces of the TI chipset fit together, and Calypso is only one chip out of that chipset), they still aren't 100% complete. Here are the missing parts I'm aware of: * There exist several different versions of the Calypso DBB (digital baseband) chip. I'm not sure if the docs I have are sufficient for navigating the differences between Calypso chip versions in various existing phones (see OsmocomBB). * The analog baseband (ABB, codenamed Iota) also exists in several versions, all of which appear to be compatible with the Calypso DBB. The only one for which I've found documentation is the TWL3014, aka the original Iota. (Iota's predecessor was apparently called Nausica, mentioned in passing in some Calypso docs.) However, as one can see from the board photos in the Om wiki, the GTA02 phone features TWL3025 instead of TWL3014. I don't know what the difference between these two chips is, and I don't know if the Iota codename applies only to TWL3014 or also to TWL3025. * In addition to the DBB and the ABB, a working phone includes 3 RF chips: - an active RF chip (RF xcvr) that's part of the TI chipset; - an RF PA (power amplifier), also active, but sourced from outside of TI; - a passive RF chip (antenna switch and filters) that is also sourced from outside of TI. I have docs for the TRF6151C RF transceiver (Rita) and the M034F passive RF front-end used on the quad-band Leonardo+ reference board. But I don't know what RF components are used on the GTA02 (or GTA01 for that matter). Reasoning from the fact that these phones aren't quad-band, I figure that at least some of the RF components ought to be different. However, this photo from the Om wiki: http://wiki.openmoko.org/images/a/af/Gta02a5_pcba_cs.JPG is not legible enough to make out what the RF components are. (One can see the TWL3025 ABB chip, and one can see *most* of the DBB chip part number, but the suffix of the latter, possibly important, is obscured by the metal shield structure.) Yes, I realize that I can take my GTA02 apart and look for myself, but the device is so delicate and so expensive that I'm afraid of destroying the gem. I hear that a number of GTA02s have been gutted to turn them into GTA04s... Perhaps someone can take one of those discarded GTA02 boards, remove all RF shields and snap some better photos? I also have a hard time understanding why Openmoko Inc. didn't make their phones quad-band GSM. All components in the Calypso chipset, including the classic Rita RF transceiver, support all 4 bands, and the only extra thing one needs is a quad-band-capable passive RF front-end chip. Why couldn't they just use M034F like on the Leonardo+ board or something equivalent? We may never know... and GSM firmware is on the way. We have opportunity to study and fix it. Another important clarification is in order here. The GSM FW whose source is in my possession, the one that's about to be sent to Cryptome and which I'm equally eager to share with anyone else via either an FTP upload or a CD-R by snail mail, is for the Vitelcom TSM30 phone, *not* GTA02 or GTA01. I don't have the GTA0x version, but some other individuals right here on this mailing list do, and are *actively* refusing to share - public shame on them! (Note the emphasis on *actively* refusing. There is a world of difference between having a mental handicap that stands in the way of learning modern file sharing techniques, but actively working around that handicap by offering to share via other means, however old- fashioned or unconventional they may be (my case with the TSM30 source), versus tacitly acknowledging possession of a ware which others desperately need, yet quite deliberately refusing to share on ideological grounds: the case of Paul Fertser and the Closedmoko firmware semi-source.) Porting the TSM30 version of the code to run on GTA02, replacing the original Closedmoko firmware, would probably be the shortest path toward the holy grail of making the GTA02 a fully free and functional phone, i.e., it would probably be a shorter path than transforming OsmocomBB into an end-user-usable firmware. However, even this shortest path appears to be a very steep mountain climb:
Sharing TSM30 source
Martix martix...@gmail.com wrote: If you really have that sources, you can upload them on some public file sharing website and post link here on mailing list. I don't know of any public file sharing websites to which anyone can upload anything. Of course, you are going to lose control over this files What control? What in the world makes you think that I desire some kind of control over something that rightfully belongs in the public domain? and broke some terms of service rules, Whose? For inspiration, there are links to leaked TI Calypso documentation hosted on some leaks-friendly file sharing service: http://wiki.openmoko.org/wiki/TI_Calypso_D751992AZHH The PDF file links on that wiki page are to cryptome.org. Just checked that site out: nice work. I don't see an upload mechanism anywhere, but then uploading a 500 MiB file over my 384 kbps connection would be rather unbearable anyway. But their main page lists their snail mail address (in New York): that works for me, I'll send them a copy of my archive which currently stands at 5 CDs, one of which is that TSM30 source + development environment. But of course it will be up to them whether or not they are interested in adding my contribution to their website archive. You don't really need to host files on your personal FTP server, if you don't need to keep access logs for let's say statistics purposes, of course. My current ancient ftpd (the one that's part of 4.3BSD-Quasijarus running on VAX hardware - yes, VAX) has no capability for recording access logs at all. But it also lacks support for restarting interrupted downloads, hence hosting really large files over a flaky Internet connection is a non-starter. When I finally get around to setting up a new server on beefier hardware (I really need about 5 TiB to host my archive comfortably), I'll use a newer ftpd under Linux, one that support the REST command. The newer ftpd will probably also come with logging ability, but I'll be sure to disable it. Speaking of that: which ftpd would you recommend? I would like one in which it is easy to completely disable all logging, and have high confidence that it's really disabled, i.e., that it isn't writing any logs anywhere, period. But the bottom line is: I have *lots* of goodies (close to 1 TiB right now, the 5 TiB figure above is allowing room for growth) which I believe belong in the public domain and which I would like to share with the whole world. Hosting the stuff on an FTP server is the only way that my old-fart brain can understand. I am too handicapped to learn the more modern ways of doing it like torrents and whatnot. My only options are FTP and sending out CD/DVD copies via snail mail. I have already made my offer of a *FREE* CD-R copy of my archive, including the TSM30 stuff. Free as in no need to reimburse me for the negligible cost of media and postage. Just get the CD-R copy from me and then distribute it further in whichever way you see fit. But if you are voluntarily declining the CD-R copy I am offering at zero cost, how is that any of my fault? Just for the record, I've been offering these free CD-R copies of my archive since 2007. I haven't been counting, but the number of copies I've sent out so far is probably in the upper double digits. I have probably sent out 3 or 4 since the TSM30 CD has been added to the set. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing TSM30 source
Martix martix...@gmail.com wrote: For example Rapidshare or maybe Ubuntu One on your laptop... The Ubuntu laptop isn't mine, it belongs to my employer du jour. Because it's too much like Weendoze, I refuse to personally own a Ubuntu machine. Learning how to use Ubuntu One isn't very appealing to me. Ok, so let's upload it somewhere, if you belive in what you said. Give me the hostname, username and password for an FTP server to which I can upload it, and I'll promptly do so. Needs to be FTP: I am too old and mentally handicapped to learn more modern means. I can only do uploads with the plain old command line ftp client. That was related to file sharing services in general. They are being misused for sharing warez and other prohibited stuff for years, but theirs terms of service are just legal boilerplates. That's why I operate my own FTP and other servers instead. I and my servers and services are in a TOS-free zone. I think, cryptome.org should work well. As I've already promised, I'm going to send them a copy of my CD-R set. I'll do it as soon as I get back to my facility, which will be some time later this week: right now I'm over 100 km away, working for a paying client so I can feed my family. But I still don't understand why you yourself aren't willing to request a CD-R copy from me. Why don't you just get the CD-R copy from me (send me a snail mail addr off-list), and when it arrives in a few days, upload it to whatever more-modern-than-FTP file sharing service you like? Waiting for some volunteer archivist at Cryptome to look at my CDs, figure out what's there and add it to their site will probably take longer, and that assumes that they are interested in hosting such subject matter in the first place. 500 MiB transfer over 384 kbps link is only ~178 minutes, so almost 3 hours. That's much faster than snail mail...but you have right of choise. I haven't found an upload mechanism on cryptome.org. A more direct pointer maybe? But see above about me needing FTP. I'm curious, what's on the other CDs? CDs 1 through 3 are a snapshot of what's on my FTP server ifctfvax.Harhan.ORG: you are welcome to look there for yourself and see what's there. CD 4 is some oversize stuff that would make my ancient VAX FTP server croak: DEC VAX standards 032 and 057 (scanned from dead-tree media, hence huge), the full Adobe Type Library, some other stuff I don't remember off the top of my head. CD 5 is the most recent addition: TSM30 source code and Windows development environment. I badly need to set up a new FTP server with bigger disks and a newer ftpd that supports REST, so that I can put *everything* I have online. But I can't stomach PC hardware, at least not in my machine room: I'm OK with x86 laptops and *maybe* desktop workstations, but an x86 server is a no-no for me. Fortunately I've got some UltraSPARCs (donated by my previous employer du jour), they satisfy my non-x86 requirement and they can run Bobware, a port of Slackware to SPARC. But I still need to figure out what I want to use for the main storage subsystem. Thinking of a standalone NAS box, or maybe a storage array attached via FibreChannel. The UltraSPARCs have PCI slots, and I have a FibreChannel HBA, also donated by the same employer du jour. But I don't know how good the Linux support is. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Recommendations for a data-only GSM/UMTS device in USB stick ff
Hello Om community, Given that the GTA04 contains an off-the-shelf UMTS module and, if my understanding is correct, truly off-the-shelf GSM/GPRS/UMTS modems in the consumer USB stick form factor have been used during the BeagleBoard prototyping phase for the GTA04, I've figured that someone here might have some experience with / knowledge of these USB sticks, hence me asking here... I'm looking for a GSM/GPRS/EDGE/UMTS cell modem device in the USB stick form factor which I would plug into my x86 laptop, running Linux, currently Ubuntu, hoping to switch to Slackware or Linux From Scratch some day. My requirements / wish list items are: * USB stick form factor, encased as it would be for a normal consumer, internal antenna and all. * No battery, drawing power from the laptop when in use, no possibility of any internal components being powered up when the stick is not inserted into a laptop's USB port. * I want to buy this thing from someone who just sells equipment, not service. I need this thing to take SIM cards, and I know I can get a SIM card from my local GSM/UMTS service provider without getting their equipment. * I need something that is sufficiently well documented in terms of its external interface (AT commands?) so that I can drive it from, say, minicom. * I need this device to be capable of placing old-fashioned data calls, not just Internet access. By old-fashioned data calls I mean the arrangement where one dials a number from the mobile device with ATDnumber (no semicolon at the end, making it a data rather than voice call), and the number being dialed is a POTS land line with a plain old analog modem answering the call. I want to be able to connect to my personal data center from remote locations bypassing the Internet. * I need this device to support GSM/GPRS/EDGE fallback, not just UMTS. I would like to have UMTS capability, but only in addition to plain GSM/GPRS, not instead of. I would also very much like to be able to switch between GSM and UMTS manually with AT commands, e.g., to force GSM/GPRS mode even when UMTS is available. * I need this thing to support the 1900 MHz band when operating in the GSM/GPRS/EDGE fallback mode, so I can use it with T-Mobile USA. So, would anyone here be able to recommend such a USB stick device for me? Maybe even with pointers to where I can buy one? My original plan was to use my GTA02 for this purpose, but I'm not currently able to do anything with that device because of the community's discriminatory handling of the Calypso FW semi-source code. Let me clarify: while of course the ideal situation would be for everyone in the world to have free access to the GSM fw source code, I can grudgingly accept using consumer off-the-shelf hardware for which *no one* in the supposed-open-source community has any firmware source. But I philosophically object to using a device for which Paul Fertser has a copy of the AT interpreter source code while I'm denied a copy of the same. Not being able to use the GTA02, I'm still using my old Motorola V66 phone: it's a *very* dumb phone (well below what one would call a feature phone) and it's full of misfeatures which I don't like (a UI design that suits me very poorly, bad pre-USB connector for the charger and data port interfaces, no ability to connect the data port and external power at the same time, etc), but what makes it morally acceptable is that I'm not aware of any supposed-open-source developer(s) hoarding a copy of its firmware source, selectively denying it to new entrants into the field. With the Mot V66 poorly suited as a device for making data calls from a Linux/x86 laptop and the GTA02 unusable altogether for moral / philosophical reasons, I'm now looking into the possibility of getting a separate data-only device in the USB stick form factor and keeping it separate from my voice phone, as in a separate SIM card from my service provider. (I already have several lines on my account for my large pseudofamily, no difficulty with adding one more.) I'm not aware of any cellular data USB sticks with hackable GSM/UMTS/ whatever firmware, but I can grudgingly live with that because it isn't the same as having a clique of supposed open source developers exclusively hoarding the FW source. From what I understand, the GTA04 developers were able to get docs for the external interface (AT commands or whatever) to their UMTS modem without having to sign their lives away in NDAs, right? Oh, and before anyone accuses me of being a hypocrite and hoarding or not-sharing the TSM30 FW source which I have finally located, let me reiterate I *do* freely and readily share this source with everyone in the world, just not via the Internet. Not via the Internet because my current FTP server doesn't have enough disk space and my external Internet connection is too slow. Instead I am offering a CD-R copy by snail mail to anyone in the world who wants one. Just give
Re: [Gta04-owner] Clarification
Antonio Murdaca amurdoc...@gmail.com wrote: So, it's a dream to have a full GTA04 with case,battery,screen etc etc in a real near future? :( I mean, i have to buy a GTA01/02 and do the stuff to replace the mothherboard to have a GTA04 When you gut your GTA02s to stuff GTA04 boards into them, PLEASE don't throw the old GTA02 boards away, please save them as spares for people like me! MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo chip docs found
Hello Openmoko community, I've got some Glamo chip docs on my FTP site which I thought someone here might find useful, given that this chip is used on the GTA02: ftp://ifctfvax.Harhan.ORG/pub/GSM/GTA02/Glamo/ Enjoy! MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
U-Boot source versions
Sorry to bother y'all again with another stupid question... I have finally received my GTA02 hardware unit, and I'm starting to bring up my software stack. Starting with the bootloader. I want to use U-Boot, not Qi. And I have two questions which I hope someone might be able to help me with: 1. Which version/branch of U-Boot should I use? I've tried looking at what's available on git.openmoko.org, found the u-boot.git tree, but there are several different branches in it, all appearing about equally recent, and all feature commit messages that look relevant to the GTA02. Which is the good one to use? 2. How can I find the U-Boot source that *exactly* corresponds to what is already in the NOR flash from the factory? It identifies itself as U-Boot 1.3.2-moko12 (May 9 2008 - 10:28:48). I haven't been able to find a tag named moko12 in git, but maybe it's just my poor git skills. U-Boot is GPL'ed... Doesn't it require supplying the source that corresponds *exactly* to the binaries you ship? Again, sorry to bother you all, but if someone can point me in the right direction, it would help me a lot. TIA, MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: U-Boot source versions
Gennady.Kupava g...@bsdmn.com wrote: I tried to fix few annoying bugs and using own u-boot version, you can find description here: http://wiki.openmoko.org/wiki/U-boot-gena2x I think I have mis-expressed myself in my original post... I am not looking for a prebuilt binary, I want a source tree that I would then compile myself. That U-boot-gena2x wiki page contains a link to a binary but no source - isn't that in violation of the GPL? I would also prefer to stick to one of the branches in the u-boot.git tree on git.openmoko.org, but my problem is that there are several to choose from: I see good-looking branches named stable, zecke, andy, mokopatches and willie. What are the relative merits of these branches? *That* is the question I am looking for help with. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
