-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/31/2014 04:44 PM, Lukasz Majewski wrote:
On Mon, 31 Mar 2014 14:05:17 -0400 Tom Rini trini@ti.com wrote:
On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote:
Up till now the CRC32 of received data was calculated unconditionally. The standard crc32 implementation causes long delays when large images were uploaded.
The "dfu_checksum_method" environment variable gives the opportunity to enable on demand (when e.g. debugging) the crc32 calculation. It can be done without need to recompile the u-boot binary.
By default the crc32 is not calculated.
Tests results: 400 MiB ums.img file With crc32 calculation: 65 sec [avg 6.29 MB/s] Without crc32 calculation: 25 sec [avg 16.17 MB/s]
Signed-off-by: Lukasz Majewski l.majewski@samsung.com
OK, so, protocol question.
The DFU 1.1 standard in its appendinx B specifies the DFU suffix. It has the crc32 for the whole file, vendorID, device ID and other handy fields.
Unfortunately, this part of the standard is not supported neither at dfu implementation in u-boot nor dfu-util (v.0.5 - debian).
OK, so this is the important part. We're doing a crc32 on stuff that's not required by spec, just handy for verification, manually.
[snip]
When we use CRC in such a way, we should be able to decide which tool (algorithm) use for debug. SHA1, MD5, etc are widely available on each linux box. To have the same crc32 algorithm, which is in u-boot, implemented as linux command line tool you need to search a bit (libarchive-zip-perl package for debian).
I take your point, but I use rhash -C to get matching crc32 and it was the first thing I stumbled upon when going "oh right, what does crc32?".
[snip]
TO SUM UP:
- Handling of the DFU suffix shall be implemented and utilized in both
u-boot and dfu-util with critical files (bootloaders, kernel).
- There should be freedom to use different checksum algorithms for
providing debugging information.
- The current CRC32 calculation at DFU should be optimized.
Well, is there work being done on the dfu-util side currently or planned in the near future to do #1 per the spec?
But, with that, I'm happier to default to no crc32'ing the data for today.
- -- Tom