First small steps toward free GSM firmware
norayr at arnet.am
Sat Nov 9 11:41:14 CET 2013
Okay, so first thing I did is I have compiled loadtools, as planned
right on freerunner.
opkg install gcc
opkg install gcc-symlinks
opkg install libc6-dev
opkg install binutils
opkg install make
and synced time before build.
then I have edited makefile, as suggested in readme, set CFLAGS to
CFLAGS= -O2 -march=armv4t -mtune=arm920t -DGTA0x_AP_BUILD
After short build I have three binaries installed
fc-iram fc-loadtool fc-xram
I believe they will run.
Then, I have tried to compile the firmware with supplied wine environment.
Downloaded nowhine.c, built and installed it.
Unpacked environment in drive_c directory of .wine in my home.
Inspite of using nowhine, I saw a lot of fontconfig warnings .
Build fails, failed a couple of times, both by using nowhine or wine
Because one windows utility, probably linker, fails
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 am sure, it would be much easier to debug and understand the problem
in case of using native Unix build environment. Or error would not
present at all.
Thanks for any further hints.
10/30/13 12:42 -ում, Michael Spacefalcon-ը գրել է:
> "dmatthews.org" <mail at 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:
> Or was your reference to "necessary hardware and software" regarding
> the flashing process, rather than compiling the gsm-fw.m0 image
> 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
> 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".)
> 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
> * 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 breath for any alpha
> testers to come forward until I produce and publish the SD card image
> I have proposed earlier.
> Openmoko community mailing list
> community at lists.openmoko.org
More information about the community