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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community