--- a/TCS211-fw-arch	Fri Oct 26 06:41:47 2018 +0000
+++ b/TCS211-fw-arch	Thu Dec 20 07:09:54 2018 +0000
@@ -1204,11 +1204,13 @@
 and geometry details and the location of the FFS sectors for each supported
 flash chip type.  However, this approach has its limitations:
 
-* The sequence of write operations which TI's autodetection code issues in
-  order to put the flash chip into its Read ID mode worked for older flash
-  chips that were used by TI and Openmoko, but does not work for the newer
+* The sequence of write operations which TI's original autodetection code
+  issues in order to put the flash chip into its Read ID mode worked for older
+  flash chips that were used by TI and Openmoko, but does not work for the newer
   Spansion S71PL129NC0HFW4B flash chip which we (FreeCalypso) have copied from
-  the Pirelli DP-L10 phone.
+  the Pirelli DP-L10 phone.  We have now fixed it, but until recently we had to
+  disable flash autodetection and hard-code the flash chip type on Pirelli and
+  FCDEV3B targets.
 
 * While the physical flash chip used on a given phone or modem board is a
   physical property that can be autodetected, the choice of which flash sectors
@@ -1225,24 +1227,57 @@
   have to be hard-coded with conditional compilation per board type and cannot
   be autodetected.
 
-To support our new repertoire of possible hardware targets, the logic has been
-changed as follows in our Magnetite and Selenite firmwares:
+To support our new repertoire of possible hardware targets, we have made the
+following changes in our Magnetite and Selenite firmwares:
+
+* We have a new version of the ffsdrv_device_id_read() autodetection function
+  that issues AMD's Read ID command sequence in a way that works with all flash
+  chips which we've encountered so far in real life, including Openmoko's
+  Samsung K5A3281 and our new (originally Pirelli's) Spansion flash chip.  We
+  have also incorporated the logic from Pirelli's firmware that distinguishes
+  between S71PL-J and S71PL-N chips: they have different sector sizes which FFS
+  needs to know about, but they have the same ID codes and can only be
+  distinguished through CFI.
 
-* When the target is our own FC hardware family (CONFIG_TARGET_FCFAM) or the
-  Pirelli DP-L10 phone (CONFIG_TARGET_PIRELLI), flash chip type autodetection
-  is disabled and a strictly fixed hard-coded FFS configuration is used;
+* The autodetected flash ID code is looked up in a compiled-in table like
+  before, but we now have 4 different versions of this table selected by
+  conditional compilation based on the target for which the firmware is being
+  built:
+
+  - For our own FC hardware family (CONFIG_TARGET_FCFAM) we have our brand-new
+    table of possible flash configurations which we keep free of any legacy
+    gunk;
+
+  - For Mot C1xx targets (CONFIG_TARGET_COMPAL) we have a dedicated table
+    giving our aftermarket FFS configurations for Intel flash chip types found
+    in these phones;
 
-* When the target is one of Mot C1xx subfamilies, the autodetection logic is
-  kept (several different flash chip types are found in these phones), but a
-  different table is used, giving our aftermarket FFS configurations for these
-  Mot C1xx flash chip types;
+  - For the Pirelli DP-L10 target (CONFIG_TARGET_PIRELLI) we likewise have
+    another dedicated table giving our aftermarket FFS config for Pirelli's
+    S71PL-J or S71PL-N flash;
+
+  - The #else clause is the original table from TI/Openmoko, used on
+    dsample and gtamodem targets.
+
+The advantages of this new approach over our previous approach of disabling
+flash autodetection and using a strictly fixed hard-coded FFS config for
+FreeCalypso and Pirelli targets are:
 
-* When the target is gtamodem (Openmoko GTA01/02 modem) or dsample (TI's
-  D-Sample board), we use the original autodetection logic and device table
-  which we got from TI/Openmoko.
+* The high-capacity flash chip we are currently using (S71PL129NC0HFW4B) is
+  great for development boards or perhaps for a high-end Pirelli-like feature
+  phone, but it would be way overkill for an embedded modem product - for the
+  latter device class a smaller flash chip like Openmoko's K5A32xx would be
+  more appropriate.  The new autodetection approach makes it possible to build
+  a single fw image that can run on both large-flash and small-flash boards.
 
-We have also changed the AMD multibank flash driver to issue write commands in
-a way that is compatible with our new S71PL129NC0HFW4B chip.
+* I've only seen Pirelli phones with S71PL-N flash so far, but their original
+  fw supports both S71PL-J and S71PL-N with autodetection.  We can now do
+  likewise in our FreeCalypso fw.
+
+Finally, independent of flash chip type autodetection vs. hard-coding issues,
+we have had to change the AMD multibank flash driver to issue write commands in
+a way that is compatible with our new S71PL129NC0HFW4B chip.  It still works
+just as well with Openmoko's K5A32xx.
 
 FFS life cycle
 --------------