Zach, I did go one more round with WD on the fastboot with a strawman proposal. I never followed up because I was not sure that the resources were commited to do it in Linaro.

Forwarded conversation Subject: [U-Boot] strawman Fastboot in U-Boot Design Doc ------------------------

From: *John Rigby* john.rigby@linaro.org Date: Thu, Apr 28, 2011 at 7:07 PM To: u-boot@lists.denx.de, Wolfgang Denk wd@denx.de

Here a first draft design doc. It is based in part on the Fastboot implementation in the rowboat git repo (pointer below).

As always, comments welcome. John

Purpose =======

Mainline support for Android Fastboot would be useful. Arguing the merits of Fastboot vs DFU is not in the scope of this document. This document is to discuss design goals/requirements of an implementation of Fastboot in U-Boot.

Background ==========

See the Android Fastboot page in Omappedia for an example of how Fastboot is used to flash nand partitions on an Android device. http://www.omappedia.org/wiki/Android_Fastboot

A description of the Fastboot protocol is available in the gitorious rowboat git repo. http://gitorious.org/rowboat/bootable-bootloader-legacy/blobs/master/fastboo...

Hooks into U-Boot =================

Fastboot gets access to the USB subsystem via the same interfaces as USB_TTY, namely the udc_* api's: udc_init udc_startup_events udc_connect udc_poll udc_setup_ep etc.

Startup =======

Fastboot will be started on the target by issuing the "fastboot" command. Optionally a board specific startup method may exist. For example if a certain combination of keys is pressed on reset then fastboot will be started immediately.

Shutdown ========

Once started the fastboot command will continue until: <CTRL-C> is typed on the console a "continue" command is sent from the host usb cable is removed no commands have been sent from the host for some configurable timeout

Coexistance With USB_TTY and DFU ================================

One should be able to enable USB_TTY, DFU and Fastboot at compile time and chose one at runtime.

Questions ========

Should a Fastboot host program be included in the U-Boot source? Could Fastboot be implemented as an extension to USB_TTY? Could Fastboot, DFU and USB_TTY share a layer of code above the udc_* api's? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

---------- From: *Wolfgang Denk* wd@denx.de Date: Fri, Apr 29, 2011 at 4:48 AM To: John Rigby john.rigby@linaro.org Cc: u-boot@lists.denx.de

Dear John Rigby, Thanks. Does it make sense to restrict this to USB? Or should we decouple the protocol part from the actual transport path? Maybe it would make sense to provide the same feature over plain serial line, or over Ethernet?

Also please keep in mind that there are many ways how a system can interact with the "operator": we have plain old serial console, netconsole, console over serial over USB, netconsole over Ethernet over USB, ...

We should make sure that at least on the conceptual level adding fastboot support will not cause any conflicts. OK. This has nothing to do with fastboot, and should be kept as a separate item. Normally U-Boot allows, when keys are supported, to map any combination of key presses to any commands, i. e. this is in no way restricted to or dependent on fastboot support. This probably needs configuration.

"usb cable is removed" probably makes little sense when running fastboot protocol over a serial port.

Also, this feature would require permanent polling of the USB status. Is this needed? I'm not sure what exactly you mean by "chose one at runtime". It is pretty much clear that you don't want to run DFU and fastboot simultaneously, but it is very likely that we will need USB_TTY (for console over USB) or even Ethernet over USB for console and then want to start fastboot.

I think I remember that fastboot may require "adjustments" of the USB IDs and such - we will have to make sure that things like that do not cause conflicts.

An area that raises additional questions is error handling. When running fastboot over USB and with a serial console it is probably a very good idea to provide error messages and maybe even status reports on the console. Will this still work with USB_TTY or netconsole over Ethernet over USB? Seems some peole want it... I think we should at least split protocol handling and communication layer. At least they will have to co-exist with each other.

Best regards,

Wolfgang Denk

-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "A dirty mind is a joy forever." - Randy Kunkee

---------- From: *Detlev Zundel* dzu@denx.de Date: Fri, Apr 29, 2011 at 5:02 AM To: John Rigby john.rigby@linaro.org Cc: u-boot@lists.denx.de

Hi John, Thanks for this piece of documentation. Itcertainly helped me understand that the "boot" part in fastboot is kind of a misnomer, right?

Again it shows that a bad description can lead thoughts astray....

[...] So in essence you say that fastboot is an "alternative" implementation of the "idea" behind DFU? Or is DFU (functionally) a subset of fastboot? It may be worth extending on that aspect so that people knowing DFU can "hook into" the discussion.

[...] I would certainly welcome a "reference" implementation for a GNU/Linux host. Hopefully this will prevent multiple works later on. Maybe even writing a small library and having a simple command line wrapper would be good (like flat device tree and libfdt).

Best wishes Detlev

-- Is this a private fight or can anyone join in? -- Old Irish saying -- Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de