c139

[Mychaela Falconia]

Hello FreeCalypso community,

Given the recent confusion encountered by our dear David and which I
now see can be reasonably encountered by others, I feel that I need to
provide a better explanation of the flash memory layout on Mot C139
phones.

The flash memory chip in Mot C139 phones is a functional clone of
Intel 28F320C3T, and its total capacity is exactly 4194304 bytes - if
you make a full flash dump with fc-loadtool and look at the resulting
dump file, you will see that it is exactly that many bytes long.  But
the decimal number system based on human finger count is very
inconvenient for measuring computer memories whose design is based on
powers of 2 instead, hence instead of saying 4194304 in decimal, that
exact same number is more meaningfully expressed in the hexadecimal
number system as 0x400000.  There is also the relatively recently
invented MiB notation, by which the capacity of the flash chip is
question is said to be 4 MiB.

Now let us closely examine the sequence of loadtool commands which I
have been instructing people to use on C139 phones for many years now,
the same commands which our dear David just used:

> flash erase-program-boot my_c139.bin 10000
> flash erase 10000 360000
> flash program-bin 10000 my_c139.bin 10000 360000

Look at these commands closely - what are they comprised of?  There
are command keywords, there is the name of the image file to restore,
and there are several "magic" numbers.  It appears that I may be a
little at fault here if I haven't explained the meaning of these
numbers sufficiently well - so let me make another attempt at
explaining them.

These numbers are NOT magic incantations invoking any kind of gods or
demons - instead they are hexadecimal offsets.  Many Unix tools use
the convention whereby a numeric argument is interpreted as hexadecimal
if preceded with 0x, as octal if preceded with 0 or as decimal
otherwise, but when I wrote fc-loadtool back in 2013, I cheated a
little in order to save typing: as explained in the help file, many
numeric arguments including those appearing in flash commands are
always interpreted as hexadecimal, whether they are preceded with 0x
or not.  I made it this way because hexadecimal number system is the
only one that makes sense in this context, and I wanted to save some
typing because I type these commands a lot, both in direct usage and
when composing various scripts.

Let us look at the first command:

> flash erase-program-boot my_c139.bin 10000

The last argument could have been written equivalently as 0x10000,
perhaps more clearly.  This command operates on the boot sector only,
not on any other sectors of the flash chip; because the boot sector is
0x10000 bytes long (64 KiB), this command can only operate on this
many bytes and no more.  The last argument of 0x10000 or just 10000 is
required because otherwise it would give you an error, saying that the
file is much longer than the boot sector; the 0x10000 argument tells
this command to only take that many bytes from the beginning of the
dump file.  The end result of this command is that the first 0x10000
bytes of the flash (1/64th of the total chip size) will be rewritten,
while the rest of the flash remains untouched.

Next two commands:

> flash erase 10000 360000
> flash program-bin 10000 my_c139.bin 10000 360000

The same deal with 0x being omitted for brevity applies here.  The
first command tells the tool to erase 0x360000 bytes of the flash
starting at offset 0x10000, and the second command tells the tool to
write the exact same number of bytes (0x360000) at the same offset
(0x10000), taking the bits from file offset 0x10000.

The end result of all 3 commands is that the portion of flash from 0
up to offset 0x370000 (0x10000 + 0x360000) will be rewritten with bits
from the file - BUT!  All of these operations end at flash offset
0x370000, and do not go any further!  As a result of this carefully
crafted end address, all flash content from 0x370000 onward remains
completely untouched.  Given that the total flash capacity on these
phones is 0x400000 bytes, it follows by basic hexadecimal arithmetics
that the last 0x90000 bytes of the flash remain untouched by these
reflashing operations.

Compal's vital data including the IMEI, RF calibration values, date of
manufacture (DOM) displayed in #02# output and other non-understood
bits reside in the last two small sectors of the flash, starting at
offset 0x3FC000, going from that offset to the end of the flash.  The
intermediate area between 0x370000 (where our flashing procedure
stops) and 0x3FC000 (where truly vital bits begin) holds transient
data which the firmware can easily recreate on its own (including
Compal's FFS) and which can be blown away without worry.  The exact
same arrangement holds on both Mot C139 and SE J100, both made by
Compal - thank you, Harald, for sending me a specimen of the latter
model for examination last year!

I ask everyone to please understand that all of my experience with Mot
C139 phones is based first and foremost on North American units, with
the EU variety being a little more foreign to me.  The vast majority
of North American C139 phones that are available on ebay etc come with
carrier branding and SIM locks, thus I had to develop the procedure
for replacing one official Motorola fw version with a different one
(thereby removing the carrier branding and the SIM lock) long before
we made our first attempt at running FreeCalypso fw on these phones.
As a matter of timeline, our first attempt at running FC fw on C139
was in the fall of 2015, whereas fc-loadtool support for these phones
and the procedure for replacing one Mot official fw version with a
different one were developed back in the summer of 2014.  (The seasons
are Northern hemisphere.)  Back to the flashing commands that have
been used successfully by David and hopefully others:

> flash erase-program-boot my_c139.bin 10000
> flash erase 10000 360000
> flash program-bin 10000 my_c139.bin 10000 360000

Ever since I first started instructing people how to flash their C139
phones with fc-loadtool, I've been giving them some variation of these
commands (with or without 0x) specifically because I've been intending
this particular use case of reflashing phones to a different Mot fw
versions.  The present situation may be the first time our dear David
experienced a SIM-locked C139 phone, but on North American C139 units
this SIM lock situation is the norm, hence the procedure I've been
trying to popularize is an absolute requirement here.

Now for the sake of completeness, truthfulness and full disclosure,
consider this alternate sequence of commands:

flash erase-program-boot my_c139.bin 10000
flash erase 10000 3F0000
flash program-bin 10000 my_c139.bin 10000 3F0000

*These* alternate commands will restore a C139 flash backup image in
its entirety, every single bit, including the vital bits sector.  When
someone is playing with these phones, I always instruct them to first
make a complete flash dump and save it securely.  Very recently this
flash dump acquired a second purpose for c1xx-calextr, but even before
this addition it was still very important as a backup.  If through
whatever calamity, be it wrong loadtool commands or a bug in our
FreeCalypso fw or whatever, or perhaps Motorola's fw reacting badly to
a transplant, if the vital bits end up being corrupt by whatever cause,
the "full restore" sequence of commands I just listed will restore
*everything*.  BUT! - this full restore operation can only be done
restoring to the *same* phone, not a different one!  Vital data bits
are not transplantable from one phone to another, but the main firmware
is successfully transplantable in every case I have seen so far - and
if you are transplanting the main fw portion of the flash from one
phone to another, then you need to use the firmware-only flashing
commands, rather than the full restore version.

The only difference between fw-only and full-restore flashing commands
is the last number: 360000 for fw-only or 3F0000 for full restore.
Please be alert and pay attention!

I also need to note one difference between Openmoko devices and Mot
C139 units.  If someone suffers the misfortune of blowing away factory
calibration values on their Openmoko Neo FreeRunner or even Neo 1973
and does not have a backup, they can send their device to my Falconia
Partners LLC company address in California, and I will send it back to
you with a fresh calibration performed on my CMU200 station - my
calibration procedure is no worse than what OM's factory did (in fact
my version is slightly more accurate), and will work not only with
current FreeCalypso fw, but also with legacy mokoN fw versions if you
need to run one of them for some strange reason.  But I won't be able
to provide an equivalent service for Mot C139 phones: while I could
certainly perform a new calibration on these phones (they do have an
easily accessible RF test port of the same kind as OM; I would need to
craft an appropriate calibration profile first, but it would certainly
be doable), I would not be able to package the results of my own
calibration into a format which Mot/Compal's fw would accept, given
that we have reverse-engineered their mystery data format only to a
very limited extent.  Therefore, if I were to do a new calibration on
a C139 phone, it would only be usable with FreeCalypso fw and not with
any Mot/Compal's official ones - and we are still far away from having
any practically usable FreeCalypso handset fw.

Hasta la Victoria, Siempre,
Mychaela aka The Mother