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

[Lukasz Majewski <l.majewski@samsung.com>]

Hi Stefan,

> Hello.
> 
> On Tue, 2014-04-01 at 11:00, Lukasz Majewski wrote:
> > Hi Tormod,
> > 
> > > On Mon, Mar 31, 2014 at 10:44 PM, Lukasz Majewski wrote:
> > > > 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).
> > > 
> > > You are wrong :) Please don't use what's available in Debian
> > > (stable?) as a reference.
> > 
> > I'm regarding this as a reference since 80% of developers will
> > download the dfu-util with apt-get on debian.
> 
> You really believe that 80% of all developers are using Debian? 

It seems, that some miscommunication has crept in. What I meant was that
majority of developers, who are using deb based distro (debian, ubuntu),
would be lazy and use the apt-get/aptitude utility to install dfu-util.

It doesn't mean, that I'm not using the newest dfu-util (I recall that
there was some issue with libusb).

> If
> they ship an old version there is nothing Tormod can do about it. I
> implemented the dfu suffix feature one or two years ago and made a
> release after it. If distros are not picking it up you have to fill a
> bug for them to update.

Maybe this is the thing to do.

> 
> > > I don't know what their maintainer is up to. dfu-util
> > > supports the DFU suffix according to the DFU standard. That means
> > > it checks the CRC after reading the file, and also checks that
> > > vendor/product values match, then sends the firmware to the device
> > > after stripping off the suffix.
> > 
> > So this means that:
> > 1. The file before reading by dfu-util has to be equipped with
> > suffix. 2. The dfu-util reads it and then if matching sends data
> > (with sufix stripped) to target. This means that we are "protected"
> > from downloading wrong firmware to device, however
> > 3. The target doesn't have any means to check if the downloaded
> > data is consistent - the information about CRC is stripped at
> > dfu-util.
> 
> Correct. That is how the DFU spec defines it.

Now it is clear.

> 
> > > 
> > > Are you wanting to do some CRC checking at the device side? That
> > > would be outside the DFU standard. 
> > 
> > I hoped that the suffix is appended by dfu-util and then sent with
> > the binary to target. As a result we would be able to perform some
> > integrity tests.
> 
> The spec requires to remove it. I also found that odd when
> implementing it but the spec is clear on this.
> 
> > > But you can always put whatever you want
> > > in the "firmware", including proprietary headers or suffices.
> > 
> > I think that this would be finally required for updating small
> > (crucial) files - like bootloaders, kernels.
> > 
> > > We
> > > already support some of those, please see the dfu-util (and
> > > dfu-suffx/dfu-prefix) code at dfu-util.gnumonks.org.
> > 
> > Ok, I see. This would probably require extension of ./src/prefix.c
> > file. In this way u-boot community would impose some kind of
> > standard prefix/suffix only for u-boot. It's a pity, that integrity
> > checking is not standardized in the DFU.
> 
> It all depends on how much you want to be compatible with the DFU
> spec.

I would like to be as close to the standard as possible. Otherwise I
could be blamed for breaking compatibility.

> 
> regards
> Stefan Schmidt



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group