Add old fastboot_protocol.txt

FastBoot  Version  0.4

----------------------

The fastboot protocol is a mechanism for communicating with bootloaders

over USB.  It is designed to be very straightforward to implement, to

allow it to be used across a wide range of devices and from hosts running

Linux, Windows, or OSX.

Basic Requirements

------------------

* Two bulk endpoints (in, out) are required

* Max packet size must be 64 bytes for full-speed and 512 bytes for 

  high-speed USB

* The protocol is entirely host-driven and synchronous (unlike the

  multi-channel, bi-directional, asynchronous ADB protocol)

Transport and Framing

---------------------

1. Host sends a command, which is an ascii string in a single

   packet no greater than 64 bytes.

2. Client response with a single packet no greater than 64 bytes.

   The first four bytes of the response are "OKAY", "FAIL", "DATA", 

   or "INFO".  Additional bytes may contain an (ascii) informative

   message.

   a. INFO -> the remaining 60 bytes are an informative message

      (providing progress or diagnostic messages).  They should 

      be displayed and then step #2 repeats

   b. FAIL -> the requested command failed.  The remaining 60 bytes 

      of the response (if present) provide a textual failure message 

      to present to the user.  Stop.

   c. OKAY -> the requested command completed successfully.  Go to #5

   d. DATA -> the requested command is ready for the data phase.

      A DATA response packet will be 12 bytes long, in the form of

      DATA00000000 where the 8 digit hexidecimal number represents

      the total data size to transfer.

3. Data phase.  Depending on the command, the host or client will 

   send the indicated amount of data.  Short packets are always 

   acceptable and zero-length packets are ignored.  This phase continues

   until the client has sent or received the number of bytes indicated

   in the "DATA" response above.

4. Client responds with a single packet no greater than 64 bytes.  

   The first four bytes of the response are "OKAY", "FAIL", or "INFO".  

   Similar to #2:

   a. INFO -> display the remaining 60 bytes and return to #4

   b. FAIL -> display the remaining 60 bytes (if present) as a failure

      reason and consider the command failed.  Stop.

   c. OKAY -> success.  Go to #5

5. Success.  Stop.

Example Session

---------------

Host:    "getvar:version"        request version variable

Client:  "OKAY0.4"               return version "0.4"

Host:    "getvar:nonexistant"    request some undefined variable

Client:  "OKAY"                  return value ""

Host:    "download:00001234"     request to send 0x1234 bytes of data

Client:  "DATA00001234"          ready to accept data

Host:    < 0x1234 bytes >        send data

Client:  "OKAY"                  success

Host:    "flash:bootloader"      request to flash the data to the bootloader

Client:  "INFOerasing flash"     indicate status / progress

         "INFOwriting flash"

         "OKAY"                  indicate success

Host:    "powerdown"             send a command

Client:  "FAILunknown command"   indicate failure

Command Reference

-----------------

* Command parameters are indicated by printf-style escape sequences.

* Commands are ascii strings and sent without the quotes (which are

  for illustration only here) and without a trailing 0 byte.

* Commands that begin with a lowercase letter are reserved for this

  specification.  OEM-specific commands should not begin with a 

  lowercase letter, to prevent incompatibilities with future specs.

 "getvar:%s"           Read a config/version variable from the bootloader.

                       The variable contents will be returned after the

                       OKAY response.

 "download:%08x"       Write data to memory which will be later used

                       by "boot", "ramdisk", "flash", etc.  The client

                       will reply with "DATA%08x" if it has enough 

                       space in RAM or "FAIL" if not.  The size of

                       the download is remembered.

  "verify:%08x"        Send a digital signature to verify the downloaded

                       data.  Required if the bootloader is "secure"

                       otherwise "flash" and "boot" will be ignored.

  "flash:%s"           Write the previously downloaded image to the

                       named partition (if possible).

  "erase:%s"           Erase the indicated partition (clear to 0xFFs)

  "boot"               The previously downloaded data is a boot.img

                       and should be booted according to the normal

                       procedure for a boot.img

  "continue"           Continue booting as normal (if possible)

  "reboot"             Reboot the device.

  "reboot-bootloader"  Reboot back into the bootloader.

                       Useful for upgrade processes that require upgrading

                       the bootloader and then upgrading other partitions

                       using the new bootloader.

  "powerdown"          Power off the device.

Client Variables

----------------

The "getvar:%s" command is used to read client variables which

represent various information about the device and the software

on it.

The various currently defined names are:

  version             Version of FastBoot protocol supported.

                      It should be "0.3" for this document.

  version-bootloader  Version string for the Bootloader.

  version-baseband    Version string of the Baseband Software

  product             Name of the product

  serialno            Product serial number

  secure              If the value is "yes", this is a secure

                      bootloader requiring a signature before

                      it will install or boot images.

Names starting with a lowercase character are reserved by this

specification.  OEM-specific names should not start with lowercase

characters.