From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lukasz Majewski <l.majewski@samsung.com>
Date: Tue, 01 Apr 2014 11:05:28 +0200
Subject: [U-Boot] [PATCH 3/3] dfu: Introduction of the
 "dfu_checksum_method" env variable for checksum method setting
In-Reply-To: <5339D866.8020405@ti.com>
References: <1396255729-6573-1-git-send-email-l.majewski@samsung.com>
	<1396255729-6573-4-git-send-email-l.majewski@samsung.com>
	<20140331180517.GV16360@bill-the-cat> <20140331224402.15e3e161@jawa>
	<5339D866.8020405@ti.com>
Message-ID: <20140401110528.679eeda7@amdc2363>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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 <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.

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