# HG changeset patch # User Mychaela Falconia # Date 1545289794 0 # Node ID 5de1f72ce941da00dd56338737f30a09add80e84 # Parent dc0e9c91d54a8ef76173c49e57f7b236f9fabfbc TCS211-fw-arch: flash chip type autodetection reinstated diff -r dc0e9c91d54a -r 5de1f72ce941 TCS211-fw-arch --- 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 --------------