First small steps toward free GSM firmware

Michael Spacefalcon msokolov at ivan.Harhan.ORG
Sat Nov 9 14:18:32 CET 2013


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



More information about the community mailing list