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