Hi, I would like to have your feedback on this topic. Today a binary package of OpenOCD should include: - the binary openocd[.exe] - the TCL scripts from tcl folder - the file contrib/60-openocd.rules (for Linux only) - documentation - license files
All the small binaries for flashing are embedded inside openocd[.exe] binary. There is one exception. The old driver "ulink" loads at runtime the file ulink_firmware.hex that has to be distributed in the binary package. Actually I plan to rework it, but this is out of the scope of this email. Recently, Ahmed (in Cc) proposed a new driver in https://review.openocd.org/7701/ https://review.openocd.org/7702/ that uses the same method of run-time load as "ulink" and adds two new files; one .hex for the adapter's MCU 8051 and a bitstream for the adapter's Xilinx FPGA. To avoid adding the two new files in the binary package, I would like to embed them too inside openocd[.exe]. But the FPGA bitstream is 340697 bytes (~8% of the current size of OpenOCD) [1]. I don't want to start adding such big chunks, as openocd size could become a problem on small memory systems. Actually the FPGA bitstream is quite empty (very few sparse non-zero values) and "gzip -9" deflates it to only 1282 bytes! Cool! The Xilinx tool that generates the FPGA bitstream has a compression option; the FPGA will run a HW decompression while receiving the compressed bitstream. But that's a very basic compression method (probably just a run-length-encoding with limited window size) and the result is a disappointing 134236 bytes [2]. Plus the compressed bitstream has much higher entropy, and applying "gzip -9" gets 6744 bytes. >From the tests above, the cool options would be to: - add zlib as a dependency of OpenOCD - compress the original FPGA bitstream with "gzip -9", embed it in openocd[.exe] and decompress it when needed. Questions: - do you have any concern with this approach? - zlib is a basic library, present in every system. Also Jimtcl has optional dependency from zlib. Any issue on adding the zlib dependency to openocd? - any other use case that could benefit from compression? Today the bigger embedded binaries, if compressed with "gzip -9" provide: contrib/loaders/flash/cc26xx/cc26x2_algo.inc: from 131072 to 4464 bytes contrib/loaders/flash/cc26xx/cc26x0_algo.inc: from 77824 to 3121 bytes contrib/loaders/flash/msp432/msp432p411x_algo.inc: from 23008 to 4263 bytes Regards, Antonio [1] angie_bitstream.bit in https://review.openocd.org/c/openocd/+/7702/16 [2] angie_bitstream.bit in https://review.openocd.org/c/openocd/+/7702/17
