FreeCalypso > hg > freecalypso-tools
changeset 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 | 3a41d69e8104 |
children | be641fa7b68d |
files | doc/Loadtools-performance |
diffstat | 1 files changed, 0 insertions(+), 36 deletions(-) [+] |
line wrap: on
line diff
--- 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 ========================