-----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 <tr...@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.majew...@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----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot