First small steps toward free GSM firmware

[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