First small steps toward free GSM firmware

Sat Nov 9 20:55:55 CET 2013

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.

11/09/13 11:42 -ում, Norayr Chilingarian-ը գրել է:
> Hehe, flashed your image!
>
> http://norayr.arnet.am/tmp/2013-11-09/Screenshot-2_patched.png
>
> Thanks a lot.
> Let's see how it works. 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 also had problems with iliwi, so I usually connect to wifi by
> hands, from terminal.
> That way it works. So may be I am doing something wrong. But I would
> like to learn to establish gprs connection from console.
>
> Anyway, this was off topic.
>
> The firmware flashed, will continue testing.
>
> Thank you.
>
> P. S. one day I'll play with IMEI too.
>
>
> 11/09/13 05:18 -ում, Michael Spacefalcon-ը գրել է:
>> Norayr Chilingarian <norayr at 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 0x380000, then 7
>> sectors of 64 KiB each (0x70000 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 at 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 at darkstar:~$ cat /etc/slackware-version
>> Slackware 13.37.0
>> hec at 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 Hg source
>> repository I'm using; you can find the link in this old post of mine:
>>
>> http://lists.openmoko.org/pipermail/community/2013-August/068850.html
>>
>> See the warning at the end of that post, though.
>>
>>> Or error would not present at all.
>> The specific error you are experiencing (some Windows binary or wine
>> snafu) most certainly will not occur when building with gcc!
>>
>>> Thanks for any further hints.
>> My earlier post to which you are replying contained a link to a
>> prebuilt fw binary, i.e., one I've built on my machine.  Of course the
>> whole point of having sources (even a partial semi-src like we have
>> currently) is being able to modify and recompile at will, so being
>> limited to running my binary is not much progress compared to just
>> running the original fw your FR came with...  But at least if you
>> flash my binary, you'll have the "viewable source" benefit, i.e., you
>> know exactly what source it was built from and you can study that
>> source.  My binary package even includes the linker-generated map file,
>> so you know exactly where every function and variable got placed in
>> that specific binary image - very handy for JTAG debugging etc.
>>
>> As far as resolving your wine problem running the linker, maybe try
>> talking to some wine gurus.  Or you could start by putting together a
>> system setup more like mine, with everything 32-bit and no x86_64 in
>> the picture.  You could also try using a real Winblows machine
>> somewhere, like at your day job or school etc.  Thankfully I never had
>> to go down that route (except for running the installers), so I don't
>> have any experiences to share on that front.
>>
>> VLR,
>> SF
>>
>> _______________________________________________
>> Openmoko community mailing list
>> community at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community