Hi Tom, > -----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.
Yes, indeed. > > [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? As Tormod has written, dfu-util supports it for initial setting, but is sending data with this information stripped. Hence u-boot shall not calculate CRC32 unless we plan to add a customized prefix for crucial binaries. > > But, with that, I'm happier to default to no crc32'ing the data for > today. Thanks for your opinion. We share similar view on the issue. > > - -- > 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----- -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot