[U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting

[Tom Rini]

-----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 at 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 at 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:
> 
> 1. Handling of the DFU suffix shall be implemented and utilized in both
> u-boot and dfu-util with critical files (bootloaders, kernel).
> 
> 2. There should be freedom to use different checksum algorithms for
> providing debugging information.
> 
> 3. 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTOdhmAAoJENk4IS6UOR1WDsYP/2eg3v+K5nCUZ22eYnrY4s14
f8KUan8My7Ifr/to9qbAIFsSuw5mlLPvYy5JNnrbmmipDH2bQIO20R1t94/Mm8Ut
Hoj1nbGZ3JvMsoj86D+9pFz2AchVgbpvs+boiJGw2s1TZ3xKoNlJ1O4WJ8ttZRZS
1B3FC50PKYJK6lgWgfvds2AevLIAcF1QyePVsOLVKV2USilFiZ1LVb8qUFp5l6Ja
LX3wfQjhPq4gQq8bX7LW6zNbDkXuZjxLlKT/kUxzl2qclpHj4+8rXVVRf1mLaLvU
Dvx50V/JCncIivRBhfvK2BoQ/LOntmPwGfO95AY57naP9+nCzzE9vdKv/Ki5vpju
/q/CjlXbkS4iwru+91neyMdfeCiiALV2yW0GBORgph7kCpUk343S753epl/MFmAW
rOQ0xBjw4q5KeXijtQG5bdevynPkB09soKKhQX5XRe7i8olXe32+khQVwqpomjkG
v0YbKvUTuCZ1NNZqEey/zO4gJPR2Tq4QiNFpfFPvcYOqlqoC/C84HfO+M8ocKiUh
SUgdaUQI+uP7LSQ7Yv5N149ZD4aWAfsyU5YCtyC0gI9aXRF5YqwWU96eym8PUVM8
amo+srsp1uK5l6XRO0cqtM9cmLedPRNAEKhah4/GgZa3S6lTH3oD7JBEPNyazTsc
FpOnIzGk5JJnVpeobQv2
=HfXm
-----END PGP SIGNATURE-----