四极管：FastBoot 协议源码

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",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.