# HG changeset patch # User Mychaela Falconia # Date 1583708191 0 # Node ID f2a023c206537f5c415b1ad66f3c4d351ca8e870 # Parent 3a41d69e8104fba9146b00851bb9460d396f54ca doc/Loadtools-performance: removed the section about SREC programming With our current fc-loadtool there is no difference in performance between different flash programming commands, and the explanation of binary vs. S-record issues has been moved to the new Binary-file-formats and Flash-programming articles. diff -r 3a41d69e8104 -r f2a023c20653 doc/Loadtools-performance --- a/doc/Loadtools-performance Sun Mar 08 22:53:30 2020 +0000 +++ b/doc/Loadtools-performance Sun Mar 08 22:56:31 2020 +0000 @@ -85,42 +85,6 @@ flash program operation times between K5A3281CTM and S71PL129N flash chips seems to be the most likely explanation. -Programming flash using program-m0 or program-srec -================================================== - -Prior to fc-host-tools-r12 flash programming via flash program-m0 or -program-srec commands was much slower than flash program-bin. The reason for -this performance discrepancy was that the original implementation of these -commands from 2013 was very straightforward: they operated in one pass, reading -the S-record image file, and as each individual S-record was read, it was turned -into an AMFW or INFW command to loadagent. In the case of *.m0 files generated -by TI's hex470 post-linker, each S-record carries 30 bytes of payload, thus the -flashing operation proceeded in 30-byte units, incurring the overhead of a -command-response exchange for every 30 bytes. In contrast, our current flash -program-bin implementation sends 256 bytes of payload per each AMFW or INFW -command; this larger unit size decreases the overhead of command-response -exchanges between fc-loadtool and loadagent. - -Why do we need flash program-m0 and program-srec commands at all, why not -simply convert all SREC images to straight binary first and then program with -flash program-bin? The reason is that S-record images can contain multiple -discontiguous program regions with gaps in between. All of our current -FreeCalypso firmwares built with TI's TMS470 toolchain contain a few small gaps -in the fwimage.m0 file, filled with 0xFF bytes when converted to straight binary -with mokosrec2bin, but TI's own firmwares built for 8 MiB flash configurations -often had much bigger gaps in them. - -As of fc-host-tools-r12 we finally have a more efficient solution for flashing -discontiguous SREC images: our new implementation of flash program-m0 and -program-srec commands begins with a preliminary pass (pure host operation, no -target interaction) of reading the S-record image file; the payload bits are -written into a temporary binary file (automatically deleted afterward), while -the address and length of each discontiguous region are remembered internally. -Then the actual flash programming operation proceeds just like program-bin, -reading from the internal binary file and sending 256 bytes of payload at a time -to loadagent, but using the remembered knowledge of where the discontiguous -regions lie. - XRAM loading via fc-xram ========================