| Scott Anderson | 9bfecb0 | 2012-12-06 09:34:34 -0800 | [diff] [blame] | 1 |  | 
 | 2 | FastBoot  Version  0.4 | 
 | 3 | ---------------------- | 
 | 4 |  | 
 | 5 | The fastboot protocol is a mechanism for communicating with bootloaders | 
 | 6 | over USB.  It is designed to be very straightforward to implement, to | 
 | 7 | allow it to be used across a wide range of devices and from hosts running | 
 | 8 | Linux, Windows, or OSX. | 
 | 9 |  | 
 | 10 |  | 
 | 11 | Basic Requirements | 
 | 12 | ------------------ | 
 | 13 |  | 
 | 14 | * Two bulk endpoints (in, out) are required | 
 | 15 | * Max packet size must be 64 bytes for full-speed and 512 bytes for  | 
 | 16 |   high-speed USB | 
 | 17 | * The protocol is entirely host-driven and synchronous (unlike the | 
 | 18 |   multi-channel, bi-directional, asynchronous ADB protocol) | 
 | 19 |  | 
 | 20 |  | 
 | 21 | Transport and Framing | 
 | 22 | --------------------- | 
 | 23 |  | 
 | 24 | 1. Host sends a command, which is an ascii string in a single | 
 | 25 |    packet no greater than 64 bytes. | 
 | 26 |  | 
 | 27 | 2. Client response with a single packet no greater than 64 bytes. | 
 | 28 |    The first four bytes of the response are "OKAY", "FAIL", "DATA",  | 
 | 29 |    or "INFO".  Additional bytes may contain an (ascii) informative | 
 | 30 |    message. | 
 | 31 |  | 
 | 32 |    a. INFO -> the remaining 60 bytes are an informative message | 
 | 33 |       (providing progress or diagnostic messages).  They should  | 
 | 34 |       be displayed and then step #2 repeats | 
 | 35 |  | 
 | 36 |    b. FAIL -> the requested command failed.  The remaining 60 bytes  | 
 | 37 |       of the response (if present) provide a textual failure message  | 
 | 38 |       to present to the user.  Stop. | 
 | 39 |  | 
 | 40 |    c. OKAY -> the requested command completed successfully.  Go to #5 | 
 | 41 |  | 
 | 42 |    d. DATA -> the requested command is ready for the data phase. | 
 | 43 |       A DATA response packet will be 12 bytes long, in the form of | 
 | 44 |       DATA00000000 where the 8 digit hexidecimal number represents | 
 | 45 |       the total data size to transfer. | 
 | 46 |  | 
 | 47 | 3. Data phase.  Depending on the command, the host or client will  | 
 | 48 |    send the indicated amount of data.  Short packets are always  | 
 | 49 |    acceptable and zero-length packets are ignored.  This phase continues | 
 | 50 |    until the client has sent or received the number of bytes indicated | 
 | 51 |    in the "DATA" response above. | 
 | 52 |  | 
 | 53 | 4. Client responds with a single packet no greater than 64 bytes.   | 
 | 54 |    The first four bytes of the response are "OKAY", "FAIL", or "INFO".   | 
 | 55 |    Similar to #2: | 
 | 56 |  | 
 | 57 |    a. INFO -> display the remaining 60 bytes and return to #4 | 
 | 58 |     | 
 | 59 |    b. FAIL -> display the remaining 60 bytes (if present) as a failure | 
 | 60 |       reason and consider the command failed.  Stop. | 
 | 61 |  | 
 | 62 |    c. OKAY -> success.  Go to #5 | 
 | 63 |  | 
 | 64 | 5. Success.  Stop. | 
 | 65 |  | 
 | 66 |  | 
 | 67 | Example Session | 
 | 68 | --------------- | 
 | 69 |  | 
 | 70 | Host:    "getvar:version"        request version variable | 
 | 71 |  | 
 | 72 | Client:  "OKAY0.4"               return version "0.4" | 
 | 73 |  | 
 | 74 | Host:    "getvar:nonexistant"    request some undefined variable | 
 | 75 |  | 
 | 76 | Client:  "OKAY"                  return value "" | 
 | 77 |  | 
 | 78 | Host:    "download:00001234"     request to send 0x1234 bytes of data | 
 | 79 |  | 
 | 80 | Client:  "DATA00001234"          ready to accept data | 
 | 81 |  | 
 | 82 | Host:    < 0x1234 bytes >        send data | 
 | 83 |  | 
 | 84 | Client:  "OKAY"                  success | 
 | 85 |  | 
 | 86 | Host:    "flash:bootloader"      request to flash the data to the bootloader | 
 | 87 |  | 
 | 88 | Client:  "INFOerasing flash"     indicate status / progress | 
 | 89 |          "INFOwriting flash" | 
 | 90 |          "OKAY"                  indicate success | 
 | 91 |  | 
 | 92 | Host:    "powerdown"             send a command | 
 | 93 |  | 
 | 94 | Client:  "FAILunknown command"   indicate failure | 
 | 95 |  | 
 | 96 |  | 
 | 97 | Command Reference | 
 | 98 | ----------------- | 
 | 99 |  | 
 | 100 | * Command parameters are indicated by printf-style escape sequences. | 
 | 101 |  | 
 | 102 | * Commands are ascii strings and sent without the quotes (which are | 
 | 103 |   for illustration only here) and without a trailing 0 byte. | 
 | 104 |  | 
 | 105 | * Commands that begin with a lowercase letter are reserved for this | 
 | 106 |   specification.  OEM-specific commands should not begin with a  | 
 | 107 |   lowercase letter, to prevent incompatibilities with future specs. | 
 | 108 |  | 
 | 109 |  "getvar:%s"           Read a config/version variable from the bootloader. | 
 | 110 |                        The variable contents will be returned after the | 
 | 111 |                        OKAY response. | 
 | 112 |  | 
 | 113 |  "download:%08x"       Write data to memory which will be later used | 
 | 114 |                        by "boot", "ramdisk", "flash", etc.  The client | 
 | 115 |                        will reply with "DATA%08x" if it has enough  | 
 | 116 |                        space in RAM or "FAIL" if not.  The size of | 
 | 117 |                        the download is remembered. | 
 | 118 |  | 
 | 119 |   "verify:%08x"        Send a digital signature to verify the downloaded | 
 | 120 |                        data.  Required if the bootloader is "secure" | 
 | 121 |                        otherwise "flash" and "boot" will be ignored. | 
 | 122 |  | 
 | 123 |   "flash:%s"           Write the previously downloaded image to the | 
 | 124 |                        named partition (if possible). | 
 | 125 |  | 
 | 126 |   "erase:%s"           Erase the indicated partition (clear to 0xFFs) | 
 | 127 |  | 
 | 128 |   "boot"               The previously downloaded data is a boot.img | 
 | 129 |                        and should be booted according to the normal | 
 | 130 |                        procedure for a boot.img | 
 | 131 |  | 
 | 132 |   "continue"           Continue booting as normal (if possible) | 
 | 133 |  | 
 | 134 |   "reboot"             Reboot the device. | 
 | 135 |  | 
 | 136 |   "reboot-bootloader"  Reboot back into the bootloader. | 
 | 137 |                        Useful for upgrade processes that require upgrading | 
 | 138 |                        the bootloader and then upgrading other partitions | 
 | 139 |                        using the new bootloader. | 
 | 140 |  | 
 | 141 |   "powerdown"          Power off the device. | 
 | 142 |  | 
 | 143 |  | 
 | 144 |  | 
 | 145 | Client Variables | 
 | 146 | ---------------- | 
 | 147 |  | 
 | 148 | The "getvar:%s" command is used to read client variables which | 
 | 149 | represent various information about the device and the software | 
 | 150 | on it. | 
 | 151 |  | 
 | 152 | The various currently defined names are: | 
 | 153 |  | 
 | 154 |   version             Version of FastBoot protocol supported. | 
 | 155 |                       It should be "0.3" for this document. | 
 | 156 |  | 
 | 157 |   version-bootloader  Version string for the Bootloader. | 
 | 158 |  | 
 | 159 |   version-baseband    Version string of the Baseband Software | 
 | 160 |  | 
 | 161 |   product             Name of the product | 
 | 162 |  | 
 | 163 |   serialno            Product serial number | 
 | 164 |  | 
 | 165 |   secure              If the value is "yes", this is a secure | 
 | 166 |                       bootloader requiring a signature before | 
 | 167 |                       it will install or boot images. | 
 | 168 |  | 
 | 169 | Names starting with a lowercase character are reserved by this | 
 | 170 | specification.  OEM-specific names should not start with lowercase | 
 | 171 | characters. | 
 | 172 |  | 
 | 173 |  |