public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@datenfreihafen.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [ RFC ] fastboot protocol support in u-boot
Date: Tue, 16 Aug 2011 20:12:21 +0200	[thread overview]
Message-ID: <20110816181221.GB8317@excalibur.local> (raw)
In-Reply-To: <CADDGHU_BzOeeyfUuiM9+DSdisjGQ+rNt-FPkJLTd=-9LeoOGNQ@mail.gmail.com>

Hello.

On Tue, 2011-08-16 at 09:32, John Rigby wrote:
> On Tue, Aug 16, 2011 at 8:47 AM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
> >
> > Given these different use cases I never seen fastboot and DFU as
> > competitors. Personally I see DFU as a good and standardized way of
> > _flashing_ devices while fastboot/novacom are way to communicate with
> > the bootloader (allow flashing as on task).
> >
> Just my two cents.  From my discussions with Android developers, they
> use fastboot as a quick turnaround way of getting an image on a board
> during iterative development.

Sure, we did the same with DFU at Openmoko and other companies have
done the same as well with DFU. What I was meaning to point out is
that flashing (be it to NAND, NOR or just to RAM) is only one action
out of many you can do with fastboot. While with DFU it was designed
to only do upgrade or backup operations. Nothing else.

> The other thing I think is important is the ability to choose DFU or
> fastboot at run time vs compile time.  So we should be able to have
> both features turned on in a given u-boot binary.  This means of
> course that fastboot, or DFU would not assume it owned the gadget USB
> HW.

Hmm, interesting point. To be honest I never have thought about people
having both enabled at runtime. Having fastboot with flashing seem to
imply that DFU is not used on that device to me. What is the use-case
you are describing here?

Or are you talking about changing fastboot to use DFU as a flashing
backend or such?

Anyway, DFU does distinguish between run-time and DFU mode. During
run-time it only offers a single DFU class interface descriptor and a
single functional descriptor. This get added to every USB
configuration the devices exposes (and wants to support DFU in it).

This is used to to trigger a switch to the DFU mode where the complete
DFU protocol interaction happens. Normally this is used to enter the
flash mode from the run-time mode via the host utility. Often there is
also a button combination that can be pressed to directly boot up the
device in DFU mode for flashing.

How we could hook that together with fastboot I don't know yet. One
easy solution would be to bring up u-boot in DFU run-time mode and
disable all fastboot stuff once we switch to DFU mode as well as the
other way around.

I'm still curious though if there are practical needs for both
fastboot and DFU enabled.

regards
Stefan Schmidt

  reply	other threads:[~2011-08-16 18:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 18:07 [U-Boot] [ RFC ] fastboot protocol support in u-boot Sebastian Andrzej Siewior
2011-08-10 18:07 ` [U-Boot] [RFC] fastboot gadget support Sebastian Andrzej Siewior
2011-08-13 10:22   ` Remy Bohmer
2011-08-24 14:09     ` Sebastian Andrzej Siewior
2011-08-24 19:34   ` Remy Bohmer
2011-08-26 10:09     ` Sebastian Andrzej Siewior
2011-08-16 14:47 ` [U-Boot] [ RFC ] fastboot protocol support in u-boot Stefan Schmidt
2011-08-16 15:32   ` John Rigby
2011-08-16 18:12     ` Stefan Schmidt [this message]
2011-08-16 19:44       ` John Rigby
2011-08-16 20:44         ` Stefan Schmidt

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=20110816181221.GB8317@excalibur.local \
    --to=stefan@datenfreihafen.org \
    --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