diff options
Diffstat (limited to 'fastboot_protocol.txt')
| -rw-r--r-- | fastboot_protocol.txt | 173 |
1 files changed, 0 insertions, 173 deletions
diff --git a/fastboot_protocol.txt b/fastboot_protocol.txt deleted file mode 100644 index 2248992..0000000 --- a/fastboot_protocol.txt +++ /dev/null @@ -1,173 +0,0 @@ - -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. - - |