1 2FastBoot Version 0.4 3---------------------- 4 5The fastboot protocol is a mechanism for communicating with bootloaders 6over USB. It is designed to be very straightforward to implement, to 7allow it to be used across a wide range of devices and from hosts running 8Linux, Windows, or OSX. 9 10 11Basic 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 21Transport and Framing 22--------------------- 23 241. Host sends a command, which is an ascii string in a single 25 packet no greater than 64 bytes. 26 272. 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 473. 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 534. 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 645. Success. Stop. 65 66 67Example Session 68--------------- 69 70Host: "getvar:version" request version variable 71 72Client: "OKAY0.4" return version "0.4" 73 74Host: "getvar:nonexistant" request some undefined variable 75 76Client: "OKAY" return value "" 77 78Host: "download:00001234" request to send 0x1234 bytes of data 79 80Client: "DATA00001234" ready to accept data 81 82Host: < 0x1234 bytes > send data 83 84Client: "OKAY" success 85 86Host: "flash:bootloader" request to flash the data to the bootloader 87 88Client: "INFOerasing flash" indicate status / progress 89 "INFOwriting flash" 90 "OKAY" indicate success 91 92Host: "powerdown" send a command 93 94Client: "FAILunknown command" indicate failure 95 96 97Command 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 145Client Variables 146---------------- 147 148The "getvar:%s" command is used to read client variables which 149represent various information about the device and the software 150on it. 151 152The 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 169Names starting with a lowercase character are reserved by this 170specification. OEM-specific names should not start with lowercase 171characters. 172 173 174