public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Date: Tue, 01 Apr 2014 11:00:27 +0200	[thread overview]
Message-ID: <20140401110027.102e0c25@amdc2363> (raw)
In-Reply-To: <CAArsGaZgogqQzmUcCDe98GETeROXF_wS7euxnkGjBrYf9br6zQ@mail.gmail.com>

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.

> 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.

> 
> 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.

> 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.

> 
> Regards,
> Tormod


-- 
Best regards,

Lukasz Majewski

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

  reply	other threads:[~2014-04-01  9:00 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31  8:48 [U-Boot] [PATCH 0/3] dfu: Several enhancements for dfu subsystem Lukasz Majewski
2014-03-31  8:48 ` [U-Boot] [PATCH 1/3] dfu: mmc: Provide support for eMMC boot partition access Lukasz Majewski
2014-03-31  8:59   ` Marek Vasut
2014-03-31  9:14     ` Lukasz Majewski
2014-05-09 14:58   ` [U-Boot] [PATCH v2] " Lukasz Majewski
2014-05-14 22:24     ` Marek Vasut
2014-03-31  8:48 ` [U-Boot] [PATCH 2/3] dfu: add static alt num count in dfu_config_entities() Lukasz Majewski
2014-03-31  9:01   ` Marek Vasut
2014-03-31  9:15     ` Lukasz Majewski
2014-04-01  6:47       ` Przemyslaw Marczak
2014-04-01  6:49         ` Marek Vasut
2014-04-01  7:45           ` Lukasz Majewski
2014-03-31  8:48 ` [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting Lukasz Majewski
2014-03-31  9:04   ` Marek Vasut
2014-03-31  9:24     ` Lukasz Majewski
2014-03-31  9:29       ` Marek Vasut
2014-03-31  9:49         ` Lukasz Majewski
2014-03-31 11:19   ` Pantelis Antoniou
2014-03-31 12:04     ` Lukasz Majewski
2014-03-31 12:10       ` Pantelis Antoniou
2014-03-31 12:16       ` Pantelis Antoniou
2014-03-31 18:05   ` Tom Rini
2014-03-31 18:15     ` Marek Vasut
2014-03-31 18:26       ` Tom Rini
2014-03-31 20:44     ` Lukasz Majewski
2014-03-31 21:04       ` Tom Rini
2014-04-01  9:05         ` Lukasz Majewski
2014-03-31 21:44       ` Tormod Volden
2014-04-01  9:00         ` Lukasz Majewski [this message]
2014-04-01  9:15           ` Stefan Schmidt
2014-04-01 11:31             ` Lukasz Majewski
2014-05-05 13:16   ` [U-Boot] [PATCH v2] " Lukasz Majewski
2014-05-05 17:47     ` Marek Vasut
2014-05-08 12:27     ` [U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" " Lukasz Majewski
2014-05-08 13:07       ` Marek Vasut
2014-05-09  4:27       ` Wolfgang Denk
2014-05-09  6:52         ` Lukasz Majewski
2014-05-09  8:31           ` Wolfgang Denk
2014-05-09  9:54             ` Lukasz Majewski
2014-05-12 14:45             ` Tom Rini
2014-05-15  7:09               ` Lukasz Majewski
2014-05-15  9:27                 ` Heiko Schocher
2014-05-15 11:19                 ` Wolfgang Denk
2014-05-15 13:43                   ` Lukasz Majewski
2014-05-15 14:07                     ` Wolfgang Denk
2014-05-16  6:08                       ` Lukasz Majewski
2014-05-16  8:58                     ` Lukasz Majewski
2014-05-19 14:02                       ` Heiko Schocher
2014-05-20 17:22                         ` Lukasz Majewski
2014-05-22  9:46                         ` Lukasz Majewski
2014-05-12  8:43     ` [U-Boot] [PATCH v4] " Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140401110027.102e0c25@amdc2363 \
    --to=l.majewski@samsung.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox