comparison doc/Loadtools-performance @ 678:f2a023c20653

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.
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 08 Mar 2020 22:56:31 +0000
parents e66fafeeb377
children 89ed8b374bc0
comparison
equal deleted inserted replaced
677:3a41d69e8104 678:f2a023c20653
83 CP2102 and FT2232D is less likely to produce such significant time difference 83 CP2102 and FT2232D is less likely to produce such significant time difference
84 given our current 2048 byte transfer block size, thus the difference in physical 84 given our current 2048 byte transfer block size, thus the difference in physical
85 flash program operation times between K5A3281CTM and S71PL129N flash chips seems 85 flash program operation times between K5A3281CTM and S71PL129N flash chips seems
86 to be the most likely explanation. 86 to be the most likely explanation.
87 87
88 Programming flash using program-m0 or program-srec
89 ==================================================
90
91 Prior to fc-host-tools-r12 flash programming via flash program-m0 or
92 program-srec commands was much slower than flash program-bin. The reason for
93 this performance discrepancy was that the original implementation of these
94 commands from 2013 was very straightforward: they operated in one pass, reading
95 the S-record image file, and as each individual S-record was read, it was turned
96 into an AMFW or INFW command to loadagent. In the case of *.m0 files generated
97 by TI's hex470 post-linker, each S-record carries 30 bytes of payload, thus the
98 flashing operation proceeded in 30-byte units, incurring the overhead of a
99 command-response exchange for every 30 bytes. In contrast, our current flash
100 program-bin implementation sends 256 bytes of payload per each AMFW or INFW
101 command; this larger unit size decreases the overhead of command-response
102 exchanges between fc-loadtool and loadagent.
103
104 Why do we need flash program-m0 and program-srec commands at all, why not
105 simply convert all SREC images to straight binary first and then program with
106 flash program-bin? The reason is that S-record images can contain multiple
107 discontiguous program regions with gaps in between. All of our current
108 FreeCalypso firmwares built with TI's TMS470 toolchain contain a few small gaps
109 in the fwimage.m0 file, filled with 0xFF bytes when converted to straight binary
110 with mokosrec2bin, but TI's own firmwares built for 8 MiB flash configurations
111 often had much bigger gaps in them.
112
113 As of fc-host-tools-r12 we finally have a more efficient solution for flashing
114 discontiguous SREC images: our new implementation of flash program-m0 and
115 program-srec commands begins with a preliminary pass (pure host operation, no
116 target interaction) of reading the S-record image file; the payload bits are
117 written into a temporary binary file (automatically deleted afterward), while
118 the address and length of each discontiguous region are remembered internally.
119 Then the actual flash programming operation proceeds just like program-bin,
120 reading from the internal binary file and sending 256 bytes of payload at a time
121 to loadagent, but using the remembered knowledge of where the discontiguous
122 regions lie.
123
124 XRAM loading via fc-xram 88 XRAM loading via fc-xram
125 ======================== 89 ========================
126 90
127 Our current fc-xram implementation is similar to the old 2013 implementation of 91 Our current fc-xram implementation is similar to the old 2013 implementation of
128 flash program-m0 and program-srec commands in that fc-xram sends a separate ML 92 flash program-m0 and program-srec commands in that fc-xram sends a separate ML