From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 31 Mar 2014 14:05:17 -0400 Subject: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting In-Reply-To: <1396255729-6573-4-git-send-email-l.majewski@samsung.com> References: <1396255729-6573-1-git-send-email-l.majewski@samsung.com> <1396255729-6573-4-git-send-email-l.majewski@samsung.com> Message-ID: <20140331180517.GV16360@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: