--- a/doc/C1xx-flashing	Sun Jun 11 09:55:27 2023 +0000
+++ b/doc/C1xx-flashing	Sun Jun 11 19:11:47 2023 +0000
@@ -211,7 +211,7 @@
 In this step you are basically telling fc-loadtool to execute the command script
 that was prepared in step 4.  This script performs all necessary flash erasure
 and programming operations - having a previously prepared script do everything
-in one go greatly reduced the chances of leaving your phone in an invalid
+in one go greatly reduces the chances of leaving your phone in an invalid
 partially flashed state due to operator distraction or other human errors.
 Once the flashing script finishes executing, exit loadtool and your phone will
 power off.  Next time this reflashed phone executes hardware switch-on (power
@@ -228,8 +228,8 @@
 the firmware portion, but the whole thing) from one phone to another!  For
 maximal restorative power, the loadtool command script generated by
 c1xx-analyze-image (named restore-flash) restores the entire flash image, every
-bit without exceptions - but this quality also makes the {flashdump.bin +
-restore-flash script} package non-transplantable, i.e., it should NOT be
+bit without exceptions - but this property also makes the {flashdump.bin +
+restore-flash script} combo non-transplantable, i.e., it should NOT be
 programmed into a different phone.  Each individual phone has its own unique RF
 calibration values and other factory tunings, stored in small sectors at the end
 of the flash (after the firmware), and these bits should never be mindlessly
@@ -255,14 +255,16 @@
 Because the boot sector still needs to be rewritten (the command that does so
 is part of the generated fc-flash-script and restore-flash scripts), a very
 small bricking vulnerability window still exists - but this window is on the
-order of a few tens of milliseconds.  Furthermore, in order for the phone to
-get bricked, the unfortunate event happening in that short vulnerability window
-would have to be someone physically yanking the battery out of the phone at
-that exact moment, or the battery running out or falling out, again at that
-exact moment in a time window that spans maybe 100 ms at the most.  There is
-absolutely NO bricking vulnerability window in terms of the serial cable
-disconnecting or the host machine crashing - those events can happen at any
-moment in time and do NOT create bricking danger.
+order of some milliseconds to a few seconds at most.  (The bricking-vulnerable
+operation completes in an imperceptible time in my actual experience, but Intel
+flash datasheet says it can take up to 5 s.)  Furthermore, in order for the
+phone to get bricked, the unfortunate event happening in that short
+vulnerability window would have to be someone physically yanking the battery
+out of the phone, or the battery running down or falling out - simply
+disconnecting the serial cable or killing fc-loadtool process on the driving
+host during this window will NOT cause bricking, as the entire sequence of
+operations that fall into the bricking vulnerability window happens entirely
+inside loadagent without needing further host communication once started.
 
 However, if the flashing process as a whole (on the order of a few minutes if
 you are using "slow" 115200 baud rate) gets interrupted for whatever reason,
@@ -274,9 +276,9 @@
 
 * Return the phone to its powered-off state by removing and reinserting the
   battery.  Very important: do NOT press the power button or plug in charging
-  power after reinserting battery until instructed to do so below; if you mess
-  up, remove the battery again, reinsert it, and be careful this time to NOT
-  press the power button prematurely.
+  power after reinserting the battery until instructed to do so below; if you
+  mess up, remove the battery again, reinsert it, and be careful this time to
+  NOT press the power button prematurely.
 
 * With the phone off and the battery freshly removed and reinserted, connect
   the headset jack serial cable and run fc-loadtool with the right arguments.