--- a/doc/Compal-unlock	Sat Dec 12 03:48:19 2015 +0000
+++ b/doc/Compal-unlock	Sat Dec 12 08:24:08 2015 +0000
@@ -40,14 +40,15 @@
 this feature enabled unconditionally, but some of the newer versions have a
 malfeature whereby the serial boot interrupt and code download possibility may
 be disabled.  Some C1xx phones out in the wild, particularly all North American
-C139s with TracFone branding, have such maliciously-locked firmware in them.
+C139s with TracFone branding and some of the Cingular-branded ones as well,
+have such maliciously-locked firmware in them.
 
-Fortunately though, these maliciously-locked firmwares (or at least the most
-common TFC139 one) have been found to have another hole through which we can
-break in, as described in the TFC139-breakin article.  We can exploit this hole
-in the TFC139 firmware to gain code execution access to the Calypso, and then
-use the latter to reprogram the flash, replacing the ultra-malicious firmware
-with some other version that, although still proprietary, is a little less evil.
+Fortunately though, these maliciously-locked firmwares (or at least all versions
+we've encountered so far) have been found to have another hole through which we
+can break in, as described in the TFC139-breakin article.  We can exploit this
+hole in the firmware to gain code execution access to the Calypso, and then use
+the latter to reprogram the flash, replacing the ultra-malicious firmware with
+some other version that, although still proprietary, is a little less evil.
 
 Making first contact
 ====================
@@ -111,20 +112,26 @@
    albeit at 57600 baud instead of TI's default of 115200.
 
 4. Connect the headset jack serial cable if it wasn't already connected, and
-   run this FreeCalypso hack-utility:
+   run this FreeCalypso utility:
 
    tfc139 /dev/ttyXXX
 
+(The name tfc139 is historical; the current version is expected to work with
+ all Mot C1xx firmwares.)
+
 Compal's TI-based firmware implements some of TI's Test Mode commands, and one
-of these commands is a raw memory write.  Our tfc139 hack-utility will try to
-break into the phone (gain code execution access) by using this Test Mode
-command to write a little payload into a particular RAM location (beginning of
-IRAM), and then doing more memory writes by the same method, seeking to smash
-the stack and cause control to be transferred to the sent payload by
-overwriting a function return address on the stack.
+of these commands is a raw memory write.  It also implements some of TI's GPF
+"system primitive" commands, including the MEMCHECK command that causes the
+firmware to report some info on all running GPF tasks, including the location
+of each task's stack.  Our tfc139 utility will try to break into the phone
+(gain code execution access) by querying the target fw for the location of the
+L1A task's stack, and then using Test Mode memory write commands to write a
+piece of shellcode into an unused RAM location and to make this code execute by
+overwriting a function return address on the stack of the L1A task that
+processes these Test Mode commands.
 
-If the stack smashing hack succeeds, the code injected by tfc139 will send a
-message out the serial port indicating this success, and then re-enable the
+If the stack smashing hack succeeds, the shellcode injected by tfc139 will send
+a message out the serial port indicating this success, and then re-enable the
 Calypso boot ROM and jump to it.  Once the boot ROM code gains control, it will
 wait forever for a serial code download following its standard protocol.  If
 tfc139 gets the success indication from the target, it will announce this
@@ -137,28 +144,26 @@
 be in full control of the phone via fc-loadtool.
 
 There is one additional quirk worth mentioning.  It appears that Mot/Compal's
-main fw (at least TF's version 8.8.17, which is the version we break into with
-tfc139; other versions are anyone's guess) keeps resetting the RTC alarm
-registers in the Calypso DBB as it runs, always keeping the alarm time in the
-near future relative to the current time.  When one breaks into this firmware
-with tfc139 and takes over the control of the device with fc-loadtool, this
-alarm time will almost certainly be reached, and the RTC alarm will go off.
-This alarm has no effect on loadtool operation (i.e., it cannot reset the CPU
-or otherwise wrestle control away from loadtool, so it doesn't add any bricking
-risk), but it has one quite surprising effect upon exit, i.e., when you are
-done with your loadtool session and give it the exit command.
+main fw keeps resetting the RTC alarm registers in the Calypso DBB as it runs,
+always keeping the alarm time in the near future relative to the current time.
+When one breaks into this firmware with tfc139 and takes over the control of
+the device with fc-loadtool, this alarm time will almost certainly be reached,
+and the RTC alarm will go off.  This alarm has no effect on loadtool operation
+(i.e., it cannot reset the CPU or otherwise wrestle control away from loadtool,
+so it doesn't add any bricking risk), but it has one quite surprising effect
+upon exit, i.e., when you are done with your loadtool session and give it the
+exit command.
 
 Loadtool's configured default exit action for this target is to send a power-off
 command to the Iota ABB, leaving the device cleanly powered off.  However, if
 the RTC alarm has gone off previously during the session, the ABB will instantly
 power the phone back on, and put it through a new boot cycle.  The firmware
-(again, the only version this stuff can be tested on is the one that works with
-tfc139) handles this special form of boot rather oddly: it proceeds to the same
-end state it would have reached via a normal power button hold-down boot
-(powered on with the "Insert SIM" message on the LCD), but it reaches this state
-almost instantly, without going through the power-on LCD logo and buzz phase.
-Odd, but harmless.  This explanation has been included to save other hackers
-the hours of bewildered head-scratching I spent chasing this quirk down.
+handles this special form of boot rather oddly: it proceeds to the same end
+state it would have reached via a normal power button hold-down boot (powered
+on with the "Insert SIM" message on the LCD), but it reaches this state almost
+instantly, without going through the power-on LCD logo and buzz phase.  Odd,
+but harmless.  This explanation has been included to save other hackers the
+hours of bewildered head-scratching I spent chasing this quirk down.
 
 Dumping and reloading flash
 ===========================
@@ -244,7 +249,7 @@
 
 Unzip it, and you'll get c139-unlocked-fw.bin - that is the image you'll need
 to flash into your phone.  Get in with fc-loadtool (using tfc139 if necessary
-for locked-down Tracfones) and make a backup of the original flash content.
+for bootloader-locked phones) and make a backup of the original flash content.
 Then reflash the firmware as follows:
 
 flash erase-program-boot c139-unlocked-fw.bin 2000