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? 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.
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:
- The file before reading by dfu-util has to be equipped with suffix.
- 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.
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.
regards Stefan Schmidt