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: > 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. > > > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot