From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Mon, 31 Mar 2014 20:15:41 +0200
Subject: [U-Boot] [PATCH 3/3] dfu: Introduction of the
	"dfu_checksum_method" env variable for checksum method setting
In-Reply-To: <20140331180517.GV16360@bill-the-cat>
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>
Message-ID: <201403312015.41924.marex@denx.de>
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

On Monday, March 31, 2014 at 08:05:17 PM, Tom Rini 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.  What's going on in the background here such
> that it's a good and safe idea to not do this checksum and we won't end
> up in the case where data was corrupted and we just bricked a board in
> update mode?

This is just a convenience measure for people who do a lot of updates and thus 
the time matters, it's not a production-feature.

Best regards,
Marek Vasut