[U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting

[Lukasz Majewski]

On Mon, 31 Mar 2014 14:05:17 -0400
Tom Rini <trini at 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 at 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).

It would be handy for small files (like bootloaders, kernels) where we
download all the data at once. For critical files it should be
definitely implemented. From my glimpse observation the dfu-util would
require some extension to support the DFU suffix (Tormod, please
correct me if I'm wrong).

For large files (400 MiB in this case) it is useless since we store
data as it goes (with 32 MiB chunks). Also, as we send the large files
we experience the biggest performance penalty from CRC32 calculation.
It takes considerable time and in my opinion now serves only for debug
purposes, to provide the final CRC for comparison with original one,
even though the file is already on flash.

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 think that we can improve the crc32 performance with calculating it
for smaller chunks, which already fits L1 cache. Now they are calculated
for 32 MiB.


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

Now we rely solely on testing. Downloading file, checking CRC and
compare with original.
I also have some automated tests, which utilize MD5.

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.


> 

Best regards,
Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140331/672a2a95/attachment.pgp>