Dear John Rigby,

In message BANLkTinFHTff5Scr_uP6KNBXQKP3SvVB5A@mail.gmail.com you wrote:

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

Thanks.

Hooks into U-Boot

Fastboot gets access to the USB subsystem via the same interfaces as USB_TTY, namely the udc_* api's:

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.

Startup

Fastboot will be started on the target by issuing the "fastboot" command.

OK.

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.

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.

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

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?

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.

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?

Questions

Should a Fastboot host program be included in the U-Boot source?

Seems some peole want it...

Could Fastboot be implemented as an extension to USB_TTY?

I think we should at least split protocol handling and communication layer.

Could Fastboot, DFU and USB_TTY share a layer of code above the udc_* api's?

At least they will have to co-exist with each other.

Best regards,

Wolfgang Denk