# HG changeset patch # User Mychaela Falconia # Date 1686510707 0 # Node ID b71216a5f3c393962fb5de28fe464c270fe45279 # Parent 2df287f4722c1237eb303d5f431ddd5da2432edf doc/C1xx-flashing: proofreading fixes diff -r 2df287f4722c -r b71216a5f3c3 doc/C1xx-flashing --- 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.