Flashing wrong image into partition using DFU
laforge at openmoko.org
Sun Mar 4 13:21:12 CET 2007
On Sun, Mar 04, 2007 at 04:33:59AM -0300, Werner Almesberger wrote:
> Harald Welte wrote:
> > then let's add some safeguard against this.
> Okay :-)
> > DFU actually specifies something like this. It also has error handling
> > for that case (i.e. we can report back that this file is not suitable
> > for the device). This is also useful for u-boot revisions that don't
> > match the hardware revision (prevenging Bv2 uboot to be flashed to Bv3
> > device, etc).
> That sounds useful, yes. Can this be done in a way that's compatible
> with present DFU support in u-boot ? (E.g., as optional data, which is
> currently ignored, or at least as a protocol revision that's rejected.)
> I guess I'll have to read that spec some day :-)
DFU basically transports one opaque block of data. It doesn't do
anything that tries to interpret/format/parse that data. All it states
is that the file must be formatted in a way acceptable to the device,
and that any file returned by "UPLOAD" must be formatted correctly to be
later "DOWNLOAD"ed again.
So no, there will not be compatibility, i.e. you cannot flash a file
with header into a bootlodaer version that doesn't parse a header.
However, we can have a fallback mode, i.e. later u-boot versions could
still accept files without header (but where's the benefit of that)?
Also, DFU makes a specification of a 'dfu file suffix' which is a small
fixed-length data structure at the end of a 'dfu' file, which indicates
stuff like for which USB vendor/device id it is supposed to be. This
makes it easier for dfu-util to find out if the user tries to send
something completely unsuitable to the device. Also, CRC32 checking on
the host side is performed.
However, we currently dont [yet] implement that file suffix. This is a
compltely local thing in dfu-util, since that suffix is to be stripped
before sent to the device.
So yes: I would think it is useful to add both DFU suffix and u-boot
header to the file. DFU suffix gets stripped within dfu-util, and uboot
header gets send to the device (which only strips it if != kernel)
In u-boot, we should check 'arch' and 'os', make sure that 'comp' is
none and that 'name' matches the partition name.
os should be 'linux' for kernel + rootfs, and should be 'u-boot' for
u-boot, splash and env.
However, using the uImage format, we still don't have checking for the
correct device revision (GTA01Bv2/Bv3/...). We could put that into the
'name' field e.g. "u-boot:GTA01Bv2". I know it sucks, but it sucks less
than inventing our own header (and tool for creating it) or introducing
> Ah, now I got it. Being able to get the listing only after you've tried
> to perform an up-/download is a bit counter-intuitive, but, say,
> specifying an invalid file name will accomplish the switch nicely, if
> one is interested in manually poking around.
feel free to add a commandline option to explicitly switch, you could
then combine that with list. or change into --list-dfu and --list-rt
> > However, matching partition names with some argument from the
> > commandline is not a problem at all, given that at that point we know
> > that we actually want to do up/download, i.e. more than just listing.
> Indeed. Patch for your consideration is in SVN,
I would rather have it return -ENODEV if it doesn't find a matching
altsetting... this also should give a reasonable error message and
avoids that +/-1 return
Apart from that: looks fine, feel free to commit.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-uboot