From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Schmidt Date: Tue, 1 Apr 2014 11:15:46 +0200 Subject: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting In-Reply-To: <20140401110027.102e0c25@amdc2363> References: <1396255729-6573-1-git-send-email-l.majewski@samsung.com> <1396255729-6573-4-git-send-email-l.majewski@samsung.com> <20140331180517.GV16360@bill-the-cat> <20140331224402.15e3e161@jawa> <20140401110027.102e0c25@amdc2363> Message-ID: <20140401091546.GF16941@novatech.datenfreihafen.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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